Jump to content


Bgp Advertising


  • Please log in to reply
5 replies to this topic

#1 Grexory

Grexory

    Super Member

  • Veterans
  • PipPipPipPip
  • 849 posts
  • Gender:Male
  • Location:UK

Posted 28 January 2006 - 12:51 AM

Hi guys,

Im by no means ready for CCIE however I am learning BGP in my lab enviroment, I have a question, when full meshing routers in a IBGP, what is the normal way of advertising the /30 p2p subnets which connect them together, is it just a case of advertising them with the network command, or redistributing connected routes, or making a static route to null0 then redistributing it?

Any help would be great, I know with BGP they always recommend you advertise routes by using the network command if the router exists in the table, but im not sure on advertising directly connected subnets!

Any help would be great

Cheers
  • 0

#2 mgerdon

mgerdon

    Super Member

  • Veterans
  • PipPipPipPip
  • 981 posts
  • Location:Germany

Posted 28 January 2006 - 06:38 AM

Grexory,

there're various methods deployed dependent on layout of the network and preference of the administrator.
Regarding advertisement via BGP this depends whether you're carrying internal (igp) routes within BGP. For an iBGP full-mesh to work you have to deploy any IGP underlying the BGP design as the neighbors have to be reachable and BGP speakers don't pass on routes learned from an iBGP peer. At least you need an IGP when not all BGP-speakers are directly connected.
Usual design is to have an IGP responsible to route the BGP neighbor addresses. For iBGP when redundant paths are existing, loopbacks are used. Thebn the link networks (/30) aren't needed to be distributed neither by BGP nor the IGP. Only routes required within IGP are the loopback addresses then.
Usually BGP isn't deployed down to the edge/access devices (access layer) but is used only within the network core (due to convergence time for example).
Redistribution into BGP is highly deprecated int the field due to risk of flaps and erroneous redistributes. BGP in general is designed for maximum stability and scalability but isn't adequate for regular/often re-converging networks or when low convergence delay is required. BGP is a very flexible protocol (as you see by the lot of options), so question for usual deployment/configuration are best based on an actual example topology.

regards,

Marcus
  • 0

#3 gordonccie

gordonccie

    Best Poster in March 2006

  • Veterans
  • PipPipPipPip
  • 652 posts
  • Gender:Male
  • Location:Netherlands

Posted 28 January 2006 - 08:08 AM

Awesome explanation, I hope it's sufficient for Grexory

Grexory,

there're various methods deployed dependent on layout of the network and preference of the administrator.
Regarding advertisement via BGP this depends whether you're carrying internal (igp) routes within BGP. For an iBGP full-mesh to work you have to deploy any IGP underlying the BGP design as the neighbors have to be reachable and BGP speakers don't pass on routes learned from an iBGP peer. At least you need an IGP when not all BGP-speakers are directly connected.
Usual design is to have an IGP responsible to route the BGP neighbor addresses. For iBGP when redundant paths are existing, loopbacks are used. Thebn the link networks (/30) aren't needed to be distributed neither by BGP nor the IGP. Only routes required within IGP are the loopback addresses then.
Usually BGP isn't deployed down to the edge/access devices (access layer) but is used only within the network core (due to convergence time for example).
Redistribution into BGP is highly deprecated int the field due to risk of flaps and erroneous redistributes. BGP in general is designed for maximum stability and scalability but isn't adequate for regular/often re-converging networks or when low convergence delay is required. BGP is a very flexible protocol (as you see by the lot of options), so question for usual deployment/configuration are best based on an actual example topology.

regards,

Marcus


  • 0

#4 Grexory

Grexory

    Super Member

  • Veterans
  • PipPipPipPip
  • 849 posts
  • Gender:Male
  • Location:UK

Posted 28 January 2006 - 09:21 AM

Thanks for the excellent response,

I've got lots of experience with various IGPs having worked on numerous large lans (10000+ workstations) but not for an ISP hence why im trying to understand BGP.

I've got a 5 lab router setup with all routers fully meshed with IBGP within AS65000. And i've been playing around injecting routes and watching the update procedure, i've also added AS63000 to the edge and observed how IBGP and EBGP advertise routes.

So I gather from your response that you generally combine IBGP with an IGP to advertise the reachability of the /30 networks between the peers? I have heard that (like you say) its bad practise to start dumping routes into BGP for fear of errors and suboptimal convergence?
  • 0

#5 mgerdon

mgerdon

    Super Member

  • Veterans
  • PipPipPipPip
  • 981 posts
  • Location:Germany

Posted 28 January 2006 - 11:38 AM

Thanks for the excellent response,

I've got lots of experience with various IGPs having worked on numerous large lans (10000+ workstations) but not for an ISP hence why im trying to understand BGP.

I've got a 5 lab router setup with all routers fully meshed with IBGP within AS65000. And i've been playing around injecting routes and watching the update procedure, i've also added AS63000 to the edge and observed how IBGP and EBGP advertise routes.

