andy.saykao at staff
Mar 13, 2008, 5:01 PM
Post #5 of 6
(3440 views)
Permalink
|
Thanks to Oli, I implemented the command "ip verify unicast
reverse-path" to our Virtual-Access template and it has stopped the
routing loop.
Interestingly enough I could only replicate the problem when the
customer was using a Cisco product (eg: Cisco 827) and did not configure
the additional subnet on their Ethernet interface. This resulted in a
loop back and forth between the customer's network and our LNS. This was
before I used the "ip verify unicast reverse-path" command.
However, when using non-cisco product like a Netcomm NB1300 or Siemens
6520, and not having configured the Ethernet interface with the
additional subnet on these devices, they did not show the same routing
loop problem. Somehow these devices stopped the routing loop from
happening.
Why would this be the case whereby the routing loops are only occuring
on the cisco 827 as illustrated above?
----------------------------------------------------------------------
Message: 2
Date: Fri, 7 Mar 2008 09:06:58 +0100
From: "Oliver Boehmer (oboehmer)" <oboehmer [at] cisco>
Subject: Re: [cisco-bba] How to stop static routes looping
To: "Andy Saykao" <andy.saykao [at] staff>,
<cisco-bba [at] puck>
Message-ID:
<70B7A1CCBFA5C649BD562B6D9F7ED784051197B1 [at] xmb-ams-333>
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>
Subject: Re: [cisco-bba] How to stop static routes looping
To: "Oliver Boehmer (oboehmer)" <oboehmer [at] cisco>
Cc: cisco-bba [at] puck, Andy Saykao
<andy.saykao [at] staff>
Message-ID: <47D14D6E.7070305 [at] misn>
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
> https://puck.nether.net/mailman/listinfo/cisco-bba
>
>
------------------------------
_______________________________________________
cisco-bba mailing list
cisco-bba [at] puck
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.
------------------------------
_______________________________________________
cisco-bba mailing list
cisco-bba [at] puck
https://puck.nether.net/mailman/listinfo/cisco-bba
End of cisco-bba Digest, Vol 57, Issue 6
****************************************
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
cisco-bba mailing list
cisco-bba [at] puck
https://puck.nether.net/mailman/listinfo/cisco-bba
|
