[AUDIO LOGO]
So finally, let's use BGP as our CEPE.
And one of the things we want to focus on
is we work through this is how little work actually
has to be done on the PE router in order to accomplish this.
Yes, of course, we will have to configure BGP neighborships
for the customer routers, but there's no additional protocols
to run.
There's no redistribution that we have to do.
It really does save a lot of work on the PE
and offloads that work to the CEs.
We're going to be setting this up for customer B
in our environment, and we will explore the one caveat
that we do normally have to work with when
handling BGP as the CEPE.
That's simply that the customers will usually have the same AS
number at multiple sites.
In fact, they may only have one AS number total.
And it may even be a private AS number that we gave them.
And that's something that we'll have to deal with
or the customer will.
So we'll explore some of those options.
So that said, let's take a look at our topology,
so we can see where we're going to be running this.
And then, of course, we'll jump into the command line
and get BGP up and running as our CEPE for customer B.
So as we mentioned, we will be configuring BGP for customer B
down here, between their headquarters
and their remote site.
Now, the first thing we're going to need here for customer B
is going to be an AS number.
So we'll go ahead and configure their AS number
on both sides as 65001.
So we'll use this private AS number
at both of their locations.
And as we mentioned, that's going
to push the redistribution job out here to the CE routers.
Now, since all of the networks are directly
connected to the CEs, we'll just do a redistribute connected.
However, of course, in the real world,
the customer would redistribute whatever core protocol
they happen to be using.
So let's go ahead and jump into the command line.
Let's just start on router 7 and get the customer routers
configured first.
So let's go ahead and begin by configuring router BGP 65001.
Then, we'll configure our neighbor.
Our neighbor here is going to be 192.168.27.2.
That's router 2's address.
And the service provider is remote AS 100.
Then let's do a redistribute connected
and do a configuration.
That's all there is.
Now, obviously, the customer might
want to redistribute something else, but, in this case,
connected will be fine.
We're going to do the same configuration on router 10.
Of course, the neighbor's address
is going to be different here, 192.168.51.5.
It's, of course, in remote AS 100.
And we'll still do redistribute connected.
Now, we'll configure the PEs.
Let's start on router 2.
Let's begin by seeing, if we have any of our BGP route
policies on this router, let's do a show rpo route policy.
And we actually see that we don't have any route
policies on this router.
So that's going to be the first thing
we're going to want to do.
Let's do a route policy.
Let's call it RP_ALL because all we're going to do
is pass all the routes.
So we'll end that policy.
So now, we have a route policy to pass all the routes through.
Now, we're going to router BGP 100 into the VRF for customer
B, into our address family for IPv4 unicast,
and we'll configure our neighbor.
The neighbor here is going to be .7.
That neighbor is a remote AS 65001.
And for the address family, IPv4 here.
We're going to put in our filters, RP_ALL.
We'll use that same filter inbound and outbound
to that neighbor.
Because, at this point, at least,
we want to send and receive all of the customer routes.
We're not trying to do any filtering here.
Let's commit our changes.
And we can exit configuration.
So here on the console, we see that neighborship just
came up, which means that we should actually
have some prefixes.
So let's do show bgp vpnv4 unicast for the VRF customer B.
And we see that we are, in fact, receiving updates
from router 7.
So, so far, this is looking good.
Let's actually jump over and configure router 5 next.
So router 5, we go into router BGP 100,
into the address family ipv4 four unicast for the VRF
customer B, and we configure our neighbor, 192.168.51.10,
which is in remote AS 65001.
We see the BGP neighborship come up, so let's verify.
We'll do a do show bgp vpnv4 unicast for the VRF customer B.
And we see all of the routes being learned through BGP.
So this is looking good.
Let's go ahead and jump out to router 10,
and let's just do a show ip route.
And unfortunately, we see nothing
but local and connected.
Well, we already know what the problem is here,
but let's do a debug ip bgp update and clear
our inbound BGP session.
We'll turn off all the debugging.
And we already see here what the problem is.
We're getting all of these prefixes,
but they're, of course, denied because they contain our AS
number.
Now, there are a few ways we can fix this.
So let's take a look at a couple of them,
and we'll talk about one of them.
So we could simply do this.
We could go back to router 5, go back up to our neighborship
and just change the option and say as override.
Let's go back over to router 10 and clear the updates again.
We won't even leave the debug on this time.
We'll just say what happens.
And we see, just like that, we're
now receiving all of the BGP updates
because the AS is being removed.
If I were to say, show ip bgp, we can see that what's happened
is the 65001 that was put on by router
7 has been removed and replaced with AS 100
from the service provider.
So as you can see, this is a very nice, clean solution,
which is partially why it was created,
that we can use to simply replace the customer's
AS with the service providers.
So now, let's go over and take a look at a different option.
Let's configure this one on router 7 itself.
Because we'll look first, but router 7
is having the same problem.
So again, jumping over to router 7, if I do a show ip route,
we can see we have the exact same issue.
Now, we don't have to do the debugging everything.
We know what the problem is.
However, we could fix it a slightly different way here.
We could simply say, to allow our own AS
in from that neighbor.
If we do that, if we do our show ip route, give it a second.
But here, we come across an interesting problem.
Notice that after several refreshes of the routing table,
and, in fact, I can do it again, we're
still not getting the updates, even though we should be.
So let's turn on our debug and see what's happening.
Let's do our refresh again.
That's a lot of input.
Notice, all these routes-- wait, no, there's no routes.
Let's go up to router 2 and see what's going on here.
Because we're not even receiving the updates here on router 7.
It's not a matter of our own AS being in the AS path.
So let's go up to router 2 and see what's going on.
On router 2, let's do a show BGP for the VRF customer B.
And for our neighbor 7, let's see what routes
are being advertised to it.
We can see that this is a very, very long list of nothing.
This explains a lot of what's going on router 7.
It's not getting any of the updates.
And the reason for this is because of IOS XR's behavior.
It already knows that the path contains 65001,
and it's not going to send those updates to a device
that it knows is in 65001.
So even though allow AS in is possibly
a solution we could use here, it's
not going to save us from having to do AS override here
on router 2.
So let's go back into configuration, back into router
BGP 100, back into customer B.
Then, we're going to configure our neighbor, 192.168.27.7,
into the address family IPv4 unicast for that neighborship,
and we're going to configure AS override.
We'll commit those changes and exit configuration.
Now, if we hop back over to router 7,
we can see, since our debug was still running,
that as soon as we got done configuring router 2,
it went ahead and sent us all of the updates.
Now, we'll turn off the bugs.
We'll do a show ip bgp, and we'll
see that the AS override is, in fact, what's in effect.
So can allow AS in be an appropriate solution?
Yes, but only if the other device is actually
sending us the routes.
Another possibility could be to have the service provider
remove private ASs, assuming that the customers are
using private ASs.
So there could be multiple solutions to this,
but the best one is going to be the AS override.
Just to make sure everything is working,
let's ping 10.10.10.10 and source it from our loopback
zero interface.
We can see that this is working.
So now, we have BGP up and running as our CEPE.
So in this video, we set up BGP as our CEPE.
And as we saw, that was very easy to do.
We configure a few neighborships.
We have the prefixes go right through,
no redistribution, no extra protocols.
The only issue we had was when the neighboring sites
are using the same AS number.
So we had to do AS override or, possibly,
one of the other solutions to fix that.
But AS override is definitely the best solution.
So that covers everything we need
to discuss in this skill, which leaves us
with just a review in the form of a quiz,
and we're going to do that next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.