BGP Confederations – How, What and Why

We are also running OSPF internally inside the organisation.. Confederations can help with this, as each intra-confederation connection is actually a special eBGP peering and not a regul

Trang 1

pdfcrowd.com open in browser customize free license

BGP Confederations – How, What and Why.

On December 22, 2009, in BSCI, CCIE, CCIP, CCNP, by Darren

During your BGP studies, you’ll come across BGP confederations a couple of

times There are a few things that are easy to miss, and I’d like to clear it up here

This will be both theory and practical, and I’ll be using this topology to explain

things (click image for full size topology):

The routers are the same that are in my topology that I normally use The only thing that will change will be the IP addressing

so it’ll be easier to see what’s going on The topology can be found here: http://mellowd.co.uk/ccie/?p=243

Our company, AS 65535 has a multitude of routers running BGP in our core N.B: R2 and R4 will NOT be running BGP at

all We are connected to 2 ISP’s – AS100 and AS200 We are also running OSPF internally inside the organisation

BGP confederations allow your BGP deployment to scale quite nicely internally Remember the rule of BGP split horizon – i.e

a BGP router learning a route from an iBGP peer will not advertise that to another iBGP peer Confederations can help with

this, as each intra-confederation connection is actually a special eBGP peering and not a regular iBGP peer

Recent Posts

RIB, FIB, LFIB, LIB etc Creative Routing Contest 350-001 CCIE Written v4 passed

350-001 booked for 21/03/11 Route filter effects Link-State vs Distance-Vector

Do we now need a security IOS license simply to provide OSPF authentication for IPv6? – UPDATED

3560 QoS – Why am I not seeing statistics?

Do we now need a security IOS license simply to provide OSPF authentication for IPv6?

Know your IPv4 and IPv6 address ranges

Capture packets directly inside dynamips

Darren's blog about getting his CCIE number

Darren's CCIE mission

Trang 2

BGP confederations can also help with splitting up your IGP domains IGP’s like EIGRP or OSPF cannot scale to gigantic

routing table sizes IGP’s also put more emphasis on convergence speed as opposed to stability like BGP I know the

topology I have is no-where near big enough, but it does allow me to show you how it splits these IGP domains I am going to

run OSPF in both Sub-AS 10 and 30, as well as EIGRP in 10, 20 and 30 so I can seperate the OSPF portion out completely I

am going to be running OSPF in area 0 in Sub-AS 10 as well as in 30, but these will be completely independent of each other

Each router has a loopback which will be advertised R1 is 1.1.1.1, R4 is 4.4.4.4 and so on All iBGP and intra-confederation

peers will be peered using the loopback IP addresses

Configuring:

The ISP itself will have a normal BGP config, nothing special needs to be done You do need to ensure you are configuring a

peer with AS 65535 ISP1 and ISP2 do not know anything about the fact that we are running a confederation

R1 config:

R1#

router bgp 100

no synchronization

bgp log-neighbor-changes

network 1.1.1.1 mask 255.255.255.255

neighbor 192.168.1.8 remote-as 65535

no auto-summary

R8′s config is like so The BGP process must be configured under the Sub-AS number In this case AS 10 The peer

connectino between ISP1 and our company will NOT come up until I tell R8 that it should identify itself to ISP1 as being in AS

65535 As soon as the confederation identifier is in place, the peer connection will come up BGP confederation peers just

tells the router itself which AS’s are intra-confederation peers If you do not add this then the router will assume any AS

different to the one it’s using itself will be a full eBGP peer

R1#

router bgp 10

no synchronization

bgp confederation identifier 65535

bgp confederation peers 20 30

network 8.8.8.8 mask 255.255.255.255

Search

Archives

March 2011 February 2011 January 2011 December 2010 November 2010 October 2010 September 2010 August 2010 July 2010 May 2010 April 2010 March 2010 February 2010 January 2010

Trang 3

neighbor 9.9.9.9 update-source Loopback0

no auto-summary

!

router ospf 1

log-adjacency-changes

