While doing a routing lab for CCNA...

J

jadams

2[H]4U
Joined
Mar 14, 2010
Messages
4,086
I stumbled onto something that has me scratching my head. I actually made a mistake in the lab but it still worked.

http://i.imgur.com/xyE0Bwz.png

SCENARIO: VLAN40 pc pings vlan 100 interface on switch and recieves reply. Notice the switch is configured with 10.0.4.1 as its gw.

Couple things I'm confused about.

1. How is the reply making its way back to 10.0.4.1 (its configured gw) and onto 10.0.4.2 w/ out going through 192.168.2.1 first?
2. Maybe the switch is smart enough to know that 10.0.4.1 is on another vlan and sends it out accordingly. However.... how is that switch even capable of doing this sort of "routing"? Isnt the point of vlan's to NOT allow that type of behavior?
 
I think I know what is happening though can you post a screencap of the tracert that you're seeing?
 
Because 192.168.2.1 and 10.0.4.1 are on the same routing device, the routing becomes transparent.. almost like being switched somewhat. I'm not seeing anything out of the ordinary. You're just not seeing a route of 10.0.4.1 -> 192.168.2.1 -> 192.168.2.2. You won't when the gateways are on the same router.
 
But the switch doesn't have a return route, it can't ping 10.0.4.1, why can it route through it? (Not the OP, btw). I think it's a goofy packet tracer thing.

[Edit] I take that back, I recreated in PT, and it CAN ping 10.0.4.1. The switch seems to be guessing it's next hop, even though it's default gateway should not be reachable. I even changed the IP of the router's fa0/0.100 interface to a 192.168.2.42, and the switch immediately takes that route instead.
 
Last edited:
aaronearles said:
But the switch doesn't have a return route, it can't ping 10.0.4.1, why can it route through it? (Not the OP, btw). I think it's a goofy packet tracer thing.

[Edit] I take that back, I recreated in PT, and it CAN ping 10.0.4.1. The switch seems to be guessing it's next hop, even though it's default gateway should not be reachable. I even changed the IP of the router's fa0/0/100 interface to a 192.168.2.42, and the switch immediately takes that route instead.
Click to expand...

nevermind :D
 
It's packet tracer BS, I just recreated in IOU and it does not respond, as expected.
 
shade91 said:
Because 192.168.2.1 and 10.0.4.1 are on the same routing device, the routing becomes transparent.. almost like being switched somewhat. I'm not seeing anything out of the ordinary. You're just not seeing a route of 10.0.4.1 -> 192.168.2.1 -> 192.168.2.2. You won't when the gateways are on the same router.
Click to expand...

So lets create this on a PC isntead of a switch

PC -----> Router ----> PC1

PC0:
IP address 192.168.2.2
GW: 10.0.4.1

Router:
INT0 connected to PC0: 192.168.2.1
INT1 connected to pc1: 10.0.4.1

PC1:
IP 10.0.4.2
GW: 10.0.4.1

In this config, PC0 should not be able to ping PC1

Or am I missing something?
 
RTR1
e0/0 192.168.2.2/24 - Physically connected to RTR2 e0/0
no ip routes, no ip default-gateway

RTR2
e0/0192.168.2.1/24 - Physically connected to RTR1 e0/0
lo0 10.0.4.1/24
no ip routes, no ip default-gateway

Code: 
RTR2#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                192.168.2.1     YES manual up                    up      
Ethernet0/1                unassigned      YES unset  administratively down down    
Ethernet0/2                unassigned      YES unset  administratively down down    
Ethernet0/3                unassigned      YES unset  administratively down down    
Loopback0                  10.0.4.1        YES manual up                    up
Code: 
RTR1#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                192.168.2.2     YES manual up                    up      
Ethernet0/1                unassigned      YES unset  administratively down down    
Ethernet0/2                unassigned      YES unset  administratively down down    
Ethernet0/3                unassigned      YES unset  administratively down down    
RTR1#ping 192.168.2.1 sou
RTR1#ping 192.168.2.1 source 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
RTR1#ping 10.0.4.1 source 192.168.2.2   

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.2 
.....
Success rate is 0 percent (0/5)
RTR1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

RTR1(config)#ip route 10.0.0.0 255.0.0.0 192.168.2.1
RTR1(config)#exit
RTR1#ping 10.0.4.1 source 192.168.2.2
*Aug 11 15:25:16.631: %SYS-5-CONFIG_I: Configured from console by console
RTR1#ping 10.0.4.1 source 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
RTR1#
Moral of the story: PacketTracer sucks...
 
jadams said:
So lets create this on a PC isntead of a switch

PC -----> Router ----> PC1

PC0:
IP address 192.168.2.2
GW: 10.0.4.1

Router:
INT0 connected to PC0: 192.168.2.1
INT1 connected to pc1: 10.0.4.1

PC1:
IP 10.0.4.2
GW: 10.0.4.1

In this config, PC0 should not be able to ping PC1

Or am I missing something?
Click to expand...

Just to be safe i changed the GW on my pc to the WAN of my router. No internets, as I expected.
 
jadams said:
I'm pretty sure this is the answer:

http://www.reddit.com/r/ccna/comments/2d8eby/im_puzzled_as_to_how_this_is_working_ip_sending/cjn4glx

Disabled proxy arp on both sub interfaces on the router. No more ping replies.

Hot pot of coffee!! I knew I wasnt going insane. I almost had to call into question everything I knew about networking.
Click to expand...

lol, I saw your message prior to edit and was racing to reconfigure in PT, you beat me to it. I think this wont work in my IOU example because it needs a third device to generate the ARP request, the router wont do it on it's own. Glad you posted this, I learned something. Thanks!
 
And just to be thorough... After disabling proxy arp I changed the GW on the switch to 192.168.2.1. Pings restored again, as it should, but this time not utilizing proxy arp.
 
Proxy Arp is, as you have found out, the cause of your issues. I still can't understand why this technology even exists and even worse, is enabled. It is just a horrible crutch for bad network designs, a bit like the APIPA-protocol. The more I read about it, the more this is confirmed. http://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/13718-5.html

I got bitten by this my self in a larger network once. It took a day to find out why the hell packets weren't routed at the gateway, but still partially reached some of their destinations (but not all because of ACLs that wasn't intended for routing happening at that switch). I had to do insert a packet capturing device and manually correlate ARP tables to MAC-addresses to notice that the core switch answered to packets originally destined for the gateway with its own MAC-adress and did proxy arp. It only managed to poison a signle hosts ARP-table in that subnet, so troubleshooting was very hard because it made absolutely no sense as you would naturally think that the issue was with that single host, not the core infrastructure.
 
You must log in or register to reply here.
Back
Top