How to stop static routes looping

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-bbapuck.nether.net
ht
tps://puck.nether.net/mailman/listinfo/cisco-bba

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-bbapuck.nether.net
> ht
tps://puck.nether.net/mailman/listinfo/cisco-bba
>
>   
_______________________________________________
cisco-bba mailing list
cisco-bbapuck.nether.net
ht
tps://puck.nether.net/mailman/listinfo/cisco-bba