ARP is sourced from loopback address

Joe Maimon jmaimon at ttec.com
Mon Jan 30 23:11:23 UTC 2012


Thanks for the reply.

Yes, it does appear to have the correct mac.


root at debian31:~# tcpdump -e -n -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:54:17.882537 00:03:fd:03:38:08 > 00:0c:29:b8:2a:14, ethertype IPv4 
(0x0800), length 114: 69.90.15.224 > 216.222.144.24: ICMP echo request, 
id 161, seq 4, length 80
12:54:18.084320 00:0c:29:b8:2a:14 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: Request who-has 192.168.76.1 tell 209.54.140.64, 
length 28
12:54:19.083580 00:0c:29:b8:2a:14 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: Request who-has 192.168.76.1 tell 209.54.140.64, 
length 28
12:54:19.838376 00:03:fd:03:38:08 > 00:0c:29:b8:2a:14, ethertype IPv4 
(0x0800), length 407: 69.90.15.224.179 > 216.222.144.24.60714: Flags 
[P.], seq 4062306194:4062306547, ack 170308540, win 16365, length 353: 
BGP, length: 353
12:54:20.083649 00:0c:29:b8:2a:14 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: Request who-has 192.168.76.1 tell 209.54.140.64, 
length 28

^C


root at debian31:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:b8:2a:14
           inet addr:192.168.76.16  Bcast:192.168.76.255  Mask:255.255.255.0



Keegan Holley wrote:
> Even though TCP dump doesn't show it the ARP packets should have a
> source mac address that is reachable on the link.  I think the reply
> is unicast to that mac address regardless of the IP in the request.
> Otherwise the receiving station would have to do an arp request for
> the source IP in the packet before it replied, in order to reply that
> station would need to have the very mapping it just requested making
> the whole thing useless.   I've never seen arp sourced from a
> non-local interface IP unless there was some sort of tunnel or
> bridging configured, but then again I don't spend my days staring at
> ARP packets so I could be missing something.
>
>
> 2012/1/30 Joe Maimon<jmaimon at ttec.com>:
>>
>> Hey All,
>>
>> Anycast related.
>>
>> Is this normal behavior? Whats the workaround? Why havent I run into this
>> before?
>>
>> 192.168.76.1 is a HSRP address on a ring of routers transiting a private non
>> routed vlan to the service addresses hosted on systems that have independent
>> management interfaces.
>>
>> Best,
>>
>> Joe
>>
>>
>> root at debian31:~# ifconfig lo:0
>> lo:0      Link encap:Local Loopback
>>           inet addr:209.54.140.64  Mask:255.255.255.255
>>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>>
>> root at debian31:~# ip rule list
>> 0:      from all lookup local
>> 32764:  from 209.54.140.0/24 lookup pbr1-exit
>> 32765:  from 216.222.144.16/28 lookup pbr1-exit
>> 32766:  from all lookup main
>> 32767:  from all lookup default
>> root at debian31:~# ip route list table pbr1-exit
>> default via 192.168.76.1 dev eth1
>> 192.168.34.0/24 dev eth1  scope link  src 192.168.76.16
>> 192.168.76.0/24 dev eth1  scope link  src 192.168.76.16
>> root at debian31:~# tcpdump -i eth1
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
>>
>> 11:08:09.053943 ARP, Request who-has 192.168.76.1 tell 209.54.140.64, length
>> 28
>> 11:08:10.035126 IP noc08rt08.noc08.chl.net>  209.54.140.64: ICMP echo
>> request, id 517, seq 0, length 80
>> 11:08:10.051276 ARP, Request who-has 192.168.76.1 tell 209.54.140.64, length
>> 28
>> 11:08:11.052548 ARP, Request who-has 192.168.76.1 tell 209.54.140.64, length
>> 28
>> 11:08:12.035964 IP noc08rt08.noc08.chl.net>  209.54.140.64: ICMP echo
>> request, id 517, seq 1, length 80
>> ^C
>>
>> root at debian31:~# ip neigh
>> fe80::230:71ff:fe3b:6808 dev eth0 lladdr 00:30:71:3b:68:08 router STALE
>> 192.168.76.1 dev eth1  FAILED
>> 192.168.34.254 dev eth0 lladdr 00:11:93:04:7a:1b DELAY
>> 192.168.34.48 dev eth0 lladdr 00:0c:29:fd:64:8a STALE
>>
>> root at debian31:~# uname -a
>> Linux debian31 3.2.0-1-686-pae #1 SMP Tue Jan 24 06:09:30 UTC 2012 i686
>> GNU/Linux
>>
>> root at debian31:~# ping 192.168.76.1
>> PING 192.168.76.1 (192.168.76.1) 56(84) bytes of data.
>> 64 bytes from 192.168.76.1: icmp_req=1 ttl=255 time=2.95 ms
>> ^C
>> --- 192.168.76.1 ping statistics ---
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 2.952/2.952/2.952/0.000 ms
>> root at debian31:~# ip neigh
>> fe80::230:71ff:fe3b:6808 dev eth0 lladdr 00:30:71:3b:68:08 router STALE
>> 192.168.76.1 dev eth1 lladdr 00:00:0c:9f:f0:01 REACHABLE
>> 192.168.34.254 dev eth0 lladdr 00:11:93:04:7a:1b REACHABLE
>> 192.168.34.48 dev eth0 lladdr 00:0c:29:fd:64:8a STALE
>> 192.168.76.2 dev eth1 lladdr 00:b0:4a:9e:54:00 STALE
>> root at debian31:~# !tcp
>> tcpdump -i eth1
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 11:12:22.476479 IP noc08rt08-l0.noc08.chl.net>  209.54.140.64: ICMP echo
>> request, id 518, seq 0, length 80
>> 11:12:22.476572 IP 209.54.140.64>  noc08rt08-l0.noc08.chl.net: ICMP echo
>> reply, id 518, seq 0, length 80
>> 11:12:22.479495 IP noc08rt08-l0.noc08.chl.net>  209.54.140.64: ICMP echo
>> request, id 518, seq 1, length 80
>> 11:12:22.479533 IP 209.54.140.64>  noc08rt08-l0.noc08.chl.net: ICMP echo
>> reply, id 518, seq 1, length 80
>> 11:12:22.484346 IP noc08rt08-l0.noc08.chl.net>  209.54.140.64: ICMP echo
>> request, id 518, seq 2, length 80
>> 11:12:22.484392 IP 209.54.140.64>  noc08rt08-l0.noc08.chl.net: ICMP echo
>> reply, id 518, seq 2, length 80
>> 11:12:22.487670 IP noc08rt08-l0.noc08.chl.net>  209.54.140.64: ICMP echo
>> request, id 518, seq 3, length 80
>> 11:12:22.487705 IP 209.54.140.64>  noc08rt08-l0.noc08.chl.net: ICMP echo
>> reply, id 518, seq 3, length 80
>> 11:12:22.490639 IP noc08rt08-l0.noc08.chl.net>  209.54.140.64: ICMP echo
>> request, id 518, seq 4, length 80
>> 11:12:22.490675 IP 209.54.140.64>  noc08rt08-l0.noc08.chl.net: ICMP echo
>> reply, id 518, seq 4, length 80
>> ^C
>>
>>
>>
>>
>
>




More information about the NANOG mailing list