IP SLA RESPONDER and conflict ip addresses

Mark_Frayhard · ‎09-09-2012

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.

Peter Paluch · ‎09-09-2012

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