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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]
>> 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@puck.nether.net <mailto:juniper-nsp@puck.nether.net
>
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net
>
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net
>
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp