Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts

Learning BGP

Hello I am learning BGP, to make sure I can understand how BGP is configured in real world. I have few questions to start with

  1. Can BGP advertise routes that are learned exclusively through IGP like redistribution from ospf or eigrp , without network statements or aggregate network address under router BGP ? with auto summary disabled ?

  2. Can BGP learn routes through local routing table on router without manually redistributing.

  3. On sh ip BGP output

What is the difference between the routes * i , *>i

is *>i when we specifically configure valid internal route with AS number details using additional command "as set "?

say we configured network as *i on "router A" , which has BGP peer " router B". on router A - sh ip bgp output , there is no AS path information next to network

When this network is learnt on Router B, dont by default *i routes gets advertised to neighbor Router B and then propagate the network statement along with AS number as *> on the neighbor Router B sh IP bgp routing table ?

Below is a general question

Those who work for ISP and in general what is the most common issue you see on a BGP networks ? what basic troubleshoot steps you do, with the knowledge of ccna and CCNP. I am only asking the most basic ones (not how you design BGP, which i will not understand at this stage), since I might use those steps to properly understand my upcoming lab comparing them to real time scenario and build my concepts.

94% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1
122 points · 3 months agoGilded1

Welcome to the club! As a guy who has been doing this for a few decades, this is how I train folks who are new to routing protocols.

For all devices (PCs, routers, switches, etc.), you have to understand there are two things at play when any decision to move packets is made. 1) The routing table on the device, or learned next hops based on specific triggers (RIB) 2) the forwarding table, or how to move the frame based on the next hop (FIB).

In order to build your RIB, you need to look at all active protocols that the device is actively using, parse them, weigh them, then import the best one into the routing table. Each protocol starts as a blank slate, and only two are enabled by default (direct/connected and static). Each and every other protocol has its own separate database that it builds independently of the primary routing table on the box. Each of these can have the same, or different, sets of prefixes that it is learning. Only when it is compiled and sent into the master RIB does it become official.

Once you enable a routing protocol that isn't on by default, say OSPF or BGP, it starts as a blank slate. It has nothing, because you haven't told it how to learn its prefixes yet. You also have to understand "default behavior" of each protocol, so as you type commands you know what is going to happen. In your case, BGP uses two different defaults. 1) For External BGP sessions, the default behavior is "accept all prefixes, forward all known prefixes", versus 2) for Internal BGP, the default behavior is "accept all prefixes, do not forward other IBGP learned prefixes". For this example though, we're going to use EBGP only.

The first thing you need to do is import prefixes into BGP to prepare your device to announce itself to the world at large. You do this one of two ways: 1) You use network statements, or 2) you redistribute. If you're able to, I highly recommend #1 over #2 for many reasons. The difference between the two is pretty simple across all protocols -- when you use a network statement (BGP or OSPF), it imports it as part of the local BGP/OSPF process. When you redistribute, it's imported as an "External" route, meaning external to the process. This has some pretty big implications later on in your learning process, but for now they're relatively the same thing. Once you've added network statements, or redistributed from another protocol (static, connected, OSPF) into BGP, you now have a local BGP-RIB you've built and are ready to advertise. Note: All prefixes will show up as their originators in the routing table, e.g. connected, static, or OSPF. In order to see what your BGP RIB has imported, just type "show ip bgp" on a typical Cisco IOS device and you'll get a dump of everything you've successfully integrated into the BGP process itself (BGP-RIB).

The second thing you need to do with EBGP is set up a neighbor. Neighbors in BGP are explicit (manually programmed), not implicit (broadcast/discovered). Router A and Router B sit on either side of a link (any kind, any mask) and on each side you set up the neighbor relationship so they know to talk to each other. This is a TCP (Port 179) based process, that requires Layer 1-3 working so packets can flow (OSPF uses its own layer 4 protocol, not TCP). Once they see each other and agree upon the finer details, they form a neighbor relationship and start exchanging prefixes. Since this is an EBGP relationship, any known prefixes in the BGP table on either side will be exchanged.

