Now it's time to jump into the virtual lab
and configure a confederation.
Let me bring up the diagram real quick
so I can show you how we're going to tackle this task.
The first thing I'm going to do is
I'm going to configure our eBGP links right here.
I'm going to configure R4 to try and peer with an AS 300 router,
right here, R5.
Then I'm going to configure R10 in AS 400 to peer with R9
here, again, thinking it's in AS 300.
Once R4 and R10 have been tackled, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Once R4 and R10 have been tackled,
then I'm going to start implementing our confederations
here within AS 300.
So let's fire up the Virtual Lab and get going.
All right.
Here we are.
I've got MTPuTTY fired up here.
I'm on R4, which is where I said I'm going to begin the journey.
Let's go into configuration mode.
This is going to be router BGP.
And the autonomous system for R4 was BGP 200.
So if we give this a do show IP interface brief,
we can see that I am connected out gigabit Ethernet 0/0 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can see that I am connected out gigabit Ethernet 0/0
towards router 5.
This little third octet here represents router 4, router 5.
And then the last octet is the router number itself.
So if I say neighbor 100.200.45.5,
the remote autonomous system in this case is going to be 300
because R4 doesn't know or care about the confederation.
The confederation is going to serve AS 300.
So this will be a valid configuration on R4.
Similarly, I'm going to jump to the other side of the topology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Similarly, I'm going to jump to the other side of the topology.
And I'm going to configure R10.
So we go router BGP.
And in this case it was servicing
autonomous system 400.
If I give it a do show IP interface brief,
it is addressed out fast Ethernet 4/0 towards R9.
So we'll say my neighbor is going to be 150.150.90.9
and the remote autonomous system, again,
is going to be autonomous system 300.
So this establishes our external peers for the confederation.
Now we need to start building the confederation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now we need to start building the confederation.
And I'm going to start with R5 to get that done.
This is what's connected directly to R4.
And here's how we configure it.
We'll go into configuration mode and then
we'll specify router BGP.
And what we're specifying here isn't AS 300.
We're going to specify our confederation number, which
is also known as a member ASN.
The autonomous systems that make up a confederation are called
member AS's.
And the member ASNs are usually the private autonomous system WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the member ASNs are usually the private autonomous system
numbers.
So our autonomous system in this case for R5 was 65,100.
But then we can tell our BGP instance
that we are servicing a confederation with BGP
confederation identifier.
And then we say 300.
If we draw the topology real quick,
we had R4, which was AS 200.
Then it connected to R5, which serviced AS 300,
but it was in AS 65,100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but it was in AS 65,100.
It also peered with R8 down here.
And I'm going to put a little dotted line here.
This is where 65,200 is.
For these routers that are inside the autonomous system,
but serve as a connecting link between member AS's, we
have to specify who our peer confederation members are.
So in this case, we're on R5.
We've now identified that our autonomous system is 65,100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've now identified that our autonomous system is 65,100.
But our confederation ID is 300.
Now we have to tell R5, hey, it's OK to peer with 65,200.
So the command to do that is BGP confederation peers.
And then we can say 65,200.
So now on R8, when R8 and R5 initiate a connection
to each other, they'll be able to look
at the remote autonomous system and quickly identify
if this is just a peer in the confederation,
or if this is a true external BGP configuration. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or if this is a true external BGP configuration.
So now what I'm going to do is I'm
going to give it a do show IP interface brief.
And we'll take a look at the addressing for our peers
that we need to configure.
First, I'll build the iBGP connection within the member
AS, towards R6.
We'll say the remote AS s is our own AS.
And then I'll build the peer connection
towards our confederation peer, specifying
the remote AS is 65,200.
Let's jump down to R8 and configure our confederation
peer on this side.
I'll say router BGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll say router BGP.
And in this case it's going to be 65,200.
We'll specify that this is a confederation identifier of 300
so it knows that it's servicing the 300 autonomous system
externally.
Then we'll specify our BGP confederation peer is 65,100.
I can bring up the neighbor relationship now with 10.0.58.6
and the remote AS is 65,100.
Nope, that's wrong.
I typed that wrong.
It's not 10.0.58.6. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's not 10.0.58.6.
It's 10.0.58.5.
Some days you just can't type.
There we go.
Neighbor statement 10.0.58.5 remote
autonomous system 65,100.
And there it is.
The neighbor relationship comes up.
While I'm here, I'll also specify my neighbor
relationship of 10.0.89.9.
The remote AS is our own autonomous system.
And now we can finish configuring
the rest of these items here.
I'll jump to R6. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll jump to R6.
We'll go into router BGP 65,100.
Again, we'll specify this is in a confederation
and it's servicing AS 300.
Oop, typo.
I'll bring up the neighbor relationship with router 5
here.
And the neighbor relationship comes up.
I'll also go ahead and specify I want my other outbound neighbor
here, router 7, also an internal BGP session.
And if you recall, the topology looked like this.
There was R5.
There was R6.
And there was R7. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there was R7.
What do we know about iBGP relationships in this scenario?
It's that they won't forward prefixes unless we
configure a route reflector.
So, truthfully, in this scenario,
there's nothing harmful about configuring either
of these as a client so we know for sure that routes
get bounced in both directions.
So that's what I'll do.
I'll specify my neighbor of 10.0.56.5
as a route reflector client.
Then I'll do the same for router 7.
I'll say route reflector client.
And now I'll jump over to router 7 here and get it stood up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now I'll jump over to router 7 here and get it stood up.
We'll say router BGP 65,100, making
sure to specify this is in the confederation servicing AS 300
and R7 serves as an edge towards the other confederation peer.
So I'll say BGP confederation peers 65,200.
I'll bring up the neighbor relationship with R6.
And I'll start building the relationship between R9.
We'll specify it in the remote AS of 65,200, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll specify it in the remote AS of 65,200,
the confederation peer.
The last router that we need to configure
is R9, which will have three neighbor relationships--
the eBGP relationship to R10, the iBGP relationship to R8,
and then the confederation peering relationship to R7.
Let's go into BGP 65,200, tell it
that this is in a confederation servicing AS 300.
And because this is a confederation edge peer, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because this is a confederation edge peer,
we're going to specify the peers of 65,100.
If I give it a do show IP interface brief,
just to get my lay of the land, we'll
start by bringing up our eBGP relationship, out FA 4/0.
The remote AS was 400.
We'll bring up the iBGP relationship with R8
that was in 65,200.
And then lastly, we'll bring up the confederation relationship
with R7.
And that was in remote AS 65,100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that was in remote AS 65,100.
It looks like debug was on there for a second.
So I went ahead and turned debugging off.
And now from R9 I can give it a show BGP IPv4 unicast summary.
And it tells me that I must have typed something wrong
because my neighbor relationship with router 8 isn't coming up.
It tells me that the peer is in the wrong AS.
So that means I might have typed something wrong here.
If I give it a show run section router.
Yep, sure enough, I am declaring here that my R9 connection here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Yep, sure enough, I am declaring here that my R9 connection here
was in 65,100 when it wasn't.
Let's go ahead and fix that in R8.
Let's do router BGP 65,200 no neighbor 10.0.89.9 neighbor
10.0.89.9 remote AS 65,200.
And now the neighbor adjacency comes up.
So now back on R9, if I give this a show IP BGP summary,
I see that I have my eBGP relationship here going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I see that I have my eBGP relationship here going
towards AS 400, my iBGP relationship here in AS 65,200,
and my confederation peer relationship AS 65,100.
Let's now introduce a route from R10 into our BGP environment.
If I go into configuration mode router BGP 400,
we'll specify the network statement of 10.10.10.10,
a mask of 255.255.255.255 so that we can inject the loopback WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a mask of 255.255.255.255 so that we can inject the loopback
address into BGP.
Now the NLRI is coming in from R10.
We see that we've got a prefix received.
And if I give it a show BGP IPv4 unicast,
we see that this route has made it into our BGP
with the next hop address of R10's address.
Now, we know about the behavior of iBGP and eBGP.
Let's jump up to the confederation peer of R7
and give it a show BGP IPv4 unicast WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and give it a show BGP IPv4 unicast
to see how it's behaving.
As expected, it doesn't change the next hop address.
Even though this is coming from a different autonomous system,
because it's in a confederation, it still
behaves like IGP in that regard.
Notice the path 2, like we said, this came from AS 65,200.
Then it went to AS 400.
Then it was originated internally from there.
So let's go to R9, go into router BGP 65,200. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's go to R9, go into router BGP 65,200.
Specify for our neighbor 10.0.79.7.
Let's set the next hop address to be self.
Exiting out of configuration mode, I'll jump back to R7.
We'll refresh this.
And after a few seconds we do end up
getting the correct next hop address.
And it's installed in the routing table.
So if I give it a show IP route, I see now that I have a route
to 10.10.10.10 via router 9. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to 10.10.10.10 via router 9.
Now, we would expect in this case,
if we've got R7, who's got the route coming in from R9, then
we've got R6 and R5.
Because R6 is serving as a route reflector for each of these,
R7 is going to advertise this to R6, who's
then going to reflect it to R5.
But the issue here is this, again, is iBGP.
And we're not changing the next hop address.
The next hop address is 10.0.79.9, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The next hop address is 10.0.79.9,
which R7 does have a connected interface on.
However, here's another thing to think about,
is that these are all in the same autonomous system, 65,100.
And it is pretty likely that all of these devices
would be running an interior gateway
protocol like OSPF or EIGRP.
So to solve another next hop problem that you may run into,
we could configure OSPF between R5, R6, and R7.
Let's do that.
We'll just do this really lazy, OSPF 1 network 0.0.0.0 area 0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll just do this really lazy, OSPF 1 network 0.0.0.0 area 0.
I can do a do show history.
And I'll just grab this section right here.
We'll go to R6, config T, paste it, R5, and paste it.
And after just a moment, OSPF converges.
So now what I'm going to do is I'm going to go over to R6.
I'm going to exit out of configuration mode.
I'll give it a show BGP IPv4 unicast.
And look.
There's the route, 10.10.10.10 that came in from R7, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's the route, 10.10.10.10 that came in from R7,
valid next hop because it knows about how to get to this
network from OSPF.
This should have been reflected, this route off of R6 to R5.
If I go to R5 now, end show BGP IPv4 unicast.
Look at that.
There it is.
Now, lastly, the behavior is that R5 would have advertised
this network out through eBGP to R4,
but changing the next hop address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but changing the next hop address.
Let's go to R4, jump back into privilege mode,
show BGP IPv4 unicast.
And there's nothing there.
Why is there nothing there?
Because I forgot to configure the neighbor
relationship with R4 on R5.
OK, all over the place today.
Let's go router BGP 65,100 neighbor 100.200.45.4 remote AS
is 200.
Remote AS is 200 for real this time.
Neighbor relationship comes up.
Now if I go to R4, there it is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now if I go to R4, there it is.
There's the route to 10.10.10.10.
So by using a confederation, we got around the iBGP full mesh
mandatory statements to make all this work in AS 300
by splitting it up into a couple confederation AS's.
Now when a route came in through AS 400,
we were able to send it up into AS 65,100 from AS 65,200
because this AS was running an interior gateway protocol,
as well as had a route reflector.
The iBGP route was sent all the way through. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The iBGP route was sent all the way through.
And then the eBGP rules state that we
sent it outbound towards AS 200 with a new next hop.
So that's confederations in action.
I hope this has been informative for you.
And I'd like to thank you for viewing.