[j-nsp] Route Reflecting & Next-Hop Self

Tue Sep 9 19:31:37 EDT 2008

I agree, this is 'hotly debated' :).. Those who argue against having
transfer networks in IGP believe the IGP should be kept 'lean', only
loopbacks and internal transfernets to keep the SPF database as small
as possible. If you have a large backbone with hundreds of
upstream/downstream/peering ports and you try to keep all those
transfernets in your IGP, you will eventually start to feel the bloat.
Another alternative to both IGP & next-hop-self methods is to take the
external transfernets into your iBGP via connected network
redistribution/network statement (tag with an internal transfernet
community, etc).

Regards,
Kevin

On Tue, Sep 9, 2008 at 5:05 PM, Dan Armstrong <dan at beanfield.com> wrote:
> Those people <ahem> that first planted this notion in my head is watching
> this list - they're free to chime in anytime. :-)
>
>
>
> James Jun wrote:
>>
>> Well, given the fact that BGP uses IGP information (metric) to make
>> best-path decision, you should include inter -AS xfernets in your IGP if you
>> want to do decent deterministic traffic engineering toward your nexthops.
>>
>> I think the whole notion of "my IPs in IGP only" is silly..
>>
>> James
>>
>> Sent from my iPhone
>>
>> On Sep 9, 2008, at 4:01 PM, Dan Armstrong <dan at beanfield.com> wrote:
>>
>>> A hotly debated topic among BGP nerds....     I honestly don't know how I
>>> feel about it either way.
>>>
>>>
>>> Many people think that because the IPs that you often use between
>>> yourself and a transit provider belong to your transit provider, they have
>>> no business being in your IGP.... "My IGP is for MY address space".    At
>>> the end of the day I don't think it really matters, but you know how
>>> passionate some people can be.
>>>
>>>
>>>
>>>
>>> Amos Rosenboim wrote:
>>>>
>>>> Hello Dan,
>>>>
>>>> You can also work around all of this by simply adding the inter-AS
>>>> prefix into your IGP by adding this interface as a passive interface for the
>>>> IGP.
>>>> This will eliminate the need for next hop self in the first place.
>>>> This seems simpler to me, am I missing any reason not to use this?
>>>>
>>>> Regards
>>>>
>>>> Amos Rosenboim
>>>> amos at oasis-tech.net <mailto:amos at oasis-tech.net>
>>>>
>>>>
>>>>
>>>> On Sep 6, 2008, at 12:46 AM, Dan Armstrong wrote:
>>>>
>>>>> EUREKA you're a genius!
>>>>>
>>>>> Thanks...  That works perfectly.
>>>>>
>>>>> And thanks to all who replied!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Kevin Hodle wrote:
>>>>>>
>>>>>> Hi Dan,
>>>>>>
>>>>>> Instead of 'from external' you need 'from route-type external', like
>>>>>> so:
>>>>>>
>>>>>> term external-nexthopself {
>>>>>>   from {
>>>>>>       protocol bgp;
>>>>>>       route-type external;
>>>>>>   }
>>>>>>   then {
>>>>>>       next-hop self;
>>>>>>       accept;
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> HTH,
>>>>>> Kevin
>>>>>>
>>>>>> On Fri, Sep 5, 2008 at 9:26 AM, Dan Armstrong <dan at beanfield.com
>>>>>> <mailto:dan at beanfield.com>> wrote:
>>>>>>
>>>>>>
>>>>>>> I was trying to make a generic policy statement that I could deploy
>>>>>>> across all our boxes... this is not possible if we name ebgp peers
>>>>>>> specifically, and if we change transit providers - we have to keep track of
>>>>>>> changing policy statements as well... kind of messy.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chuck Anderson wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Thu, Sep 04, 2008 at 10:08:45PM -0400, Dan Armstrong wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> In IOS, if I set next-hop self in a neighbor relationship with an
>>>>>>>>>  RR-Client, it sets the next-hop to itself for routes learned from local
>>>>>>>>>  eBGP sessions, but leaves the next-hop unchanged for routes that it's
>>>>>>>>>  passing on from other fellow route-reflectors...
>>>>>>>>>
>>>>>>>>> The *problem* is that in JunOS, if I set next-hop self on a
>>>>>>>>> neighbor  relationship with an RR-Client, it sets the next-hop to itself all
>>>>>>>>> the  time, even on routes it's passing on from other fellow
>>>>>>>>> route-reflectors,  effectively sucking all traffic into the route reflector
>>>>>>>>> and totally  defeating the purpose of route reflecting.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> That's just the way it is in JunOS--not much policy-related behavior
>>>>>>>> is hard-coded into JunOS like it might be in other vendors.  This gives you
>>>>>>>> the most flexibility in writing policy to do exactly what you want.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Now, of course we can policy-statement our way out of this - with
>>>>>>>>> big  messy kludgey stuff, but it seems to me that there has to be a fairly
>>>>>>>>>  simple and elegant way to do this, since it's pretty common, no?
>>>>>>>>>
>>>>>>>>> (My current kludge is to set an import policy on my eBGP sessions
>>>>>>>>> that  tag each route with a community called "HERE", have an export policy
>>>>>>>>>  towards all my iBGP neighbors to set next-hop self if the route is  tagged
>>>>>>>>> with the community "HERE", then strip it off - so that the  community "HERE"
>>>>>>>>> never leaves any box.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>> That is one recommended method.  The other is to match the eBGP
>>>>>>>> neighbor and only apply next-hop self to routes from your eBGP peers.
>>>>>>>>
>>>>>>>> e.g. in your IBGP export policy (from the JNCIP study guide):
>>>>>>>>
>>>>>>>> term 3 {
>>>>>>>>  from {
>>>>>>>>      protocol bgp;
>>>>>>>>      neighbor [ 172.16.0.14 172.16.0.18 ];
>>>>>>>>  }
>>>>>>>>  then {
>>>>>>>>      next-hop self;
>>>>>>>>  }
>>>>>>>> }
>>>>>>>>
>>>>>>>> where 172.16.0.14 and 17.16.0.18 are eBGP peer addresses.
>>>>>>>> _______________________________________________
>>>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>>>> <mailto:juniper-nsp at puck.nether.net>
>>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>>> <mailto:juniper-nsp at puck.nether.net>
>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>> <mailto:juniper-nsp at puck.nether.net>
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

-- 
|| Kevin Hodle
||
|| 913-780-3959 (Primary)
|| 913-626-7197 (Mobile)

PGP KeyID [0xBBDE8ED7]
fingerprint [3E1B 1F10 938E A831 8CF2 670C 1329 0B8B BBDE 8ED7]