BGP Series 4: Intro to BGP, BGP Commands, AS-path, ISP, eBgp Requirements, update-source and multi-hop, iBGP Requirements

BGP Series 4

BGP Intro:

• BGP formed on Port 179.
• BGP rides on top of TCP.
• iBGP or eBGP is automatically decided by bgp based on our asn and the asn mentioned in the neighbor command
• There is a lot of differences between the capabilities and functiona lities offered by both iBGP and eBGP
• RFC 1771 is the RFC for bgp
• In BGP, the prefix/subnetmask is called as Network Layer Reachability Information (NLRI). NLRI can be IPv4 or IPv6 or multicast

BGP Commands:

• ‘Show ip bgp neighbor’ will show lots of details→ most of which we will never even use

• • We need to concentrate of neighbor state- established, active, idle
  • We can see the number of updates sent/ received
  • By default, it shows for all the neighbors. We can filter it for a particular neighbor by adding the after the command

• ‘Show ip bgp summary’ shows the status of all the bgp neighbors. Can be used to verify the bgp (iBGP/eBGP) neighborship easily .ie. check if state is ‘Established’

IGP vs BGP:similarities and differences

AS-Path:

• Tells the list of AS that the IP prefix/subnet has travelled to reach current device
• If we advertise a new IP prefix from a router in a an AS (public AS), then, when the router sends this prefix to another eBGP peer, it will update the AS-path and make the AS-path as its AS number which means the route originated from this AS (say, AS is 100, then, the router advertises AS-path as 100 to its eBGP peers)
• Then, in the other AS, when it is advertised to its iBGP peers, the AS-path attribute is unchanged
• When it reaches the next eBGP peer, the router updates the AS-path by adding its own AS-path value to the front of the old AS-path…(something like ‘200 100’ herein 200 is the asn of this bgp n/w)
• So, when this bgp advertisement reaches third AS, it will know that the route originated in ASN 100 and I got this route through ASN 200.

Ways of connecting our network to ISP:

• When we will use default-route (no routing protocols)—> single ISP1 and IP provided by ISP1 (or) IP provided by ISP1 and we are connecting to ISP1 and ISP2 with default route as ISP1 and backup default-route as ISP2. We can redistribute the static default-route to our IGP (like OSPF…)
• In case, we want to use our own IP address which we got from IANA, we need to use BGP.
• Even here, if we have single connection to ISP1, we can ask ISP1 for a private AS number from ISP1 and use that to configure BGP. But, if we want to connect to two ISPs, then, we need to get a public AS from regional registries, since the private AS of one ISP will not be same as other.
• Also, we need to note that if we are using private-AS to form eBGP neighborship with public-AS, then, when the public AS sends out our routes to another public-ebgp peer, it will remove the private as-number and only send the AS-number as its public AS since private-AS cannot be sent to the internet/ other eBGP (public-AS) peers
• For more detail, see ‘Using BGP for Outbound Traffic’ section below

eBGP Neighborship Requirements and Configuration:

• ip and asn must match actual neighbor configuration,
• router-id must not be same,
• md5 authentication must pass (note that the md5 is not part of actual bgp message, it is present on the tcp header option),
• neighbor ip must be reachable via our routing table and must be part of connected routes (by default, bgp checks only the connected routes for checking neighbor ip..if we want to use via multi-hop, then, we need to use another command in bgp and also sync that routes via some IGP)
• Can be configured using ‘router bgp ’ and then neighbor remote-as

BGP Update Source and Multi-hop :

• If we have bgp neighborship with a router, and that fails, then, we lose all bgp routes. To overcome this, two solutions:

• • First, having multiple ‘neighbor; commands between same two devices on different links (consumes more memory in bgp table, since we will have multiple entries for same route via both interface)
  • Using loopbacks to form neighborship (since, loopbacks never go down)

• Using 2nd way is recommended..but there are few problems

• • If we configure ‘neighbor <loopback-ip of neighbor’, then, bgp will go into its routing table and look into its routing table for a connected route to the loopback which will never exist and bgp will never even start...to overcome it, we need to enable multihop by adding this additional command in router bgp-> neighbor ebgp-multihop. What this does is usually bgp creates all its packets with TTL of 1 which means the neighbor must be directly connected. Upon doing this command, it creates a packet with TTL of 255 and also allowing bgp to look beyond only connected routes in its routing table for the neighbor
  • Then, we need to have a route to the neighbor...we can use static route to the neighbor’s loopback (OR) use a IGP to advertise the loopbacks.
  • After doing this, we can see tcp packets going back and forth with correct dest-ip...but bgp neighborship wouldn’t be up...this is because usually we use the interface of the connected link as source-address for bgp. But, now, the router will use the outgoing physical interface’s IP (as per routing table) as s-ip which wouldn’t match the configuration of neighbor. So, neighbor will ignore those. To overcome this, we need to source those packets from our loopback for that neighbor. We can do that by neighbor update-source . Now, they will use their loopbacks as source and everything will work

• In above, it is recommended to use as low TTL value as possible instead of default 255. In above example, TTL=2 should be enough

• Also, in above example, we used static routing because they were in different AS and we wouldn’t be having IGP between them.

iBGP Neighborship and Configuration

• iBGP is usually used when we are a transit asn. Say, a ISP sits between two other ISPs and this ISP just needs to send those routes from both sides and the routes are not meant for it. This is a classic iBGP use case. In this case, the two edge routers will be having eBGP peering, but the string of routers in middle will be iBGP peers to carry all those routes through, so that they can go back and forth.

• Requirements of iBGP are same as eBGP

• Concept of update-source is still true and required if we are using loopbacks

• A big difference here is TTL value. Here, the TTL is 255 by default. There is no need to change TTL value through ‘multihop’ command.

• • So, iBGP, by default, can create neighborships with non-directly connected neighbors.
  • But, there is a risk in this that we can create a blackhole in the network
  • Consider the example below where AS 6000 is a transit ISP between ASN 3000 and ASN 1000.
  • 
  • We establish an iBGP neighborship between R12 and R13 even though they are not directly connected
  • Now, when update of 50.0.0.0/8 n/w comes from R9 via eBGP, R12 will put the next-hop as the eBGP neighbor’s interface (we will come to this later, but this is what happens)
  • Then, in iBGP, we do NOT change the next-hop value in bgp update and keep it as it is.
  • When R13 receives the update, it sends bgp update to R8 for 50.0.0.0/8...all fine till now
  • But, when a device in ASN 1000 wants to reach a device in 50.0.0.0/8 n/w (say, 50.0.0.1), then, R8 sends the packet to R13
  • R13 looks at the destination and sees next-hop as 1.1.1.9 and looks into its routing table and sees an IGP route to 1.1.1.9. It knows that the next-hop to reach 1.1.1.9 is via R10, it sends the message to R10.
  • But, when R10 receives the packet, it will just drop the packet since the dest-ip of 50.0.0.0/8 is not present in its routing table.
  • If we are running iBGP between non-connected routers this is what will happen. So, it is probably a better idea to run iBGP all throughout your network

• For iBGP neighbors, running ‘show ip bgp neighbor’, we can see ‘internal-link’ on the first line which tells us that it is an iBGP neighborship