BGP Confederation Explained

Hi Laz,

Yes, 88.1.1.0/24 is directly connected between R7 and R8, EBGP is configured via R7 and R8 on the interface which has ip add 88.1.1.0/24. I had advertised 88.1.1.0/24 on R8 via BGP, there is no OSPF advertisement of this network.

Hello Navaraj

The RIB-failure statement you are getting states that the router is learning of the 88.1.1.0/24 network from BGP. This however is a directly connected network, and should be in your routing table as such. The conflict comes from the fact that the AD of the directly connected route outranks the AD of the route being learned via BGP. However, my question is WHY is BGP advertising this route to a router that is directly connected to it? Can you investigate in this direction?

I hope this has been helpful!

Laz

Hi Laz,

I had advertised this network on R8 under BGP, that’s why it is advertised.

Hello Navaraj

Then it is natural that you will have such a message from BGP. This is not necessarily incorrect, and based on the design, is to be expected. The problem you are facing is independent of the specific BGP message that you are sharing. You will have to look elsewhere for the specific problem.

Our goal here is to help you pinpoint the problem by giving some guidelines, or information concerning the next steps to take. I hop this helps you in your troubleshooting procedures.

Laz

Hi Navraj,
As Laz said this is independent of the RIB failure likely as its a connected network for R7. You need to break it down to see where is the connectivity getting lost ? Have you tried some basic checks? May be a traceroute from your internal AS2 router to R8 ? See where is it getting broken. Look at the routing table of it and see if it has a route ? Also it is very important to understand that unless you advertise your internal prefixes in AS2 , there wont be return route in R8 or R1. So this is something to troubleshoot step by step. Hope this helps.
Thanks,
M

1 Like

Infact I set up a similar lab and I don’t see any problem. I am able to ping between R1<<>>R8

R8#ping 1.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 8.8.8.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/102/132 ms
R8#
R1#ping 8.8.8.8 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/137/220 ms
R1#

And if I ping from the AS2 I am not able to ping.

R4#ping 8.8.8.8 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4 
.....
Success rate is 0 percent (0/5)
R4#

Its because R8 or R1 don’t have any return routes to R4.

R8#show ip route 4.4.4.4
% Network not in table
R8#

As soon as I advertize 4.4.4.4 in my IBGP , I am able to ping it.

R4#sh run | s bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 2
 bgp confederation peers 200 
 **network 4.4.4.4 mask 255.255.255.255  >>>>>>> Advertizing 4.4.4.4**
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 5.5.5.5 remote-as 200
 neighbor 5.5.5.5 ebgp-multihop 2
 neighbor 5.5.5.5 update-source Loopback0
 no auto-summary
R4#
R4#ping 8.8.8.8 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4 
!!!!!

So it has no relation to RIB failure or Confedaration or Route-reflector within Sub-AS. I assume you are not advertising the internal subnet of AS 2 in your BGP.

Hope this helps.

Thanks,
Madhu

1 Like

Hi Team,

Question related to Confederation topic::

Suppose we a have topology in which R2-R3-R6 and R4-R5-R7 ( As per topology using by you in confederation topic only difference is that I connected R6&R7 next to R3&R5) are connected to each other in same AS then can we perform confederation if yes then how we divide these routers in sub-ASes to get minimun IBGP peering ?

Hello Pradyumna

Based on your description, I wasn’t able to find the lesson about which you are speaking. The lesson on confederations uses five routers, R1 through R5. However, I can respond to your question more generally.

As long as all the routers in a particular AS can communicate with each other (that is, they are able to achieve full mesh iBGP peerings) it is possible to subdivide such a topology into two or more confederations. You can simply follow the logic in the lesson to configure such a topology.

In general, it is a good idea to strike a balance between the number of confederations and the number of routers per confederation. There is no point in having too few, or too many routers within each confederation, or too few or too many confederations within an AS. Configuration complexity is lowest when the number of confederations within an AS is about the same as the number of routers within each confederation.

