|
Mierdaan posted:Can you provide some documentation to back this up? It is my understanding that you cannot send traffic back out over the same physical interface it came in on, but we're talking about logical interfaces when it comes to vlans - not physical. It will forward to another logical interface. I should have read about your situation more closely. Anyways, it looks like you have a 255.255.0.0 subnet on your internal interface. Is that intentional?
|
#
?
Jul 5, 2007 19:48
|
|
|
|
| # ? May 31, 2024 11:59 |
|
|
dwarftosser posted:It will forward to another logical interface. I should have read about your situation more closely. Yes, our network here is 10.10.0.0/16.
|
|
#
?
Jul 5, 2007 19:52
|
|
|
Mierdaan posted:Yes, our network here is 10.10.0.0/16. How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space? Wouldn't clients on the inside network just arp for 10.10.7.x hosts? Is the pix doing proxy-arp? quote:
|
|
#
?
Jul 5, 2007 20:12
|
|
|
jwh posted:How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space? Yeah that also caught my eye... technically they should both be /24's shouldn't they?
|
|
#
?
Jul 5, 2007 20:20
|
|
|
atticus posted:Yeah that also caught my eye... technically they should both be /24's shouldn't they? You can proxy-arp to fake it (clients in 10.10/16 arp for what they think is local, gateway responds with it's own MAC), but I don't know if proxy-arp is enabled by default on pix interfaces. It probably is, because it's been like that on IOS devices forever, but I don't know for certain. If I had to guess, it's probably enabled by default, and isn't really the problem here. You also used to be able to set yourself as your gateway in windows, and it would cause the stack to arp for _everything_, which was pretty cool.
|
|
#
?
Jul 5, 2007 20:29
|
|
|
jwh posted:How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space? If the clients are running a /16 subnet mask they sure as heck won't hit the gateway. The PIX should be able to figure out things just like a router in regards to 'subnetted' networks. Show route should... show that. In an earlier post, some guy had overlapping IP 4 subnets (for defining lan to lan VPN) that would have not worked unless he changed his local 10/8 to a 10/24.
|
|
#
?
Jul 5, 2007 20:31
|
|
|
jwh posted:How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space? Yeah, I've been wondering about this for a while but wasn't real sure if it was going to cause a problem or not. This scheme was dreamed up by a converged engineer at our phone system implementation partner, I'm gradually getting myself up to speed on how this whole thing works.
|
|
#
?
Jul 5, 2007 20:31
|
|
|
Herv posted:If the clients are running a /16 subnet mask they sure as heck won't hit the gateway. Pretty weird.
|
|
#
?
Jul 5, 2007 20:35
|
|
|
Well, that's enlightening. I added a static arp entry for 10.10.7.9 (the voicemail server) to one of my boxes, and gave it the PIX's MAC address. I can remote desktop into the voicemail server by IP address now without any problem. So, this says to me that the PIX wasn't doing proxy-arp by default. Time to read into how to turn it on.
|
|
#
?
Jul 5, 2007 21:53
|
|
|
Herv posted:No sir, it's been either Text Pad, or VI for me for ages. Our current setup is PPTP, L2TP looks like it will do what we want, I'll look at setting it up.
|
|
#
?
Jul 5, 2007 22:30
|
|
|
I'm having a hell of time figuring out this problem with ASA. This is my first time configuring a firewall and I'm a bit in over my head. I have a 4507 switch and an ASA5510 firewall. The outside interface goes to the internet. The inside interface is a point to point link to the switch. The asa-side IP is 192.168.99.1 and the switch side non-switch-port is 192.168.99.2. The DMZ is a trunk that goes to the switch carrying the DMZ vlan 120. That vlan is configured with an ip of 192.168.100.1. The switch has a non routed vlan 120 which is assigned to a port. On that port I have a server (192.168.100.9) who's default gateway is the ASA's 192.168.100.1. I have a routed vlan 20 on the switch that goes out to another server (192.168.0.20). How do I make the DMZ communicate with the server's VLAN. (ping from the 100.9 to the 0.20 and vice versa) I have included a sketch of what I mean. 0.0.0.0 traffic goes to 192.168.99.1.  I'm currently on site and have been hacking away at this for hours. Maybe someone can let me know what I'm missing.
|
|
#
?
Jul 6, 2007 00:24
|
|
|
Captain, post a show ip route from that switch plz. I think the switch is just doing the routing for you, which you don't want.
|
|
#
?
Jul 6, 2007 01:13
|
|
|
Tremblay posted:Captain, post a show ip route from that switch plz. I think the switch is just doing the routing for you, which you don't want. Gateway of last resort is 192.168.99.1 to network 0.0.0.0 C 192.168.14.0/24 is directly connected, Vlan34 C 192.168.8.0/24 is directly connected, Vlan28 C 192.168.10.0/24 is directly connected, Vlan30 C 192.168.99.0/24 is directly connected, Vlan40 C 192.168.6.0/24 is directly connected, Vlan26 C 192.168.0.0/24 is directly connected, Vlan20 C 192.168.100.0/24 is directly connected, Vlan120 S* 0.0.0.0/0 [1/0] via 192.168.99.1 I set up a interface vlan on the switch as a last resort to communicate with that server. The IP is 192.168.100.2. Doing that I can ping the server on the DMZ from the switch but not from any other network.
|
|
#
?
Jul 6, 2007 01:15
|
|
|
jwh posted:You can proxy-arp to fake it (clients in 10.10/16 arp for what they think is local, gateway responds with it's own MAC), but I don't know if proxy-arp is enabled by default on pix interfaces. It probably is, because it's been like that on IOS devices forever, but I don't know for certain. If I had to guess, it's probably enabled by default, and isn't really the problem here. Proxy arp on PIX/ASA/FWSM function is based on your NAT config. Any IP address assigned to a physical, logical, or NAT address (nat (int) x.x.x.x) will cause the FW to proxy arp. Static NATs: static (real_interface,mapped_interface) mapped_address real_address Tells the FW to proxy arp for mapped_address on interface mapped_interface. Proxy arp can be disabled on a per interface basis as well (sysopt no-proxy-arp <int> [IIRC]).
|
|
#
?
Jul 6, 2007 01:18
|
|
|
TheCaptain posted:Gateway of last resort is 192.168.99.1 to network 0.0.0.0 Yeah see how: C 192.168.0.0/24 is directly connected, Vlan20 C 192.168.100.0/24 is directly connected, Vlan120 Are connected? Thats bad. That means the switch is routing and not the ASA. Statefull firewalls don't like asymetric routing. Are hosts in the DMZ initiating traffic to the inside or is it only inside hosts initiating connections? Also fix your mask, I don't think you want to have a /16 on Vlan20. You'll need a static identity nat to get this going (and an ACL), I'm assuming you want the ASA to just route the DMZ and inside nets and not NAT? Assuming that is the case: static (inside,dmz) 192.168.99.0 192.168.99.0 mask 255.255.255.0 static (dmz,inside) 192.168.100.0 192.168.100.0 mask 255.255.255.0 See my above post on how proxy arp works in case I just reversed what you are trying to do. Tremblay fucked around with this message at 01:27 on Jul 6, 2007 |
|
#
?
Jul 6, 2007 01:22
|
|
|
Tremblay posted:Yeah see how: I want the switch to do all the routing except for the DMZ Vlan. The server in the DMZ is an ISA server and needs to communicate with Exchange which is on the 20 Vlan so connections come in from the internet, to the DMZ through the ISA server which needs to talk to the 20 vlan to get to exchange. Also, I have subnet-zero enabled. That's why I have 192.168.0.0/24.
|
|
#
?
Jul 6, 2007 01:28
|
|
|
TheCaptain posted:I want the switch to do all the routing except for the DMZ Vlan. The server in the DMZ is an ISA server and needs to communicate with Exchange which is on the 20 Vlan so connections come in from the internet, to the DMZ through the ISA server which needs to talk to the 20 vlan to get to exchange. Also, I have subnet-zero enabled. That's why I have 192.168.0.0/24. Right, so what I am saying is, since you have a L3 vlan interface on the switch that resides in the DMZ subnet. The switch is currently routing between the .99 and .100 subnets and not the ASA. This is NOT what you want to happen.
|
|
#
?
Jul 6, 2007 01:36
|
|
|
Tremblay posted:Right, so what I am saying is, since you have a L3 vlan interface on the switch that resides in the DMZ subnet. The switch is currently routing between the .99 and .100 subnets and not the ASA. This is NOT what you want to happen. Thanks. Even when the 4507 was not routing, i still couldn't get through. What's the next step?
|
|
#
?
Jul 6, 2007 01:37
|
|
|
TheCaptain posted:Thanks. You need the static nats I posted above. ASA by default requires a NAT config to get traffic from one interface to another. So basically what we do is write NAT statements that essentially NAT traffic to their original IP addresses. The order of the interfaces is important since it controls which interface proxy ARPs for the subnet or host IP configured. If you flip the interface order you can wind up having the FW and hosts ARPing for the same addresses and that makes a headache. http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/index.htm I've got to head out but I'll check the thread when I get home. Tremblay fucked around with this message at 01:50 on Jul 6, 2007 |
|
#
?
Jul 6, 2007 01:43
|
|
|
Tremblay posted:You need the static nats I posted above. ASA by default requires a NAT config to get traffic from one interface to another. So basically what we do is write NAT statements that essentially NAT traffic to their original IP addresses. The order of the interfaces is important since it controls which interface proxy ARPs for the subnet or host IP configured. If you flip the interface order you can wind up having the FW and hosts ARPing for the same addresses and that makes a headache. This is fantastic, I didn't know i could use NAT to route traffic that way. I had to go for the day but I'll pick this up in the morning. I only saw half of your post before so I missed the static entries. Now that I'm home, I'm going to read up on this to speed things up tomorrow. Thanks again.
|
|
#
?
Jul 6, 2007 02:25
|
|
|
TheCaptain posted:This is fantastic, I didn't know i could use NAT to route traffic that way. I had to go for the day but I'll pick this up in the morning. I only saw half of your post before so I missed the static entries. Now that I'm home, I'm going to read up on this to speed things up tomorrow. Happy to help!
|
|
#
?
Jul 6, 2007 03:22
|
|
|
What is the typical order in which to tackle the CCNP? I've read that BSCI is a good starting point, but looking for other input.
|
|
#
?
Jul 8, 2007 17:58
|
|
|
jbusbysack posted:What is the typical order in which to tackle the CCNP? I've read that BSCI is a good starting point, but looking for other input. I think BSCI is the best place to start because the switching exam (BCMSN?) has a lot of content that deals with layer 3 switching/mls and now with the added MPLS content in what was the BCRAN exam you'd be best off having a solid routing foundation to build on. I haven't read the MPLS stuff in the CCNP since I did mine a fair while ago, but you can bet it'll have questions on MPiBGP and PE-CE routing protocols.
|
|
#
?
Jul 9, 2007 04:43
|
|
|
Alright, this is a rough outline of our network as it stands at the moment: Not pretty. We operate as a division within the university and are very decentralized with about 7 or 8 different remote sites configured in this manner all pointed back to the resources in the main building. Campus networking maintains the links between the sites and the building routers, along with the DHCP server that all our non-static clients are assigned through. Not controlling our own DHCP registration has been causing more and more administrative headaches as we are growing rapidly (Thanks for setting the Option 81 flag so nothing registers with our DNS servers!  ) and I really want VPN links between sites so everything looks physically under our control networking-wise. The other consideration is that we don't need web traffic or that other nonsense going across the VPN link when it could be forwarded to the campus building router and be handled from there, so I assume some manner of routing functionality is in order as well.So if anyone has hardware recommendations of what I should be looking at or a different way of handling this mess, I would appreciate it. Work should be footing the bill for me to get trained to take the CCNA exam in a few months, but I would like to have a long-term plan on how this is going to be corrected before that. Oh yeah, the firewalls are Juniper Netscreen boxes and I'm not sure what kind of hardware the campus networking guy are running for their routers, but I do know they have a room with some Foundry equipment in it (FastIron Workgroup and BigIron 4000 from what I have seen).
|
|
#
?
Jul 9, 2007 14:50
|
|
|
Don't know if anybody saw this over on Network World, but apparently Len Bosack has a start-up that's making a little 1U DWDM box. They have CLI manuals online: http://www.xkl.com/products/product-literature Looks kind of interesting.
|
|
#
?
Jul 9, 2007 18:08
|
|
|
code:RMA Ahoy.
|
|
#
?
Jul 11, 2007 16:56
|
|
|
Not sure if I asked this before, but this is just a curiosity. Dealing with Cat 3750G-PoE's we occasionally find ports that just won't work at Gig, for no apparent reason. The agonizingly long startup tests show nothing, then we will find a port that will work great at 10/100 but will not negotiate at gig, or work at gig if we lock it down. We tried the obvious, shut/no shut, check log, etc. Nothing comes up, or helps, save for a reload. Obviously once we have a switch full of users operating in a production environment, we can't do this. We're not terribly concerned about it, because it is just one port every so often and we just move the user to an available port, generally. The only thing we could think of is there is some problem with using a 5 Pair punch on 110 blocks, may be causeing a problem. I know it does with PoE devices, you will sort the pairs and get a power error, so we don't do that. We did have this issue show up on one of the mini GBIC ports, however. Anyone have this happen, or have any ideas? Its just a curiosity...
|
|
#
?
Jul 12, 2007 03:14
|
|
|
I'm experiencing the strangest problem. I have a network with the following configuration:  Router A is not really a router and we don't really care about it at the moment. The problem is that Router B is not sending RIP updates towards Router A. It is configured with RIP v2, classless, zubnet zero and with no split horizon. The networks configured on Router B are "network 10.31.13.0" and "network 192.168.0.0". With that config Router B is not sending any updates to Router A. I checked the "debug ip rip" and the RIP is only sending update messages to the 10.31.13.1 interface but not to the 192.168.0.0 interface. I have checked the "show ip protocols" and the 192.168.0.0 network is recognised by RIP. It is also there in the "show ip route" as a locally connected network. What is even more strange is that if I change the IP of the interfaces between Router A and B to 172.30.x.x it works just fine, sending updates to both interfaces. All of the above is leading me to believe it has something to do with the class of the networks.. But RIP shouldn't care. It is supposed to send multicasts to the interface that is not on the advertised network. It doesn't build connections or verify that there is someone to receive the multicast. It just sends them out. I know that this configuration is not a good one. I also know that setting both routers on the same network works fine. This configuration was not made by me and has to stay the same for compatability reasons. Please tell me I am missing something stupid and that I didn't just stumble onto some strange bug. Lastly, here is the config I received before doing my tests on it. code:
|
|
#
?
Jul 12, 2007 16:09
|
|
|
Partycat posted:Not sure if I asked this before, but this is just a curiosity. Dealing with Cat 3750G-PoE's we occasionally find ports that just won't work at Gig, for no apparent reason. The agonizingly long startup tests show nothing, then we will find a port that will work great at 10/100 but will not negotiate at gig, or work at gig if we lock it down. We tried the obvious, shut/no shut, check log, etc. Nothing comes up, or helps, save for a reload. Obviously once we have a switch full of users operating in a production environment, we can't do this. We're not terribly concerned about it, because it is just one port every so often and we just move the user to an available port, generally. The only thing we could think of is there is some problem with using a 5 Pair punch on 110 blocks, may be causeing a problem. I know it does with PoE devices, you will sort the pairs and get a power error, so we don't do that. We did have this issue show up on one of the mini GBIC ports, however. The only think I can figure is that you have PoE configured for the ports stuck at 10/100. PoE can't work at GigE speeds. Also is the other device capable of running GigE? Finally if it's only one port sometimes, it sounds like you might have a bad patch between end device and the port. If you have a lovely cable that can't support GigE then it will go down to 100. In any case I think its a layer 1 problem, and not necessarilly a problem with the switch.
|
|
#
?
Jul 12, 2007 17:21
|
|
|
Arkady posted:stuff Exactly what image are you running? Is this in production or in a test lab?
|
|
#
?
Jul 12, 2007 18:21
|
|
|
Tremblay posted:Exactly what image are you running? Is this in production or in a test lab? I didn't check the version, but it's safe to assume it's a very recent one. It's in a test lab. We are testing a few things for satellite communication (that's the cloud), with the Router A being a VSAT. Quickie edit: Just checked the same setup in Netsim and it does exactly the same thing; doesn't send RIP updates to 192.168.0.0 interface, but sends them to 172.31.0.0 without a problem. What is going on! 
Arkady fucked around with this message at 18:58 on Jul 12, 2007 |
|
#
?
Jul 12, 2007 18:42
|
|
|
Arkady posted:I'm experiencing the strangest problem... Then what is it? Are you running routed, gated, quagga on some server if it's not a router? Are they configured properly? Arkady posted:The problem is that Router B is not sending RIP updates towards Router A. It is configured with RIP v2, classless, zubnet zero and with no split horizon. Why why why oh why Arkady posted:I have checked the "show ip protocols" and the 192.168.0.0 network is recognised by RIP. It is also there in the "show ip route" as a locally connected network. Not the class. RIPv2 is classless. First of all you need to fix the subnet masks on the 192.168.x.x network. Secondly split horizon is still turned on from looking at your config. Thirdly you need to use major network addresses in your network statements. If you fix both ends of the link to /30's and add the network with code:edit for clarity: It doesn't even have to be /30's on both sides. You could do /8's or /24's on both sides, but they have to match. Even if you tried to use static routes, your traffic is just getting black holed. If you do a show ip route on router A, you won't see 192.168.0.0/16 as a directly connected network, because your /30 you have on the other side is encompassed in that. atticus fucked around with this message at 19:27 on Jul 12, 2007 |
|
#
?
Jul 12, 2007 19:15
|
|
|
atticus posted:Then what is it? Are you running routed, gated, quagga on some server if it's not a router? Are they configured properly? The Router A is a VSAT - Satellite router of sorts. It is configured properly and all I really need is for Router B to send a RIP update to it. The rest should be easy. I tried testing without split horizon (not shown in this config) because this is a going to be connected to an isolated satellite network, so no fear of loops and such. atticus posted:Not the class. RIPv2 is classless. First of all you need to fix the subnet masks on the 192.168.x.x network. Secondly split horizon is still turned on from looking at your config. Thirdly you need to use major network addresses in your network statements. If you fix both ends of the link to /30's and add the network with I know RIP v2 is classless, but for some reason class is coming into the calculation in this case. Putting the two interfaces on the same network does solve the problem, but that's not the issue. The issue is why doesn't the router advertise RIP to a 192.168.0.0 network. You see, I need to leave the interface of Router A as a /30 and I need to leave the interface on Router B as /16. It works fine for all networks I have tested so far except 192.168.0.0 atticus posted:edit I am not sure why do they have to match. The interface can't recognise the other interface's IP and mask. RIP doesn't care for classes or neighbors. It just sends the updates. As for the masks having to be the same; I'm not sure they do. Ping goes fine between differently subnetted networks. Why do you think it would be a problem? Arkady fucked around with this message at 19:43 on Jul 12, 2007 |
|
#
?
Jul 12, 2007 19:41
|
|
|
Powercrazy posted:The only think I can figure is that you have PoE configured for the ports stuck at 10/100. PoE can't work at GigE speeds. Also is the other device capable of running GigE? Finally if it's only one port sometimes, it sounds like you might have a bad patch between end device and the port. If you have a lovely cable that can't support GigE then it will go down to 100. That is possible. I mentioned using the 5 pair punch which does cause PoE problems on devices trying to draw the power. If it somehow turns it 'on', that may work. I don't think I examined closely an interface exhibiting this behavior enough to notice any comments about PoE. When we find a failure at a workstation, I will test the port, direct attached with a gig enabled laptop, and known good patch, and find that it will flop between "Acquiring address" and "Disconnected". Other times it will sit at disconnected and at some point in time it will appear as being at 100M and start working. Locking the port at 100M, is instant. However, we did have this issue with one of the mini GBiC ports, for a fibre uplink. Last I checked you can't run power over fibre, so unless the switch becomes confused for some reason that shouldn't play into it. It hasn't come up recently, and we have been running SEE2 on the IOS, instead of SEB or SED, so maybe it was some odd glitch that is no longer present. It was sort of a running joke that you had to wait 5 minutes for a port test that did not actually seem to "test" anything when we had what would appear to be bad ports, but they may not actually be bad.
|
|
#
?
Jul 12, 2007 20:01
|
|
|
Partycat posted:
It's very possible that it was a code problem. But I'm still suspicious of why setting the port to 100 would cause it to come up immediately unless PoE was enabled somehow. Strange. As far as the fiber problem, Cisco devices are pretty specific about what SFP's you use, so if it wasn't that, then it could be any number of things.
|
|
#
?
Jul 12, 2007 20:40
|
|
|
Arkady posted:The issue is why doesn't the router advertise RIP to a 192.168.0.0 network. R2#sh run | b router rip router rip version 2 network 192.168.0.0 ^Z R2#sh ip proto Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 0 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 2, receive version 2 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 192.168.0.0 Routing Information Sources: Gateway Distance Last Update Distance: (default is 120) R2#sh ip rip data R2#sh run int ser1/0 Building configuration... Current configuration : 88 bytes ! interface Serial1/0 ip address 192.168.4.26 255.255.0.0 serial restart-delay 0 end R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router rip R2(config-router)#network 192.168.4.0 R2(config-router)#exit *Jul 12 15:21:57.495: RIP: add Serial1/0 to RIP idb list *Jul 12 15:21:57.499: RIP-DB: redist 192.168.0.0/16(metric 0, last interface Serial1/0) to RIP *Jul 12 15:21:57.503: RIP-DB: Get redist for network 192.168.0.0 *Jul 12 15:21:57.503: RIP-DB: adding 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 to RIP database *Jul 12 15:21:57.507: RIP-DB: add 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 (donot_age) *Jul 12 15:21:57.511: RIP-DB: Adding new rndb entry 192.168.0.0/16 R2(config)#exit R2# *Jul 12 15:22:00.651: %SYS-5-CONFIG_I: Configured from console by console *Jul 12 15:22:03.675: RIP-TIMER: age timer expired R2# R2#sh ip rip data 192.168.0.0/16 directly connected, Serial1/0 R2# R2(config)#access-list 1 permit any R2(config)#exit R2#debug ip pack 1 IP packet debugging is on for access list 1 R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)# R2(config)#int ser1/0 R2(config-if)#shut R2(config-if)#no shut R2(config-if)#exit R2(config)# *Jul 12 15:26:26.427: rip_route_adjust for Serial1/0 going down *Jul 12 15:26:26.431: RIP: Removing everything from Serial1/0's retrans queue and stopping the retrans timer. *Jul 12 15:26:26.435: RIP-DB: flush route of 192.168.0.0/16 on Serial1/0 *Jul 12 15:26:26.435: RIP-DB: Remove 192.168.0.0/16, (metric 4294967295) via 0.0.0.0, Serial1/0(permanent) *Jul 12 15:26:26.563: RIP-DB: redist 192.168.0.0/16(metric 0, last interface Serial1/0) to RIP *Jul 12 15:26:26.563: RIP-DB: Get redist for network 192.168.0.0 *Jul 12 15:26:27.047: RIP-DB: redist 192.168.0.0/16(metric 0, last interface Serial1/0) to RIP *Jul 12 15:26:27.051: RIP-DB: Get redist for network 192.168.0.0 *Jul 12 15:26:27.051: RIP-DB: adding 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 to RIP database *Jul 12 15:26:27.055: RIP-DB: add 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 (donot_age) *Jul 12 15:26:27.059: rip_route_adjust for Serial1/0 coming up *Jul 12 15:26:27.063: IP: s=192.168.4.26 (local), d=224.0.0.9 (Serial1/0), len 52, sending broad/multicast *Jul 12 15:26:27.067: RIP: sending request on Serial1/0 to 224.0.0.9
|
|
#
?
Jul 12, 2007 20:46
|
|
|
jwh posted:192.168/16 is classful /24 space, so your third octet needs to play ball with what's configured on the interface. RIPv2 is classless, but it's configuration isn't. The reason your 10/8 and 172.16/16 attempts worked, is because they were accidentally the correct classful mask. Ah thanks jwh - this is exactly what i was trying so hard to figure out how to say. Again, you're awesome.
|
|
#
?
Jul 12, 2007 21:54
|
|
|
Powercrazy posted:It's very possible that it was a code problem. But I'm still suspicious of why setting the port to 100 would cause it to come up immediately unless PoE was enabled somehow. The cable tester we are using shows no PoE on these ports being on, unless the switch thinks it is. The fibre issue cleared with a switch reload, so whatever the hardware setup was, seemed to be fine.
|
|
#
?
Jul 13, 2007 16:48
|
|
|
jwh posted:192.168/16 is classful /24 space, so your third octet needs to play ball with what's configured on the interface. RIPv2 is classless, but it's configuration isn't. The reason your 10/8 and 172.16/16 attempts worked, is because they were accidentally the correct classful mask. I'm still not entirely sure why doesn't the router recognise the 192.168.4.26 interface in the 192.168 /16 network. Are you saying that even though the network is /16, the interface is being recognised with the /24 mask? Also, what debug command did you use? Still, the solution you suggested works perfectly. Thank you very much. Arkady fucked around with this message at 22:48 on Jul 13, 2007 |
|
#
?
Jul 13, 2007 22:43
|
|
|
|
| # ? May 31, 2024 11:59 |
|
|
Arkady posted:I'm still not entirely sure why doesn't the router recognise the 192.168.4.26 interface in the 192.168 /16 network. Are you saying that even though the network is /16, the interface is being recognised with the /24 mask? Well, I'm no expert, particularly on RIP, but from what I was able to test in a lab, the reason IOS didn't pick up on the fact that you had an interface covered by the 192.168.0.0 statement, is because the RIP configuration is approaching things with a classful mentality. This seems to make a certain sense if you consider that RIPv1 was a classful protocol, and maybe for historical reasons, the IOS configuration was never retrofitted. So in other words, it looks to me like IOS uses the RIP network statement along classful boundaries. Even though your interface is technically 'covered' by the larger supernet of 192.168.0.0/16, IOS is considering 192.168.0.0 classfully, which would match the 192.168.0 portion of the network, because 192.168 is part of class C or /24 classful address space. That's my theory anyway, it seems to be true, even if it is a little brain-dead on the part of IOS. Debugging commands were 'debug ip rip event' and 'debug ip rip database' I think, and then the 'debug ip packet' example that's included in the text I wrote. Be careful with debug ip packet, because I have successfully killed production devices with it.
|
|
#
?
Jul 13, 2007 23:41
|
|