Now, once you've wrapped your head around that simple process, then the fun begins. You start diving into "transitive" versus "non-transitive" properties you can associate with each prefix individually. You can manipulate routes into groups, you back block inbound, or prevent outbound announcements. But, if you're just starting, don't worry too much about that stuff. Get familiar with the basics like what is and isn't exchanged between Autonomous Systems, what is or isn't exchanged internally in the same AS, and how to set it up so you can see what you're advertising and what you're receiving on both sides for troubleshooting ("show ip bgp neighbor X.X.X.X advertised-routes | received-routes").

And again, good luck, and enjoy!

level 2

This is a great writeup with tons of good info. I just want to add clarity to some of the statements made about BGP and OSPF. Network statements between BGP and OSPF actually have different functions and behavior. A network statement with BGP is basically redistribution of a specific route without regards to the protocol it came from. Network statements with OSPF tells the router which interfaces will be participating in OSPF, not which routes to advertise. The router will try to establish OSPF neighborship on those interfaces unless they're set to passive, and routes associated with those interfaces will be advertised to OSPF neighbors. Issuing a "network" in BGP advertises a default route in BGP if one already exists in the RIB. Issuing a "network area 0" in OSPF tells the router that all IPv4 configured interfaces will be participating in OSPF area 0. It doesn't redistribute anything into OSPF unlike the behavior with BGP.

OSPF will automatically originate routes that are configured on the interfaces participating in OSPF. You can configure an entire LAN to run OSPF without a single network statement. Just tell the interfaces what ospf process and area they belong to using "ip ospf <process number> area <area number>". On the other hand, BGP requires network statements and/or redistribution statements to originate routes.

Finally BGP operates at the application layer and OSPF operates at the network layer. The IP protocol associated with OSPF operates at Layer 3, not Layer 4.

level 2
5 points · 3 months ago

This was an awesome read, thanks.

level 2
Original Poster2 points · 3 months ago

Yup thanks alot for giving a detailed run through the bgp process. Yes I have reached this far, and yes I use neighbour advertisements command to make sure carrier routers are advertising the new networks that are added. And also I make sure every time that from the aggregate summary network,there is at least one sub network statement that is in use today or learnt internally for the bgp to advertise the entire summary it to bgp peer, otherwise the aggregate network summary will be seen as supressed routes locally.

level 2

I need a brain like yours. Actually, would you mind uploading all your knowledge to me? ( wish it was that easy)

level 2

Are there any books, guides, videos, or anything you can suggest on learning bgp and ospf? I've inherited a network and I feel those are my two weakest points (weak as in... Paper thin)

level 3

Life experience and Google. That's how I roll. I would be useless without Google. :)

GNS3 is definitely the way to go here. All training classes and books are going to show you that there are these commands that exist, you can put them into a device, and it will enable the process. But, they don't really do a good job at teaching you the "what happens" next, or the if/then/else we need to do the job. That's where GNS3 and smashing things into a fake environment really can help get you over the curb.

Other than that it's really one of those careers where you just have to do it. Mess up a bunch, learn, and grow.

level 1

On "those who work for ISP", this is how we setup distinction between BGP and IGP:

  1. No redistribution whatsoever between IGP and BGP, that's gross; you better have a good technical justification for this design case.

  2. IGP (IS-IS or OSPF) carries lo0 loopbacks and necessary next-hops (if needed) to support BGP operation for resolving NLRI next-hops. Nothing else in IGP table. You need to put servers, or new LAN segments? Those don't go to IGP anymore.

  3. BGP to float all networks that require reachability, even internal stuff. Anything small that you do not want advertised out to internet must be set no-export and filtered on all external peering sessions.

  4. Routing policy identifying and tagging all BGP routes in our network. Local-pref must be properly designed in following orders of decreasing priority: (1) internal-originated, (2) customer route, (3) peer route, (4) transit route.

For example: internal routes have local-pref of 400, customer routes have local-pref of 300, peering routes = 200, transit routes = 100, routes of last resort = 50.

Our IGP tables are very lean, nothing but core infra prefixes. Everything else goes on BGP and we rely on robust routing policy design to keep import/export policies sane. Redistributing BGP<->IGP is soo enterprise; doing such in service provider network is quite silly unless you have a good technical justification for doing so.

level 2

Agreed with all these points here. These are all valid in an ISP network. Only thing I would add to number 3 is to use communities to tag routes you want advertised rather than tagging everything you do not with no-export. Routes not having the right community attached to it will not pass the filter at your peers, transit, and customers. Deny by default. You’ll be far less likely to accidentally leak routes. You can also then allow customers to tag their routes to manipulate how you are (or are not) advertising their routes from your network, again, based on the filters you have in place matching those communities.

Honestly, anyone here who knows BGP could go on and on forever based on experience... like have fun with PMTUD between differing platforms which handle the definition of MTU differently, even from the same vendor. <cough Cisco cough cough IOS-XR cough>... or random bugs that break PMTUD with differing MTU sizes in your network and iBGP when an underlying route changes... and yes, make your MTU consistent if at all within your control. 😁

level 3

Coming from Juniper land initially, IMO, IOS XR actually calculates MTU the correct way (vs. IOS XE/classic). :p

level 4

Haha, true! I had IOS, Ironware, and NX-OS which all calculate the IOS way if I remember right. XR was the odd man out for me. This was my last job and can no longer verify, so I might be wrong on one of those.

level 2

This right here is the tipping point that made me get a basic understanding of how BGP works, or is supposed to be used. I've read the CCNP documentation on BGP but that just tells you how to do very basic stuff and completely missing the point on why you are supposed to do stuff a certain way. It just really gets lost in the details explaining all the fine points, and maybe that's because the protocol has so many knobs. Still, until now I've seen the trees, now I see the forest.

Thank you my good sir!

level 1
5 points · 3 months ago

Another mention for GNS3, its free. Most Vendors' kvm virtual offerings can run for 60-90 days unlicensed. Lab it up and play with it, this is the best way to achieve some operational understanding. Use the vendors in your environment so you can simulate the vendor particular behaviors etc. This really helped me understand how BGP was going to integrate into our environment.

level 1
  1. you pretty much answered yourself. if you redistribute those routes into BGP, it'll automatically start announcing them to its neighbours (in most cases)

  2. you could import them into the BGP table via the network command?

  3. did you read the legend on top of the "sh ip bgp" output? * = valid, > = best path.

The following are values of the origin attribute of BGP: i = internal, e = external, ? = unknown. You won't see "e" these days. "i" is when you introduce the prefix into BGP via the network command, "?" is for when the prefix was initially redistributed.

The reason why there's no AS path info for your prefix at the router you introduce it into BGP is because there's no reason for it to be. As long as you stay inside your own AS, the AS path is not being prepended either.

You'll only advertise your best path for a prefix (so the ones with ">") by default.

The most common thing with BGP is that the issue isn't with BGP. Most of the time you'll either have degraded performance on or lose the underlying L1/L2/L3 altogether. When it comes to actual BGP issues, you'll want to keep an eye out for whether you're receiving and sending out the prefixes you'd expect. >Soft< clear is your friend. I've also seen that eBGP sometimes doesn't really want to deal with MTU <1500, even with PMTUD enabled.

The most issues that I've seen, however, stemmed from human error. BGP is a wonderful tool where you can do one thing a bazillion different ways. But with great power comes great responsibility so learn carefully and always measure twice. Read up on the BGP state machine, BGP attributes and the BGP path selection algorithm.

level 2
Original Poster2 points · 3 months ago

Thank you I am underlining the term bgp state machine. And regarding the l1,l2 and l3 issues do you mean that most of the issues are ibgp issues ?

level 3
RFC's make my wiener tingle6 points · 3 months ago

And regarding the l1,l2 and l3 issues do you mean that most of the issues are ibgp issues ?

No, he's saying that BGP is just a TCP connection over a network, and most of the time when BGP is having troubles, it's because of the underlying network. For example, say you have a circuit taking errors causing the TCP retrans to go missing. Eventually the session will reset, which will tear down your routes, and likely get your prefixes dampened by upstream if it happens often enough. There's no configuration command to handle that...i.e...there's no "router bgp 65535 tolerate-bullshit-circuits" command.

level 4
Original Poster3 points · 3 months ago

That is if bgp is run over single t1 link to bgp peer ? I am just trying to understand how infrastructure is laid out in combination to bgp. Most of the times it is through mpls circuit ?

