From: Hyunseog Ryu (r.hyunseog@ieee.org)
Date: Fri Nov 14 2008 - 19:59:29 ARST
For Load-sharing or multi-homed customer routes, you should use
interface name instead of next-hop ip address.
That's the answer for your situation.
For an example,
ip route 192.168.1.0 255.255.255.0 serial1/0
Joe wrote:
> Thank you for all the responses. A real world scenario would be this....we
> have several class B addresses in our network. We generate summary
> addresses in BGP which obviously create supernets pointing to null 0 (/139s
> and some /149s). We then have our customers connected on the edge (lets say
> a small customer, /24 network like my example). Well the interface they are
> connected to goes down, the route to them is still a valid route due to the
> summary. So neighbor router sends traffic to this router due to the more
> specific route, only to have the route send it back based on the summary
> address( routing loop). Now we have seen this issue on some routes (those
> where the summary route is a /14, but where the summary address is a /13 the
> static route is removed from the table and thus no routing loop, saturated
> link, et....) *On a side note, with the way MPLS TE is configured on our
> backbone, the MPLS taf TTL is always new (doesn9t inherit the router TTL)
> and thus creates a storm. I know those setting can be changed...but it9s a
> little more complicated. Again a static with a next hop and interface fixes
> the problem as well. The solution isn9t so much the concern, rather the
> behavior and understanding it.
> So while I understand the answers you guys are giving, I have seen the
> route disappear on a /13 route but not a /14 route....To me it would make
> sense that ANY valid route, minus a default, could be used for
> recursion...but doesn9t appear to be the case. Didn9t know if there was any
> rhyme or reason to it. Again, thank you everyone for your input.
>
> On 11/14/08 12:44 PM, "Pavel Bykov" <slidersv@gmail.com> wrote:
>
>
>> Yes, correct.
>>
>> On Fri, Nov 14, 2008 at 8:37 PM, Hyunseog Ryu <r.hyunseog@ieee.org> wrote:
>>
>>> As long as it can find any network containing next-hop IP address from
>>> routing table.
>>> So if you have default route (0.0.0.0/0 <http://0.0.0.0/0> ), it will be
>>>
> hit
>
>>> as very last
>>> resort.
>>> Therefore it will pick up the next-hop ip address from default route to
>>> replace "down"ed interface ip address next-hop ip address.
>>>
>>>
>>>
>>> Joe wrote:
>>>
>>>>> Ya, this is what I have seen. Again, at what point is the route NOT
>>>>>
>>>> specific
>>>>
>>>>> enough for the static to disappear and is that something you can
>>>>>
>>>> configure?
>>>>
>>>>>
>>>>> On 11/14/08 11:02 AM, "Hyunseog Ryu" <r.hyunseog@ieee.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>> We had this issue in the past.
>>>>>>> If int X fails, 11.11.11.0/24 <http://11.11.11.0/24> will still
>>>>>>>
> exist
>
>>>>> in routing table because
>>>>>
>>>>>>> of recursive lookup.
>>>>>>>
>>>>>>> That's why you have to use interface name instead of next-hop IP
>>>>>>>
> address
>
>>>>>>> if possible.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Joe wrote:
>>>>>>>
>>>>>>>
>>>>>>>>> I have a question on recursive lookups, hopefully I can phrase it in
>>>>>>>>>
> a
> way
>
>>>>>>>>> that makes sense. Thanks
>>>>>>>>>
>>>>>>>>> If I have a static route like:
>>>>>>>>> Ip route 11.11.11.0 <http://11.11.11.0> 255.255.255.0
>>>>>>>>>
>>>>>> <http://255.255.255.0> 10.10.10.1 <http://10.10.10.1>
>>>>>>
>>>>>>>>> And I have a route table that looks something like this:
>>>>>>>>> C 10.10.10.0/24 <http://10.10.10.0/24> via int X
>>>>>>>>> O 10.10.0.0/16 <http://10.10.0.0/16> via x.x.x.x
>>>>>>>>> E 10.0.0.0/8 <http://10.0.0.0/8> via x.x.x.x
>>>>>>>>> B 0.0.0.0 <http://0.0.0.0>
>>>>>>>>>
>>>>>>>>> Hopefully you get the idea of the route table...doesn't matter how
>>>>>>>>>
> the
>
>>>>>>>>> routes are learned... just the idea of multiple routes (each less
>>>>>>>>>
>>>>>> specific).
>>>>>>
>>>>>>>>> What happens when I lose my directly connected interface? How
>>>>>>>>>
>>>>>> "un-specific"
>>>>>>
>>>>>>>>> of a route will the router use for a recursive lookup? *I know in
>>>>>>>>>
> this
>
>>>>>>>>> example if I lost the /24 then the next most specific /16 in this
>>>>>>>>>
> case
> is
>
>>>>>>>>> next in line but at what point will the router say it won't use a
>>>>>>>>>
>>>>>> valid
>>>>>>
>>>>>>>>> route (as far as the route table) for a recursive lookup?
>>>>>>>>>
>>>>>>>>> I don't believe it will ever use a default route but it seems like
>>>>>>>>>
>>>>>> I've seen
>>>>>>
>>>>>>>>> it try to recurse off a /14 route. In my opinion that is an
>>>>>>>>>
>>>>>> undesirable
>>>>>>
>>>>>>>>> behavior (let's say you have a summary address to null 0, you
>>>>>>>>>
> wouldn't
>
>>>>>> want
>>>>>>
>>>>>>>>> you statics still showing up as accessible because the next hop is
>>>>>>>>>
>>>>>> reachable
>>>>>>
>>>>>>>>> via a /16 net lets say). I know, I can avoid that issue by adding a
>>>>>>>>>
>>>>>> specific
>>>>>>
>>>>>>>>> interface to the static route, but would still like to know at what
>>>>>>>>>
>>>>>> point do
>>>>>>
>>>>>>>>> I not do a recursive lookup. Thanks for the help
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> _______________________________________________________________________
>>>>>>
>>>>>>>>> Subscription information may be found at:
>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Joe Clyde
> Network Engineer
> Utah Education Network
> jclyde@uen.org
> 801-883-4868 (Desk)
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:30 ARST