network 8.8.8.8 0.0.0.0 area 0

network 10.1.1.16 0.0.0.3 area 0

network 192.168.1.0 0.0.0.255 area 0

I’ve also added the next hop addresses into OSPF so I don’t need to use next-hop-self

To do a quick check on the peer connection, have a look here:

R1#sh ip bgp sum

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.1.8 4 65535 17 17 4 0 0 00:10:06 1

The peer is up, and as far as R1 is concerned, R8 is in AS 65535

R2 is simply running OSPF and nothing else:

R2#

router ospf 1

network 2.2.2.2 0.0.0.0 area 0

network 10.1.1.16 0.0.0.3 area 0

network 10.1.1.20 0.0.0.3 area 0

Router 9 is running BGP, OSPF and EIGRP – I wouldn’t do this in the real world It’s simply to prove a point later It’s also

peered with AS20, a Sub-AS There is an important thing to note here Basically iBGP sessions do not need the ‘ebgp

multihop’ command iBGP peers do NOT have to be directly connected When SubAS’s connect to each other they DO

need it though otherwise the peer will simply not come up You can see that the peer config to R8 does not have it while the

peer config to R10 does have it This is the config:

January 2010 December 2009 November 2009 October 2009

Categories

BCMSN (2)

BSCI (33)

CCIE (62)

CCIP (57)

CCNA (11)

CCNP (59)

Dynamips (33)

Fundamentals (6)

JNCIA (10)

Juniper (11)

Lab Guides (31)

Lab Solutions (2)

Linux (13)

Misc (5)

Trang 4

router bgp 10

no synchronization

network 9.9.9.9 mask 255.255.255.255

neighbor 10.10.10.10 ebgp-multihop 2

no auto-summary

!

router ospf 1

network 9.9.9.9 0.0.0.0 area 0

network 10.1.1.20 0.0.0.3 area 0

network 10.1.1.96 0.0.0.3 area 0

!

router eigrp 1

network 9.9.9.9 0.0.0.0

network 10.1.1.96 0.0.0.3

no auto-summary

Router10 is peered with 2 other Sub-AS’s It’s also running EIGRP:

#R10

router bgp 20

no synchronization

network 10.10.10.10 mask 255.255.255.255

ROUTE (16)

SWITCH (2)

Troubleshotting (2)

TSHOOT (8)

Uncategorized (8)

Blogroll

Dynamips forum

Mr Configure Networking Forum PacketLife

Reaper Daniel's quest for CCIE

Routing Bits Vito's blog

Common tags

642-661

airpaceamdauthentication

Trang 5

no auto-summary

!

router eigrp 1

network 10.1.1.36 0.0.0.3

network 10.1.1.96 0.0.0.3

network 10.10.10.10 0.0.0.0

no auto-summary

R3, R4, R11 and R12 are more of the same of what’s just been done I’ll post just the configs here

#R3

R3#sh run | begin eigrp

router eigrp 1

network 3.3.3.3 0.0.0.0

network 10.1.1.36 0.0.0.3

auto-summary

!

router ospf 1

network 3.3.3.3 0.0.0.0 area 0

network 10.1.1.36 0.0.0.3 area 0

network 10.1.1.44 0.0.0.3 area 0

!

router bgp 30

no synchronization

airpaceamdauthentication

CCIE CCIP

CCNP

centos cisco

dump

dynagen

Dynamips

EIGRP guide

IOS ipipv6jnciajncia-er jncia-exJuniper junos lab lab practise labs

Linux mpls mpls-vpnolive ospf

practice

practise redhat

ROUTE study

study guide study guides study lab

study labs

Meta

Register Log in

Entries RSS

Trang 6

no auto-summary

R4#

router ospf 1

network 4.4.4.4 0.0.0.0 area 0

network 10.1.1.44 0.0.0.3 area 0

network 10.1.1.52 0.0.0.3 area 0

#R11

router ospf 1

network 10.1.1.52 0.0.0.3 area 0

