Re: [nsp] RPF checking bug?

From: Andrey Kostin (ankost@east.ru)
Date: Mon Feb 11 2002 - 04:36:29 EST


I think this is normal because traffic for connected intrfaces is not load
balanced. I guess, the packet being dropped by rpf check has been sourced
from router on the other end of balanced link and destinied to network
behind local router. From remote router view route to network behind peer is
balanced, but from local router view source address is not balanced because
source is directly connected, output from sh ip route 192.11x.75.66 and
192.11x.75.65 explains this.
Hope I was clear enough :)
---------------
Andrey Kostin ankost@office.east.ru +7-095-956-4951 ANKOST-RIPN
East Connection ISP, Moscow, Russia. http://www.east.ru

----- Original Message -----
From: "Hank Nussbacher" <hank@att.net.il>
To: <cisco-nsp@puck.nether.net>
Sent: 11 февраля 2002 г. 9:20
Subject: [nsp] RPF checking bug?

> 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