I hope this has been helpful!

Laz

Hi Laz,
I am speaking about the 5-Routers topology we used in confederation topic, Only added two more routers R6 connected next to R3 and R7 connected next to R5( R6 and R7 are also connected to each other) so if now you understand my query then please teach me how can we use confederation concept here and in how many ways ?
In brief connectivity like that ::

Hello Pradyumna

So you’re looking at something like this:

When configuring confederations within a single AS, the rules you have to follow are these:

  1. Routers within the sub-AS’es must have full mesh iBGP peerings.
  2. Interconnection between sub-AS’es don’t need to be full mesh, you simply need at least one peering between routers in different sub-AS’es.

So essentially, either router R6 or R7, which both belong to AS 67 simply need a single peering to either R2, R3, R4, or R5 in order to be successfully added as a sub-AS to AS2.

You can choose whatever peerings you want between routers in different sub-AS’es, as long as there is one peering for each sub-AS.

I hope this has been helpful!

Laz

Hi,
I’m tryng to replicate this lab but I have a rib error on networks redistributed by R2.

R5#show ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.11/32, version 10
Paths: (2 available, best #1, table default, RIB-failure(17))
  Advertised to update-groups:
     1
  Refresh Epoch 1
  (24) 1
    192.168.12.1 (metric 1) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  (24) 1
    192.168.12.1 (metric 1) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0
R5#
 R5#show ip bgp

 r>i 11.11.11.11/32   192.168.12.1             0    100      0 (24) 1 i
 r                    192.168.12.1             0    100      0 (24) 1 i
 *>  55.55.55.55/32   0.0.0.0                  0         32768 i
 r>i 192.168.12.0     2.2.2.2                  0    100      0 (24) i
 r                    2.2.2.2                  0    100      0 (24) i
R5#

the same error exist in other routers exept R2.
Also, R5 has selected the confed-internal route for 11.11.11.11, Is it right?

Hello Giovanni

RIB failures occur when a route (with the same prefix and prefix length) is learned via BGP, but already exists in the routing table with a lower AD. I suggest you do the following:

  1. take a look at the routing table of the routers and see if the routes that have the RIB failure are also being learned via OSPF or even via a static route. iBGP has an AD of 200, while OSPF has an AD of 110 and static routes an AD of 1.
  2. Make sure that OSPF is being used to advertise only the subnets between the routers, and the loopbacks used for the router IDs. BGP should be used to advertise only the 55.55.55.55 network on R5, and the 11.11.11.11 network on R1.

I hope this has been helpful!

Laz

Hi,

problem solved, It was caused by my attempt to redistribuite the bgp into ospf process…

1 Like

No i have another question.

I’m tryng to trace 11.11.11.11 from R5.

    R5#traceroute 11.11.11.11 source loopback 0
Type escape sequence to abort.
Tracing the route to 11.11.11.11
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.35.3 17 msec
    192.168.45.4 13 msec
    192.168.35.3 6 msec
  2 192.168.24.2 12 msec
    192.168.23.2 7 msec
    192.168.24.2 8 msec
  3 192.168.12.1 [AS 24] 13 msec 9 msec 8 msec
R5#

Can you help me to interpret this output?
Thanks

Hello Giovanni

Traceroute will always send three packets for each TTL. In other words, it will begin by sending three packets with a TTL of 1, and then another three with a TTL of 2, another three with a TTL of 3 and so on until it gets to the destination. For each iteration, it gets a response back from whatever router it reaches with that TTL value.

Now keeping that in mind, let’s take a look at the routing table of R5:

  2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/3] via 192.168.45.4, 00:04:26, GigabitEthernet0/1
                 [110/3] via 192.168.35.3, 00:04:26, GigabitEthernet0/2
  3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/2] via 192.168.35.3, 00:04:26, GigabitEthernet0/2
  4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/2] via 192.168.45.4, 00:04:26, GigabitEthernet0/1
  5.0.0.0/32 is subnetted, 1 subnets
