09-09-2012 06:02 AM - edited 03-07-2019 08:46 AM
Hi.
I have a network topology which you can see on image. All routers are Cisco 3745 with IOS (C3745-ADVENTERPRISEK9-M), Version 12.4(12). SW1 is L3-switch Cisco Catalyst WS-C3560E-24TD with IOS (C3560E-UNIVERSALK9-M 12.2(58)SE2).
Configurations:
R1
interface Loopback0
ip address 1.1.1.1 255.255.255.0
interface FastEthernet0/0
ip address 192.168.146.1 255.255.255.0
ip route 0.0.0.0 0.0.0.0 192.168.146.4
ip sla monitor 1
type echo protocol ipIcmpEcho 7.7.7.7 source-interface Loopback0
timeout 100
frequency 1
ip sla monitor schedule 1 start-time now life forever
R4
interface Loopback0
ip address 4.4.4.4 255.255.255.0
interface FastEthernet0/0
ip address 192.168.146.4 255.255.255.0
interface Serial0/1
ip address 192.168.45.4 255.255.255.0
clockrate 64000
ip route 0.0.0.0 0.0.0.0 192.168.45.5
ip route 1.1.1.1 255.255.255.255 192.168.146.1
ip route 6.6.6.6 255.255.255.255 192.168.146.6
ip http client source-interface Loopback0
R5
interface Loopback0
ip address 5.5.5.5 255.255.255.0
interface FastEthernet0/0
ip address 192.168.57.5 255.255.255.0
interface Serial0/1
ip address 192.168.45.5 255.255.255.0
clockrate 64000
ip route 7.7.7.7 255.255.255.255 192.168.57.7
ip route 0.0.0.0 0.0.0.0 192.192.45.4
key chain OER
key 1
key-string CISCO
oer master
keepalive 5
logging
learn
throughput
delay
protocol tcp port 80 src
protocol 1
protocol udp port range 16384 32767 src
periodic-interval 5
monitor-period 3
border 5.5.5.5 key-chain OER
interface FastEthernet0/0 internal
interface Serial0/1 external
oer border
local Loopback0
master 5.5.5.5 key-chain OER
R6
interface Loopback0
ip address 6.6.6.6 255.255.255.0
interface FastEthernet0/0
ip address 192.168.146.6 255.255.255.0
ip route 0.0.0.0 0.0.0.0 192.168.146.4
ip sla monitor 2
type jitter dest-ipaddr 7.7.7.7 dest-port 16384 source-ipaddr 6.6.6.6 codec g729a codec-numpackets 10 codec-interval 10
ip sla monitor schedule 2 start-time now life forever
SW1
enable password cisco
ip routing
interface Vlan57
ip address 192.168.57.7 255.255.255.0
interface Loopback0
ip address 7.7.7.7 255.255.255.0
interface GigabitEthernet0/23
switchport access vlan 57
interface GigabitEthernet0/24
no switchport
ip address 10.1.42.40 255.255.255.0
ip route 0.0.0.0 0.0.0.0 192.168.57.5
ip http server
ip http path flash:
ip sla responder
line vty 0 15
password cisco
login
In same time on R4 I enter command "copy http://cisco:cisco@7.7.7.7/c3560e-universalk9-mz.122-58.SE2.bin null:"
After that I have problem. When PC with OS Windows 7 begins to work in corporate network, it sees "coflict ip addresses" and doesn't work with network. I've used wireshark and seen, when the PC send arp request a SW1 always send arp reply (see attached file). I think problem with command "ip sla responder", but I haven't searched information about it and I want understand this is bug or normal functioning.
There isn't problem with Windows XP, because XP send no arp request, but gratuitous arp request and SW1 doesn't reply.
Thank you beforehand.
09-09-2012 06:38 AM
Hello Maksim,
I do not believe that this problem is related to the configuration of the ip sla responder on SW1 - after all, try removing that command for a while and see if the problem with Windows7 goes away. If not, the problem lies elsewhere.
I primarily wonder why SW1 always responds to ARP queries even if the address being searched for is not configured on SW1. This definitely seems like Proxy ARP kicking in, and I have a theory how that might happen:
As you surely know, the Proxy ARP is a technique in which a station simply ARPs for the destination IP it wants to talk to, and this IP is either directly connected and answers to this ARP broadcast, or it is on a different subnet, and in that case, the router will respond instead. The station does not have a default gateway configured and relies completely on the ARP. The reason why the router does not respond all the time, even if the destination IP on the same subnet, is simple: the router always looks at the Target IP field in the incoming ARP Request. If the Target IP is in the same network as the interface on which the ARP Request was received, the router knows that the intended recipient is on the same network and hence it will answer itself. Therefore, the router won't respond. However, if the Target IP is in a different network, the router knows that it must respond with its own MAC address placed into an ARP Reply.
If you have a close look on the ARP Request packets you have captured, their Target IP is set to 0.0.0.0 all the time. This seems to break the logic of choosing whether to send an ARP Reply from the router: the IP address 0.0.0.0 surely does not belong into any directly connected network of the SW1, so the Proxy ARP quite naively jumps into action and responds.
I suggest trying configuring the no ip proxy-arp on the Gi0/24 interface of SW1. Please give it a try and see if it helps. The Proxy ARP mechanism is only rarely needed in our networks and its deactivation should not pose any limitations for you.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide