Help understanding BGP confederations

gavin.mckee · ‎11-07-2008

Hi,

I'm trying to understand BGP conferdations much better (the Cisco BGP case studies does not answer all my questions). The attached diagram and configs are froma lab I set up to try and understand how a confederation works. My problem is that router 4 has an EBGP session to R5, these routes are then passed on via an iBGP peering to R3, however R3 does not pass these onwards to R1. If I try to mesh the sessions i.e iBGP via confederation to R1 the session will not come active, trying to peer to both the loopback and the physical interfaces will not work.. Its like the router thinks its an EBGP connection without EBGP multihop configured. I did try to put neighbour 1.1.1.1 ebgp-multihop 5 in and the sessions will still not come up.

Can anyone help with my understanding or lack of?

Regards

Gavin

Help well rated

tcordier · ‎11-07-2008

I assume that the BGP peering between R4 and R5, as well as between R4 and R3 are working fine, and only your peering between R3 and R1 is not coming up. I also assume that you can ping R1 10.1.13.1 from R3, and v.v?

The BGP configuration on R3 should be something like:

router bgp 70

bgp-confederation-id 5500

bgp-confederation peers 60

neighbor 10.1.13.1 remote-as 60

and on R1:

router bgp 60

bgp-confederation-id 5500

bgp-confederation peers 70

neighbor 10.1.13.2 remote-as 70

Are the assumptions correct, and is your config about the same (I only included the configuration for R3 and R1 peering, not any other peering)?

- Thomas

Giuseppe Larosa · ‎11-07-2008

Hello Gavin,

first of all BGP sessions between different mini ASes like 60 and 70 in your example are treated in part as iBGP and in part as eBGP sessions.

In order to setup an eBGP session between R1 and R3 using loopbacks you will need:

R3

router bgp 70

neigh 1.1.1.1 remote-as 60

neigh 1.1.1.1 ebgp-multihop 2

neigh 1.1.1.1 update-source loop3

on R1

router bgp 60

neigh 3.3.3.3 remote-as 70

neigh 3.3.3.3 ebgp-multihop 2

neigh 3.3.3.3 update-source loop1

this should come up because all the routers are in IGP OSPF area 0.

Second Note:

to verify if a BGP session is up use

sh ip bgp summary and check the state and if established the number of prefixes received.

In fact, real eBGP routes have AD 20 and are preferred to OSPF (AD 110), pure iBGP routes have AD 200 and are ignored in comparison with OSPF routes.

What is the AD of confederation eBGP routes ?

20 I have seen I checked in my own test

However, I suggest to verify with

sh ip bgp prefix

and

sh ip route prefix

Third Note:

R3 is redistributing OSPF 100 into BGP.

In a initial setup I would prefer to use network commands to be safer.

Fourth Note:

In a real BGP confederations usage each mini AS has its own IGP running, because the target is to partition a very big network in smaller sub-domains.

We can say that a common IGP is not supposed between mini ASes but should be supported

Hope to help

Giuseppe