[cisco-bba] How to stop static routes looping

Andy Saykao andy.saykao at staff.netspace.net.au
Mon Mar 10 21:03:26 EDT 2008


In reply to Message 2 below, the route is injected into the routing
table by radius when the customer successfully logs on. Whether they are
using the additional subnet or not is up to the customer to configure
(the route to the additional subnet is there for them to use). We have
this issue because a customer gets charged for all traffic that comes
into their network. So if you can imagine that if data packets are
bouncing in and out of the customer's network and back into the ISP's
network because they haven't set up their additional subnet, they will
incur this usage when the data packet enters their network again and
will often dispute this usage. 

>From the ISP's side, is there something we can do to stop this sort of
routing loop. Oliver has suggested applying uRPF (ip verify unicast
reverse-path) to the virtual-access/virtual-template but I am yet to
test this out.

Cheers.

Andy

-----

Message: 2
Date: Fri, 7 Mar 2008 09:06:58 +0100
From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
Subject: Re: [cisco-bba] How to stop static routes looping
To: "Andy Saykao" <andy.saykao at staff.netspace.net.au>,
	<cisco-bba at puck.nether.net>
Message-ID:
	
<70B7A1CCBFA5C649BD562B6D9F7ED784051197B1 at xmb-ams-333.emea.cisco.com>
Content-Type: text/plain;	charset="us-ascii"

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


------------------------------

Message: 3
Date: Fri, 07 Mar 2008 08:13:02 -0600
From: Bryan Campbell <bbc at misn.com>
Subject: Re: [cisco-bba] How to stop static routes looping
To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
Cc: cisco-bba at puck.nether.net, Andy Saykao
	<andy.saykao at staff.netspace.net.au>
Message-ID: <47D14D6E.7070305 at misn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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
>
>   


------------------------------

_______________________________________________
cisco-bba mailing list
cisco-bba at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

End of cisco-bba Digest, Vol 57, Issue 5
****************************************

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

This email and any files transmitted with it are confidential and intended solely for the 
use of the individual or entity to whom they are addressed. Please notify the sender 
immediately by email if you have received this email by mistake and delete this email 
from your system. Please note that any views or opinions presented in this email are solely
 those of the author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for the presence of 
viruses. The organisation accepts no liability for any damage caused by any virus 
transmitted by this email. 



More information about the cisco-bba mailing list