I recently implemented RPF checking on 2 interfaces that are being load
balanced:
interface Serial2/4:0
bandwidth 1984
ip address 192.11x.75.145 255.255.255.252
ip verify unicast reverse-path
ip load-sharing per-packet
encapsulation ppp
no ip route-cache
no cdp enable
!
interface Serial2/7:0
bandwidth 1984
ip address 192.11x.75.65 255.255.255.252
ip verify unicast reverse-path
ip load-sharing per-packet
encapsulation ppp
no ip route-cache
no cdp enable
I found I was getting drops as follows:
24w3d: CEF-Drop: Packet from 192.11x.75.66 via Serial2/7:0 -- unicast rpf check
24w3d: CEF-Drop: Packet from 192.11x.75.146 via Serial2/4:0 -- unicast rpf
check
So I did a check on the routing:
Access-5#sho ip rou 192.11x.75.66
Routing entry for 192.11x.75.66/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via ospf 1
Advertised by ospf 1 subnets
Routing Descriptor Blocks:
* directly connected, via Serial2/4:0
Route metric is 0, traffic share count is 1
Access-5#sho ip rou 192.11x.75.65
Routing entry for 192.11x.75.64/30
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via ospf 1
Advertised by ospf 1 subnets
Routing Descriptor Blocks:
* directly connected, via Serial2/7:0
Route metric is 0, traffic share count is 1
I find this to be very strange. So I also checked the CEF table:
192.11x.75.64/30 attached Serial2/7:0
192.11x.75.64/32 receive
192.11x.75.65/32 receive
192.11x.75.66/32 attached Serial2/4:0
192.11x.75.67/32 receive
192.11x.75.144/30 attached Serial2/4:0
192.11x.75.144/32 receive
192.11x.75.145/32 receive
192.11x.75.146/32 attached Serial2/7:0
192.11x.75.147/32 receive
Is this normal? If so, RPF checking should state that load balanced
interfaces can't be RPF checked (I have added a RPF ACL to bypass the problem).
Thanks,
Hank
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:32 EDT