From: Alexander Arsenyev (GU/ETL) (alexander.arsenyev@ericsson.com)
Date: Thu Jun 16 2005 - 21:47:55 GMT-3
Hello,
This is expected behaviour. If CAT1 advertises 3.3.3.0/24 to R4 then R4 knows that
3.3.3.0/24 is reachable via e0/1. Now, when R4 sends ARP request to e0/0.4, R7 replies
due to 3.3.3.0/24 being also configured on R7 and proxy-arp being ON by default. R4 receives
ARP reply from R7 and refers to own routing table. It finds that 3.3.3.0/24 is
reachable via e0/1, not e0/0.4, and drops the ARP reply.
See http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122tcr/122tdbr/dbftarap.htm#wp1053103 and scroll down to read about 5th packet.
HTH,
Cheers
Alex
#13405
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
gladston@br.ibm.com
Sent: 15 June 2005 16:39
To: ccielab@groupstudy.com
Subject: ARP and PBR
Hi,
Do you know why IOS would filter arp reply? (version is 12.2T, 2600)
Net 3.3.3.0 is configured on R7 and CAT1.
CAT1 advertises net 3.3.3.0 to R4.
R4 is configured to PBR traffic destinated to 3.3.3.0 to e0/0.4, when origin is R1.
R7-------(e0/0.4)R4(e0/1)------CAT1
|
|
R1
PBR is working fine. R7 receives ARP request and send ARP reply.
But R4 is filtering the ARP reply from R7:
R4#
*Mar 1 03:45:12: IP ARP rep filtered src 3.3.3.3 0000.0c3b.d6a9, dst 142.20.44.4 0030.94d8.fde0 wrong cable, interface Ethernet0/0.4
*Mar 1 03:45:14: IP ARP: sent req src 142.20.44.4 0030.94d8.fde0,
dst 3.3.3.3 0000.0000.0000 Ethernet0/0.4
*Mar 1 03:45:14: IP ARP rep filtered src 3.3.3.3 0000.0c3b.d6a9, dst 142.20.44.4 0030.94d8.fde0 wrong cable, interface Ethernet0/0.4
Rack2R4(config-if)#do deb arp
*Mar 1 03:45:16: IP ARP: sent req src 142.20.44.4 0030.94d8.fde0,
dst 3.
Net 142.20.44.0 is the net between R7 and R4.
I am not using 'set ip next-hop..' under PBR route-map because I would like to discover the reason of this behavior when using 'set interface...'
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3