In every BGP configuration I've been involved with, we have set the iBGP
next-hop-self. It's almost like a default. This includes simple full
meshes and complex route-reflector topologies. It is actually VERY
preferable when you are multi-homed for lower CPU utilization, proper
routing and reachability during route topology changes.
The one configuration I can't remember off the top of my head is a
multi-access network where you have two iBGP routers and one eBGP router
that only peers to one of the iBGP router. I remember there is a exception
to how the iBGP peers will exchange routes learned from the eBGP router, but
the specific's aren't coming to me.
Your end result can be a cleaner IGP, and don't have to muck about with
"redistribute connected" (and thus being a ABR with a multitude of
advertisements under OSPF), or passive interfaces if you advertise the
external prefix via a "network" statement (though you still have to use
passive if you are a ISP providing the address to a customer).
I'm not 100% following why you are redistributing connected and static into
iBGP. Can you elaborate (either on or off the list)?
David
-----Original Message-----
From: Martin Cooper [mailto:mjc@cooper.org.uk]
Sent: Thursday, November 30, 2000 1:47 PM
To: cisco-nsp@puck.nether.net
Cc: mjc@cooper.org.uk
Subject: Setting next-hop-self on iBGP peerings
We are currently considering a move from carrying
all our internal prefixes in OSPF to using iBGP
to carry the edge prefixes, and just using OSPF
to carry the BGP next-hop.
The way I'm thinking of doing this is by redist'ing
connected and static routes into iBGP via a route-
map that sets community 'no-export' to make sure
we don't leak the more specific prefixes, but I
am looking for arguments for and against setting
next-hop-self on iBGP peerings - the most obvious
argument that I can see in favour is that of not
having to carry external next-hops around in the
IGP - but I am sure there must be a disadvantage
to not knowing what the external next-hop was,
although I am not sure what it might be.
Any assistance greatly appreciated,
M.
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:22 EDT