So I gather from your response that you generally combine IBGP with an IGP to advertise the reachability of the /30 networks between the peers? I have heard that (like you say) its bad practise to start dumping routes into BGP for fear of errors and suboptimal convergence?


Hi,

again this depends on your topology. I'll try with a few examples.

All routers are within same AS, currently no IGP is running, and there's no route-reflector in use. All links between routers are addressed with a different /30.

Posted Image

You want to establish iBGP sessions between all routers of this network.
Due to the fact that iBGP has to be full-mesh (as long as there's no route-reflector or confederation) because no routes learned from an iBGP neighbor are advertised to any other neighbor, each router has to be able to reach the other three.
Although r1 is directly connected to r2 and r3, no interface of r4 can be reached without any additional routes at r1 and for the return path at r4. To achieve this reachability, you could use any IGP, even static routes.

Let's do some config now.

at r1:
- route to link subnet r2-r4 out eth0
- route to link subnet r3-r4 out eth1
at r4:
- route to link subnet r2-r1 out eth1
- route to link subnet r3-r1 out eth0

Now you can reach all interfaces of all routers from each router. But as your network grows, this gets tedious.

You set up BGP sessions now:
a r1/eth0 to r2/eth1
b r1/eth1 to r3/eth0
c r1/eth0 to r4/eth1 (via r2)
d r2/eth0 to r4/eth1
e r2/eth0 ro r3/eth1 (via r4)
f r3/eth1 to r4/eth0

At this time, your BGP is up and running.

When you cut the link r2-r4 now, what happens ? You loose the sessions c & d.
But there's another path for r1-r4.

Replace the static routes by any IGP and inject the /30's.

You now can reach r4 from r1 via r3. But as the link and therefore the interfaces are still down, your sessions stay down.

You can extend your BGP config for this to work again by adding some sessions.

g r1/eth1 to r2/eth0
h r1/eth0 to r3/eth1
i r1/eth1 to r4/eth0
j r2/eth1 to r4/eth0
k r2/eth1 ro r3/eth0
l r3/eth0 to r4/eth1

You doubled the number of sessions, but now, even if an interface goes down, you keep your full-mesh up.
You've configured two sessions between each pair of routers, just to always keep a session up even if an interface goes down. But your routers have to handle the additional sessions you have to configure.
You surely see where this leads to when there are even more than two interfaces per router.

Instead of such a config, add a loopback interface to each router and put a /32 on it. Inject the loopbacks' address into your IGP so you have reachability between every pair of loopbacks.

Kick all your BGP sessions you configured and configure them this way:

a r1/lo to r2/lo
b r1/lo to r3/lo
c r1/lo to r4/lo
d r2/lo to r3/lo
e r2/lo to r4/lo
f r3/lo to r4/lo

Each session with an update-source of the local loopback you created.

You're no longer dependent on the interface and link states connecting your routers. And that with half the number of BGP sessions as before.

What happens when a link fails now ? Nothing - IGP converges and the session is running the other path. Most time BGP sessions aren't even dropped if the network converges fast enough.

Do you need the /30's to reach the other routers ? No, as every neighbor relationship between the routers for the IGP is formed on locally connected networks. Only thing you've lost is the ability to reach any not locally connected link interface.

This is the part of the administrators preference. I prefer injecting the interface addresses into the IGP to be able to directly address them, mostly for simplicity in troubleshooting. A colleague of an aligned company prefers not to do so because he wants the routing table to be as small as possible.

Regarding your second question, redistribution and filtering are the most risky and error-prone configurations that can be done for any routing protocol. In case of BGP there's a large risk of wrong routes being introduced when they come to be announced via an eBGP session. eBGP-learned routes get a administrative distance of 20 - well below any IGP (except EIGRP summary). If you happen to do some mistake here, you could possibly bring down your neighbors iBGP by overriding his IGP routes.
For the matter of stability, BGP needs a lot of CPU resources and owns a long convergence time. Therefore it's preferred for BGP to not inject any interface/link/IGP-sourced routes as these are prone to flap.
Usually you'll inject a network by the network statement and nail the network down by a static route to the null interface (with a high distance, 250 for example). The not so obvisious advantage with this is that if you do that with a summarized network, all packets destined for an address currently not routed by the IGP are blackholed.

I hope I could clear your questions, else feel free to post.

greetz,

Marcus

Edited by mgerdon, 28 January 2006 - 11:38 AM.

  • 0

#6 Grexory

Grexory

    Super Member

  • Veterans
  • PipPipPipPip
  • 849 posts
  • Gender:Male
  • Location:UK

Posted 28 January 2006 - 08:39 PM

Brilliant response again.

I fully understand what your saying and it has cleared up alot of the confusion. if I have any more queries i'll give you a shout :)
  • 0





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users