Must know

Practical BGP will focus on examples based on concrete cases. Through configurations and validation, you should by the end of this document be able to understand how to configure BGP and be familiar with its basics.

Before that, there are few rules and guidelines which must be known and understood.

  • BGP is vector path routing protocol, so BGP does not hold a complete topology like link-state OSPF.

  • Loop prevention relies on AS-path attribute, if a BGP router sees its own AS in the path, it discards it.

  • BGP is designed for scalability, Internet routing table is approaching 800,000 routes.

  • BGP default hold timer is 180s, but will use a lower value if peering neighbour is set to less.

  • BGP session is maintained with hellos, which are sent at a third of hold time.

  • neighbour peer address can be directly connected, learn by IGP or static route, but not default route.

  • Autonomous systems number, AS are now 4bytes, instead of 2 bytes.

  • Private AS used to be in the range [65,512-65,535] and now [4,200,000,000–4,294,967,294].

  • A peering session towards router with same AS number is iBGP session

  • A peering session towards router with different AS number is eBGP session.

  • Within the same AS, an iBGP router will never advertise a route learnt from another iBGP peer.

Basic configurations

Using this topology, we shall configure basic peering sessions templates for iBGP, eBGP and observe output and validation commands.

AS100 is running OSPF process 10, with all nodes in area0 for simplicity. R1 peers with R4, R3 with R5 and R4 with R5. Only relevant information will be shown, with a recommendation that you lab these steps yourself.

  • Basic BGP Configurations

Configure iBGP in AS100

In AS100, OSPF is configured, and loopback0 for R1, R2 and R3 advertised as connected. Configuring iBGP in AS100 between R1-R2 & R2-R3 is between loopbacks and not directly connected links.

3 commands to note:

  1. “no bgp default ipv4-unicast”: Allow us to use different AFIs ( address family identifiers).
  2. “update-source Loopback0”  : Is needed when you are not using directly connected link address.
  3. Under address family “neighbor x.x.x.x activate”
Copy to Clipboard
Copy to Clipboard
Copy to Clipboard

Validation

For validating BGP sessions are established, “show ip bgp summary” will clearly show all sessions in up state, how long they have been up for, number of prefixes received and additional information.
I prefer to use “show bgp ipv4 unicast summary” instead. It gives the same results, but is more geared towards working with different BGP AFIs.

Configure eBGP

Using directly connected addresses, we configure a BGP session between R1-R4 & R3-R5.
Configuration is the same as iBGP, the only difference is  remote AS is obviously not the same as for local AS.

Configure eBGP Multihop

We add loopback10 on each of R4 & R5, as well as static routing for them on opposite router. Using these loopback addresses, we can establish an eBGP multihop session between R4 & R5.

Following config are added to both R4 & R5, note the use of  “ebgp-multihop“. This will increase default eBGP ttl, from 1 up to 255

Advertising prefixes

We now have BGP sessions up and established, but we are not advertising any routes. There are few methods to add prefixes to BGP:

Network statement
Under correct BGP AFI, a network and mask statement is used. The statement must exactly match a prefix in the routing table, else it will not end up in BGP.
100.4.4.0/24 exist in the routing table, therefore we can add it under ipv4 unicast AFI.

Redistribution
Redistributing an IGP to BGP is also a valid method. This can be static, OSPF or directly connected.

  • Do not advertise BGP into IGP. If a full internet table is redistributed into your IGP, it will cause havoc.

Copy to Clipboard

Full mesh

For R2 to advertise 100.4.4.0/24 learnt from R3, to R1. R1, R2 and R3 must either have a full mesh iBGP session, or R2 must become a route reflector, with R1 and R3 as its clients.

Therefore another iBGP session was established between R1 and R3 loopbacks.

next-hop-self

When a router advertises a prefix learnt from another AS, it will set to next hop to that router. When R1 receives 100.4.4.0/24, it will advertise it with 172.16.2.4 as next hop. Very often, this address is not redistributed in AS100 IGP. R2 does not know about 172.16.2.4, and as a result will not advertise it to any other peers.

In below “show bgp ipv4 unicast 100.4.4.0/24“, next hop 172.16.1.4 shows as inaccessible.
Solution is for R1 to set next hop as self, when peering with R2. R3 must do the same when peering with R2. After which next hop changes to R1 implicit router id, which is 1.1.1.1.

Copy to Clipboard