C        5.5.5.5 is directly connected, Loopback0
  11.0.0.0/32 is subnetted, 1 subnets
B        11.11.11.11 [200/0] via 192.168.12.1, 00:03:22
  55.0.0.0/32 is subnetted, 1 subnets
C        55.55.55.55 is directly connected, Loopback5
B     192.168.12.0/24 [200/0] via 2.2.2.2, 00:03:27
O     192.168.23.0/24 [110/2] via 192.168.35.3, 00:04:26, GigabitEthernet0/2
O     192.168.24.0/24 [110/2] via 192.168.45.4, 00:04:26, GigabitEthernet0/1
  192.168.35.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.35.0/24 is directly connected, GigabitEthernet0/2
L        192.168.35.5/32 is directly connected, GigabitEthernet0/2
  192.168.45.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.45.0/24 is directly connected, GigabitEthernet0/1
L        192.168.45.5/32 is directly connected, GigabitEthernet0/1

Now remember, that OSPF is being run within AS2, and by default, equal cost load balancing is enabled. So when R5 pings 11.11.11.11, we can see what happens when we look at the routing table:

  1. There is an entry for 11.11.11.11 which is learned via BGP. It can be reached via 192.168.12.1 which is the next hop eBGP router
  2. How do we reach 192.168.12.1? There is another BGP route that tells us we can reach it via 2.2.2.2.
  3. How do we reach 2.2.2.2? There are two OSPF equal cost routes that get us there, via 192.168.35.3 and 192.168.45.4.

Equal cost load balancing, when using something like traceroute (which uses UDP) will take place on a per packet basis. So, packets are alternated between the two routes. This is why you see responses alternating between the two possible paths you can take.

In the last entry, all three responses came from Fa0/0 on R1, so they weren’t explicitly stated. But you can see this from the three response times that are indicated.

I hope this has been helpful!

Laz

Hi Guys,

Great lesson. I just want to confirm something for myself.

To quote: “R3 is in a different sub-AS than R2, you can see that it says confed-external. Something important to note is that the next hop IP address didn’t change. When you use regular EBGP, a router changes the next hop IP address of a route to its own IP address when it sends the route to another EBGP router.”

image

Are you saying that in typical eBGP circumstances, R2 would advertise the route to R3 and change the next hop to the interface it advertised the route out of e.g. “192.168.23.2” ?

Hello Joseph

Yes, that’s exactly correct. The next-hop IP for a prefix found outside of your local AS is always the IP address of the eBGP router that advertised it into your local AS. For example, take a look at this topology:

image

The next-hop IP address that R1 has in its BGP table for the 3.3.3.0/24 subnet is 192.168.23.3, which is the address of R3, which is the eBGP router that advertised the network into AS12 in the first place.

The difference that Rene is emphasizing in the statements you mentioned is that even though R2 and R3 are using eBGP (different sub-AS’es), the next-hop IP that R3 sees is that of R1, and not that of R2. This is because the R2-R3 BGP peering is not regular eBGP, but an eBGP peering between sub-AS’es.

I hope this has been helpful!

Laz

1 Like

Spot on, thanks man.

1 Like

I must be missing something. So you have to have two BGP processes running on your router, but if you try to configure a second process is says BGP is already running. What am I not understanding?

Hello Chad

Actually, you are only running a single BGP process in each router using the AS number of the sub-AS to which the router belongs. You can then configure the confederation AS containing the sub-AS’es as the confederation identifier.

In other words

  • Routers in the same sub-AS and the same confederation AS will have the same BGP number and the same confederation identifier in their configurations.
  • Routers in different sub-AS’es but in the same confederation AS will have different BGP numbers but the same confederation identifier in their configurations.

In both cases, however, there is only a single BGP process running under which both confederation and sub-AS’es are configured.

I hope this has been helpful!

Laz