[cisco-bba] How to stop static routes looping

Bryan Campbell 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 
case anymore.



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 
>> They now want an additional /29 subnet and so through Radius we
>> assign then a /29 (eg: 
>> Internet -> ISP (LNS) -> Cust Route (PPP) -> Cust additional /29
>> subnet 
>> 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
>> Routing entry for
>>   Known via "static", distance 1, metric 0
>>   Redistributing via ospf 100
>>   Advertised by ospf 100 subnets
>>   Routing Descriptor Blocks:
>>   *
>>       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..
> 	oli
> _______________________________________________
> cisco-bba mailing list
> cisco-bba at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

More information about the cisco-bba mailing list