# bgp protocol

## someguy

i know this may sound ludicrous but is it possible to make linux do bgp ?? like host the protocol

----------

## EvilN

I've seen some stuff about this so it should be possible.

Although I have a REALLY hard time understanding why.

If you need BGP you obviously want to peer with someone and that someone will not likley be fond of peering networks to a unknown linux box and even worse, have their traffic running transit over a PC.

Other things to think of is the number of routes you want to peer.

A full Internet GBP table is somewhere around 250000routes so that will generate some traffic.

No, I'd say buy Cisco or Juniper and concentrate on the peering itself rather than the problems you'll get for running bgp on linux.

But if you are serious you'll need to specify what kind of bgp you want, ibgp and or ebgp according to gbp4 and/or if you want mbgp.

In addition to that you propably need something to redistribute into bgp4 (kind of annoying redristibuting static routes on a large scale) so you'll need OSPF or IS/IS up and running first.

I would not for a second think about using linux for bgp4 peering to customers or anyone actually.

I'd go with a more "stable" solution for that.

On a side note, BGP must be the most abused protocol ever.

99% of everybody that want to use bgp has no real idea why and dont fully understand what to use it for, there are of course cases where you need bgp, when you peer to other ASes for one or when you need to fix a problem in another routing protocol but in most cases people just use a lot of bandwidth to redistributre routes they are allready getting from their igp.

On the other hand, you might just want a machine or three to learn bgp on and then it might be a pretty good idea to use linux for it.

/Nils

----------

## kashani

emerge zebra

supports bgp, ospf, and rip. No eirgp as that's Cisco specific.

Zebra is a nice routing engine for *nix that's been around for some time and is generally pretty stable. 

I generally agree with everything EvilN said, but one interesting thing you can do with your Linux box is have it act as the route server in a confederation... I think my terminology is off. In any case you have 8 local routers that need to peer with 8 routers at the next pop. Rather then all the internal peering you setup up two Linux boxes to act as route servers in each site, setup confederations locally and voila, less memory being used, more stable, and smaller routers can be purchased.

kashani

----------

## apeman_spaceman

zebra works fine, but for a first time bgp deployment I say go with Cisco. Chances are thats what your peers are using. If they speak cisco and you run into trouble, they can be of more help, rather than trying to guess the zebra commands. BGP was designed to be vendor neutral, but it makes life easy when the peers are on the same platform.

Clueless peers scare the crap outta me, but thats also what my strict filters are for  :Smile: 

-apeman

----------

## EvilN

And I say, go with Juniper (if you got the $$$).

Chances are that your peers are using Cisco and thats a good reason to go with Juniper since they peer great together.

Also, policy editing in Juniper is really good and in addition you get stuff like mpls martini and compella that you normally dont get in you Cisco box.

There is no differences in the functionality betwen the 5Gigabit M5 and the 640Gbit T640...only bandwidth. Sonet/SDH interfaces and PDH interfaces in all units and so on and so on...

Kashani, I didnt quite get the "confederation" thing.

Are you trying to redistribute routes into another routing protocol there or are you having servers for holding a hughe routing table?

Anyways, no problem in Juniper since it holds the full internet routing tables without problems. I think Cisco does too, might be a memory issue there, so check what the model is capable of.

----------

## kashani

Basically it's an inter-pop peering thing. If I peer with 8 roouters then I have 8 full sets of routing tables. Okay maybe I don't quite have 8 full sets with soem nice filtering, but I've still got quite a bit. 

So you setup a zebra box to aggregate these passit to the the other pop and then redist to the other 8 routers. 

http://www.cisco.com/warp/public/459/bgp-toc.html#bgpconfed

In any case when I was building ISP's around 98-99, you were lucky to get 128MB of ram in your router versus the silliness you can do to today.  :Smile: 

Ramin

----------

## double00

why not use zebra? A full BGP routing table requires 256M of memory, and that costs a lot from the likes of cisco and juniper, not even thinking about the costs of the router chassis, line cards etc. Fellow Gentoo-ers recommending proprietary vendors tsk tsk..  :Wink: 

