[cisco-bba] How to stop static routes looping
bbc at misn.com
Fri Mar 7 09:13:02 EST 2008
Can anyone testify as to whether there are any potential pitfalls of
configuring uRPF (ip verity unicast reverse-path) in this application?
I recall, from the past, that "ip verity unicast reverse-path" can cause
undesirable behavior in certain circumstances. But, that may not be the
Oliver Boehmer (oboehmer) wrote:
> Andy Saykao <> wrote on Friday, March 07, 2008 8:13 AM:
>> Hi There,
>> Just wondering if there's a way to stop this sort of routing loop
>> from happening.
>> Say for example we have a customer who has a PPP connection and when
>> they login they get an IP of 192.168.1.1.
>> They now want an additional /29 subnet and so through Radius we
>> assign then a /29 (eg: 192.168.2.0/29).
>> Internet -> ISP (LNS) -> Cust Route (PPP) -> Cust additional /29
>> I gather the static route for this additional /29 subnet is injected
>> to the router from Radius becauses there's no hard set "ip route"
>> command on the LNS and OSPF then restributes this static route using
>> the command "redistribute static subnets" as seen in the "sh ip
>> route" command below.
>> lns#sh ip route 192.168.2.0
>> Routing entry for 192.168.2.0/29
>> Known via "static", distance 1, metric 0
>> Redistributing via ospf 100
>> Advertised by ospf 100 subnets
>> Routing Descriptor Blocks:
>> * 192.168.1.1
>> Route metric is 0, traffic share count is 1
>> My problem is that if the customer doesn't use the additional /29
>> subnet and traffic is destined for the additional /29 subnet we get a
>> routing loop happening because the customer's router sends the packet
>> out it's default route back to the ISP's LNS and then the ISP's LNS
>> thinking it has a static route sends it back to the customer's router
>> and round and round we go til the TTL expires.
> Right. But why do you route it if the customer doesn't use it? Then the
> loop isn't bad ;-)
>> Can this routing loop be stopped from the ISP (LNS) side???
> Well, not really. However, you want to consider applying uRPF (ip verify
> unicast reverse-path) to the virtual-access/virtual-template which will
> cause the "looped" packet to be dropped as it is sourced from an IP not
> being reachable over this interface. You want to do this anyway to
> prevent spoofing..
> cisco-bba mailing list
> cisco-bba at puck.nether.net
More information about the cisco-bba