level 5

Didn't you say you weren't after how the design usually looks? BGP is often what you'd use over the "MPLS" circuit to talk to your provider's edge routers, which talk to all their edges, which talk to your other sites.

Honestly, we could go over the basics all day. Maybe read up more, see if you can't find the answers you need? Although I haven't read it in a while, I remember that the BGP section of Routing TCP/IP vol. II was pretty good (and it's an excellent read anyway, vol. I as ell).

level 5
RFC's make my wiener tingle1 point · 3 months ago

Yeah, I want to echo what /u/Spades__ said and add a couple of things. Be careful with the term "MPLS circuit". People love to say, "we have MPLS with such and such provider", but anybody that knows what they're talking about now knows that you don't. In every case I've seen but one, "such and such provider," has an MPLS network, you're just a consumer of it, and therefore just have an IP circuit of some flavor or another.

To answer your question, yes it can be T1 or DS3 or OC-192. More commonly these days it's just an Ethernet circuit, but they're all "single link" at some point. Even if you are somehow multi-chassis connected to a provider, there's still a possibility the underlying network can cause BGP issues.

level 3
1 point · 3 months ago · edited 3 months ago

To run BGP in the first place, you need to already have a functioning network that guarantees reachability between your two BGP neighbours. Without that, no BGP for you! :)

If you had that, set up BGP and everything is working, you'll often lose the BGP connection if something else under it goes. After all, BGP runs over TCP. For example if you're using fibre as the physical media somewhere on the path between your two neighbours that someone cuts through. Or you could get a broadcast storm that takes down the L2 network you're on. Or the L3 reachability between your two neighbours is achieved through a different routing protocol and you lose that route for some reason.

What I'm getting at is that there's waaaay less issues with BGP itself than with the things it needs underneath it in order to run properly.

Ah, and a cool tidbit, if you weren't already aware..

level 1
2 points · 3 months ago · edited 3 months ago

My dear friend here's the BEST! video that will give you a good solid recap about BGP.

And then see this one

BGP is a really easy, yet complex protocol.

  Out: local preference 
  IN: AS-PATH shorter is better(as-path 1,2,3 is better than as-path 4,5,6,7,8,8)
  MED: Is used for inbound on  multiple BGP peering to the same ISP. Isn't used a much but is there.
  Community: These are optional transitive messages that give instructions to the BGP neighbor to do whatever you want(som use it to null or drop routes to a specific peer xxx:666)
  Local preference, AS-PATH, origin(IGP is better than EGP, and ? * is last), MED(shorter is better), EBGP and last IBGP. 

  Don't confuse IGP with IBGP, and EGP with EBGP.

Knowing these rules, you'd troubleshoot most BGP problems in seconds.

level 1
rfc9000 - Bitchslap over IP2 points · 3 months ago · edited 3 months ago
  1. Yes you can redistribute your IGP into BGP. This is pretty common practice.

  2. Yes, this is what the Network statement does. Network will advertise if it is present in the RIB.

  3. "*" means a route is valid. I.E there is a RIB entry to the next hop. "i" means the route source is internal, it was advertised by network statement on a peer within the same AS. ">" means best path. So you may have multiple paths to the same prefix, > indicates the best path which is also the one that BGP will advertise to neighbours and submit to the RIB

Here's an excerpt from a router that is dual homed to two four WAN circuits.

Ok formatting that was a shit because BGP outputs contain lots of markup characters! Here's a link instead.

You can see there each prefix has two paths with different next hops, but only one path has the > to mark best path (which I've manually selected by manipulating the weight). You can see ISP with ASN 8426 has advertised the route direct into BGP because of the "i", whereas ISP with ASN 5089 has redistributed those prefixes into BGP, and they're flagged with "?" indicating 'incomplete' or uncertain origin.

level 1

This is the best way, build a lab, try things out, simulate common scenarios and break them:

Community Details





###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post
r/networking Rules
Rule #1: No Home Networking.
Rule #2: No Certification Brain Dumps / Cheating.
Rule #3: No BlogSpam / Traffic re-direction.
Rule #4: No Low Quality Posts.
Rule #5: No Early Career Advice.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.