Zebra has come quite a way and is shipped with Checkpoints SecurePlatform (linux based FW product) as a fully supported routing engine, so I can't believe that the code is flaky in any way shape or form. 

Also the CLI for zebra (like many netwrok appliances/devices) is very cisco-like, with command completion, output etc.

If you don't know what you are doing then no matter which platform you use, you are going to run into trouble with BGP as it is a heavyweight routing protocol, but as the poster above mentioned, it takes 2 to tango, your routing policy should dictate not just what you send but also what your receive.

I think you are referring to route reflectors, this keeps the number of peering relationships to 'n' rather than a full mesh of 'n*(n-1)' relationships.

Why is it you wanted to run BGP? In a lab or for real?

 :Question: 

----------

## kashani

Route reflectors do the same thing confederations do just in a diffenrent way. IIRC Bay Networks used route reflectors and Cisco used confederations. Basically they're the same thing with their own unique quirks. 

I didn't realize this before, but full BGP routes should come in around 130k, not 250k as mentioned way up there. Unless your peer has their head firmly implanted somewhere dark.

256MB of RAM is the minimum I'd use to run BGP w/512 starting to be more common.

kashani

----------

## fatcat.00

OK so this is from memory...if I get something wrong please point it out...

Confederations are used to simplify the requirement that straight iBGP has for a full mesh between all the peers within an AS.

A confederation works by subdividing a number of routers within a single AS into their own "mini" autonomous systems. Typically you then peer these "sub-ASes" with each other through the normal BGP means.  If you have enough routers this reduces the number of routers each router is peered to, simplifying the configuration and manageability of the network.

BGP requires a peer between every participating router (a full mesh).  To calculate the number of connections to achieve a full mesh given n routers, you do n*(n-1)/2.  

Three routers: 3*(2)/2 = 3.

Four routers: 4*(3)/2 = 6

Five routers: 5*(4)/2 = 10

Ten routers: 10*(9)/2 = 45

Twenty routers: 20*(19)/2 = 190

Two Hundred routers: 200*(199)/2 = 19900

You get the picture.  By taking your 200 routers and organizing them into 10 confederations of 20 routers each, you greatly simplify the organization of your network.  Organize it again into 20 confederations of 10 routers and it becomes simpler still, although the law of diminishing returns definitely applies.

Router reflectors do the same thing by designating the reflector that is responsible for maintaining a BGP table for a group of client routers.  Each router peers only with the reflector instead of creating a full mesh.  

In general, confederations are used for a far-flung networks, where route reflectors are used for a more localized version of the same problem.  Confederations give you more policy control over your network.

Uh, I hope thats close.  By all means consult an authority for a fuller clarification.

----------

## double00

oh yes, I forgot my denominator. 

Fatcat, your memory is spot on. 

There are a number of RFC's that cover confederations, RR's etc.

As an aside, does anyone use confederations out there? Or know of any networks that have them. From my direct experience I've only ever come across one, and that was a migration from a standard peering design to a confederation of sub-AS's. The only reason being that the extra expenditure for route reflectors could not be justified.

----------

## kashani

You're starting to see less and less confederation with the advent of layer 3 switches and better routers. Many pops are now 1-2 devices rather then the 10-20 they would have been back in the day. I'm assuming most NSP's (Level3, Cogent, etc) are using some sort of RR or confederations.

As to the full mesh stuff, you don't have to have a full mesh as long as you think about your IGP enough to avoid routing loops. Or become part of the hot potato school of routing. Most of the networks I've worked on weren't interconnected enough to make a full mess worth it. You can even do a full iBGP mesh with partial routes and cut way down on the actually number of routes you'd need. Granted keeping track of 20+ peering sessions internal makes confederations look awfully nice.

Nice write up Fatcat.

kashani

----------

## fatcat.00

Oh yes.  I didn't mean to imply that you *must* do a full mesh.  You only need to do a full mesh *if* you want the exact same routing table on every router (and you don't want to / can't use route reflectors or confederations).

There are certainly legitimate designs where homogeneous routing tables are not required.  Kashani mentioned a few.

The full mesh is the textbook example of course, because its so easy to understand.

----------

