There are so many posts and other learning material about BGP out there! One of my favorites is the bucktowntiger‘s You Down With BGP? rap.

Admit it, being more innovative when discussing this technology is somehow mission impossible. My intension is not to challenge that, I’m only trying to add a few hints from my operational experience, which I hope you will find useful :-). In the next few posts I will discuss these topics:

  • multihop eBGP
  • BGP support for a dual AS configuration (useful in network AS migrations)
  • responsible generation of the default route for a downstream AS

As discussed recently, the operation of BGP relies on underlying routing protocol which provides solid and stable connectivity between BGP speaker and reachability for the next-hops of BGP routes. This is important for all flavours of BGP. Let us look into another example of the “important-of-being-reachable” rule. This pictures shows a simple topology of a customer AS 300 connecting to its upstream provider (AS 1).

multihop_ebgp_basic

AS 1 uses multihop BGP for that kind of service. He has deployed a dedicated BGP router somewhere in the core of his network (router R1) which is also used as a BGP route-reflector within the AS 1. This way, the provider can offer BGP connectivity to his customers without running eBGP all around the access part of his network. More, the central BGP router like R1 can carry full internet routing table which can be announced to customers who will like to have more control in their routing decisions. A couple of routers like R1 will do the job.

In our example, AS 300 connects with his router R3 to a another router in AS 1 (router R2) via a point-to-point link. There are a few important things to point out in this setup:

  • R3 must have a solid and highly preferred route toward R1 (2001:db8:1::) – this is a prerequisite for R3 to be able to reach R1 and establish a BGP session
  • the peering address of R3 (2001:db8:2::23:1 or the whole interconnect subnet 2001:db8:2::23:0/64) must be known to all other core routers in AS 1 – this is important for next-hop reachability for routes announced by AS 300
  • all routers in AS 1 core must be informed about announcements from AS 300 in order that they can efficiently forward the traffic for AS 300

Being a Cisco box, R3 can be configured like this:

hostname R3
!
interface GigabitEthernet0/0
! this is the interface with R2 in AS 1
 ipv6 address 2001:DB8:2::23:1/127
 ipv6 enable
!
router bgp 300
 bgp router-id 3.3.3.3
 neighbor 2001:DB8:1:: remote-as 1
 neighbor 2001:DB8:1:: ebgp-multihop 2
 neighbor 2001:DB8:1:: update-source GigabitEthernet0/0
 !
 address-family ipv6
  ! we will statically announce this /48; note the static route below
  network 2001:DB8:3::/48
  neighbor 2001:DB8:1:: activate
!
ipv6 route 2001:DB8:1::/128 2001:DB8:2::23:0
ipv6 route 2001:DB8:3::/48 Null0

A snippet from R1’s configuration:

hostname R1
!
interface Loopback0
 ipv6 address 2001:DB8:1::/128
 ipv6 enable
 ipv6 ospf 1 area 100
!
router bgp 1
 bgp router-id 1.1.1.1
 neighbor 2001:DB8:2::23:1 remote-as 300
 neighbor 2001:DB8:2::23:1 ebgp-multihop 2
 neighbor 2001:DB8:2::23:1 update-source Loopback0
 !
 address-family ipv6
  neighbor 2001:DB8:2::23:1 activate
  neighbor 2001:DB8:2::23:1 default-originate
  neighbor 2001:DB8:2::23:1 route-map OriginateDefault out
!
route-map OriginateDefault deny 10

In the multihop eBGP session we have set TTL to 2 for the originating BGP packets. The hop count of 2 is sufficient in our simple topology but might be increased to a higher value in real networks. A generation of the default route is configured on R1 with an accompanying route-map that block all other announcements except for the default. We will discuss the generation of the BGP default route later.

Not shown in the configuration above is how R1 learns a way toward R3’s 2001:db8:2::23:1. This is accomplished by underlying OSPF. For example, on router R2:

hostname R2
!
interface GigabitEthernet1/0
 ipv6 address 2001:DB8:2::23:0/127
 ipv6 enable
 ipv6 ospf 1 area 300
!
ipv6 router ospf 1
 router-id 2.2.2.2
 passive-interface default

Of course, R1 and R2 must establish an internal BGP session which provides sufficient routing information for R2 to reach AS 300 and other foreign ASs that peer with AS 1. This is set up at other core routers in AS 1 as well. Router R1 is configured for a BGP route reflector and other routers are configured as clients.

hostname R1
!
router bgp 1
 bgp router-id 1.1.1.1
 bgp cluster-id 1.1.1.1
 neighbor 2001:DB8:2:: remote-as 1
 neighbor 2001:DB8:2:: update-source Loopback0
 !
 address-family ipv6
  neighbor 2001:DB8:2:: activate
  neighbor 2001:DB8:2:: route-reflector-client
!

hostname R2
!
interface Loopback0
 ipv6 address 2001:DB8:2::/128
 ipv6 enable
 ipv6 ospf 1 area 0
!
router bgp 1
 bgp router-id 2.2.2.2
 neighbor 2001:DB8:1:: remote-as 1
 neighbor 2001:DB8:1:: update-source Loopback0
 !
 address-family ipv6
  neighbor 2001:DB8:1:: activate
!


A couple of notes for a wrap-up:

  • Provider router R1, being a BGP route reflector, does not set next-hop to self, therefore next-hops for all reflected routes are not changed in the process of reflection and must be known via underlying IGP, OSPF for example.
  • Provider core must have an adequate routing information to reach router R3’s peering address which is the next-hop for all the prefixes originating from a customer AS.
  • Customer router R3 must have an explicit route for R1 in its routing table. This will be, by default, used as a next-hop for all routes that R1 will announce. The establishment of the BGP peering with R1 must not affect the active path toward R1.
  • A maximum number of hops for a multihop eBGP session must be determined and configured accordingly. Don’t rely on defaults.
Advertisements