[cisco-bba] How to stop static routes looping

[Bryan Campbell]

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.

Thanks!

Bryan


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
>> 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 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..
>
> 	oli
> _______________________________________________
> cisco-bba mailing list
> cisco-bba at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba
>
>