Categories R&S

BGP – implement and troubleshoot Scalability – Confederations

BGP confederation are also used to facilitate the iBGP peering. It reduce the need of full mesh peering.

 

By using confederation, you split the AS into smaller sub-Ass.

We still need to make a full mesh inside our sub-AS.

The peering between sub-ASs behave like an eBGP.

 

Requirements:

Create two sub-ASs (65001 and 6002).

Establish the peering between the two ASs.

 

Establish the peering to AS 10 and 20.

 

Diagram:

confederation

 

Configuration and verification:

So the BGP configuration when implementing confederation is a bit different.

The BGP process is configured using the sub-AS and the “real” AS comes after.

 

Let’s configure our first confederation 65001 between R1, R5 and R6.

R1(config)#router bgp 65001
R1(config-router)#bgp confederation identifier 100
R1(config-router)#neighbor 10.100.10.50 remote-as 65001
R1(config-router)#neighbor 10.100.10.66 remote-as 65001
R1(config-router)#redistribute connected route-map LOOPBACK

R5(config)#router bgp 65001
R5(config-router)#bgp confederation identifier 100
R5(config-router)#neighbor 10.100.10.49 remote-as 65001
R5(config-router)#neighbor 10.100.10.66 remote-as 65001
R5(config-router)#redistribute connected route-map LOOPBACK

R6(config)#router bgp 65001
R6(config-router)#bgp confederation identifier 100
R6(config-router)#neighbor 10.100.10.50 remote-as 65001
R6(config-router)#neighbor 10.100.10.65 remote-as 65001
R6(config-router)#redistribute connected route-map LOOPBACK

 

Let’s check our iBGP sessions.

R1#sh ip bgp sum
BGP router identifier 10.100.1.1, local AS number 65001
BGP table version is 2, main routing table version 2

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.100.10.50    4        65001       2       5        2    0    0 00:00:54        0
10.100.10.66    4        65001       2       6        2    0    0 00:00:23        0

Our sessions are UP, the local AS number is seen as our sub-AS.

Now let’s have a look at the routes received by BGP.

R1#sh ip bgp 10.100.1.5
BGP routing table entry for 10.100.1.5/32, version 3
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.100.10.50 from 10.100.10.50 (10.100.1.5)
      Origin incomplete, metric 0, localpref 100, valid, confed-internal, best
      rx pathid: 0, tx pathid: 0x0

The route is tagged as “confed-internal”, that’s a new BGP attributes (AS_CONFED_SET).

 

We do the same for the sub-AS 65002 between R2, R3 and R4.

Our iBGP sessions are also UP.

R2#sh ip bgp sum
BGP router identifier 10.100.1.2, local AS number 65002
BGP table version is 2, main routing table version 2

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.100.10.18    4        65002       2       5        2    0    0 00:00:26        0
10.100.10.34    4        65002       2       6        2    0    0 00:00:04        0

 

The two sub-ASs are now configured. It’s time to establish the peering between them.

R1(config)#router bgp 65001
R1(config-router)#neighbor 10.100.10.2 remote-as 65002

R2(config)#router bgp 65002
R2(config-router)#neighbor 10.100.10.1 remote-as 65001

 

I was expecting them to peer but no…

I get a BGP notification on R2 stating that R1 is in the wrong AS.

%BGP-3-NOTIFICATION: received from neighbor 10.100.10.1 active 2/2 (peer in wrong AS) 2 bytes 0064

The 0064 is in hexadecimal, it equals to 100.

R2 is reporting that R1 is in AS 100 and not 65001.

 

I’m missing an important command here, we MUST identify our confederation peers.

R1(config-router)#bgp confederation peers 65002

R2(config-router)#bgp confederation peers 65001

And here we go, the BGP session between R1 and R2 is UP.

R1#sh ip bgp sum
BGP router identifier 10.100.1.1, local AS number 65001

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.100.10.2     4        65002       7       7        7    0    0 00:00:35        3

 

We check one of the routes received from R2, we see them as “confed-external”.

R1#sh ip bgp 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 5
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  (65002)
    10.100.10.34 (metric 20) from 10.100.10.2 (10.100.1.2)
      Origin incomplete, metric 0, localpref 100, valid, confed-external, best
      rx pathid: 0, tx pathid: 0x0

 

Now, let’s move on and finish our peering with AS 10 and AS 20.

On R6 we configure the peering with R10.

R6(config-router)#neighbor 192.168.10.1 remote-as 10

 

The BGP session comes UP, and as you can see, R10 see R6 AS as 100.

R10#sh ip bgp sum
BGP router identifier 10.10.1.10, local AS number 10

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.10.0    4          100       8       6       22    0    0 00:01:02        6

 

We do the same on R3 to establish the peering with R20.

R20#sh ip bgp sum
BGP router identifier 10.20.1.20, local AS number 20

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.20.0    4          100       8       5       16    0    0 00:00:08        7

 

Let’s examine the BGP routes received on R10.

R10#sh ip bgp
BGP table version is 23, local router ID is 10.10.1.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.10.1.10/32    0.0.0.0                  0         32768 i
 *>  10.20.1.20/32    192.168.10.0                           0 100 20 i
 *>10.100.1.1/32    192.168.10.0                           0 100 ?
 *> 10.100.1.2/32    192.168.10.0                           0 100 ?
 *> 10.100.1.3/32    192.168.10.0                           0 100 ?
 *> 10.100.1.4/32    192.168.10.0                           0 100 ?
 *> 10.100.1.5/32    192.168.10.0                           0 100 ?
 r> 10.100.1.6/32    192.168.10.0             0             0 100 ?
R10#sh ip bgp 10.20.1.20
BGP routing table entry for 10.20.1.20/32, version 23
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  100 20
    192.168.10.0 from 192.168.10.0 (10.100.1.6)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
R10#sh ip bgp 10.100.1.3
BGP routing table entry for 10.100.1.3/32, version 18
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  100
    192.168.10.0 from 192.168.10.0 (10.100.1.6)
      Origin incomplete, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

All routes are seen as external, and only the AS 100 is display. There is no mention of our sub-ASs.

 

 

 

That’s all for BGP confederation.

Thank you for reading.

 

 

 

BGP – implement and troubleshoot Scalability – Confederations