network 11.11.11.11 0.0.0.0 area 0

network 172.20.1.0 0.0.0.255 area 0

!

router bgp 30

no synchronization

network 11.11.11.11 mask 255.255.255.255

no auto-summary

#R12

router bgp 200

no synchronization

network 12.12.12.12 mask 255.255.255.255

no auto-summary

Now there are a couple things we need to note about these special BGP peerings Usually, the next-hop address will change

Comments RSS

WordPress.org

Comments

Daniel on 350-001 CCIE Written v4 passed Jon Langemak on RIB, FIB, LFIB, LIB etc

leo on 350-001 CCIE Written v4 passed

g on 350-001 CCIE Written v4 passed

omkar on 350-001 CCIE Written v4 passed

Trang 7

Now there are a couple things we need to note about these special BGP peerings Usually, the next-hop address will change

when an update is given to an eBGP peer If we check R10′s BGP table though, we can see that the next-hop addresses have

NOT changed: (192.168.1.1 is R1′s IP address; 172.20.1.12 is R12′s)

R10#sh ip bgp

BGP table version is 8, local router ID is 10.10.10.10

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 1.1.1.1/32 192.168.1.1 0 100 0 (10) 100 i

* 8.8.8.8/32 8.8.8.8 0 100 0 (10) i

r> 9.9.9.9/32 9.9.9.9 0 100 0 (10) i

*> 10.10.10.10/32 0.0.0.0 0 32768 i

* 11.11.11.11/32 11.11.11.11 0 100 0 (30) i

* 12.12.12.12/32 172.20.1.12 0 100 0 (30) 200 i

That means updates to confederation peers will have the next-hop stay the same You need to ensure that those next hop

addresses are known by all confederation peers otherwise you’ll get what I have above, most have no valid route

If we check the BGP table on R3, we see the following:

R3#sh ip bgp

BGP table version is 20, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

r> 9.9.9.9/32 9.9.9.9 0 100 0 (20 10) i

r> 10.10.10.10/32 10.10.10.10 0 100 0 (20) i

r>i11.11.11.11/32 11.11.11.11 0 100 0 i

*>i12.12.12.12/32 172.20.1.12 0 100 0 200 i

R3 can see that the IP 9.9.9.9 came through AS 20 and 10, even though all routers are in the same major AS

The last thing I’d like to point out is the split of the IGP (OSPF in this case) Both Sub-AS 10 and 30 are running OSPF area 0

Trang 8

We can see how many times the SPF algorithm has run in each:

R9#sh ip ospf

Routing Process "ospf 1" with ID 9.9.9.9

SPF algorithm executed 3 times

R3#sh ip ospf

Let’s force the algorithm to run again by adding another loopback on Router9 and advertising it into OSPF:

R9#conf t

Enter configuration commands, one per line End with CNTL/Z

R9(config)#int lo2

R9(config-if)#ip address 99.99.99.99 255.255.255.255

R9(config-if)#router ospf 1

R9(config-router)#network 99.99.99.99 0.0.0.0 area 0

If we now check the SPF algorithm again in Both Sub-AS’s:

R9#sh ip ospf

SPF algorithm last executed 00:00:56.144 ago

R3#sh ip ospf

SPF algorithm last executed 00:27:18.572 ago

Trang 9

Leave A Response

1 Comments

Tagged with: 642661 • 642691 • 642901 • bgp • BSCI • CCIE • CCIP • CCNP • cisco • guide • ospf • tutorial

We can see in Sub-AS 10 the SPF algorithm ran 56 seconds ago In Sub-AS 30 however, it has not forced the algorithm to run

again, proving that these IGP domains are completely separate from each other

So that’s the basics of Confederations They can be very useful for a number of reasons Just be sure to remember how

exactly they operate Any questions, feel free to ask

Darren's

CCIE mission

Pages

About Contact Currently Topologies Total Cost

Stay In Touch

About Contact Currently Topologies Total Cost

More

Định dạng
Số trang	9
Dung lượng	186,19 KB