[AUDIO LOGO]
So the first thing we want to do is take a look
at controlling OSPF route types in our layer 3 MPLS VPN
environment.
But what exactly does that mean?
Well, in our current environment,
the way it's configured, which we will be reviewing in just
a moment, the OSPF routes going between the headquarters
and the remote sites for the customers
are coming in as OSPF external routes.
Now, obviously, that's not going to be
very ideal for the customer.
From the customer's perspective, these
should be internal routes, certainly not external.
However, they're coming in as external routes
because, of course, they're passing through BGP
redistribution in the middle.
Now, if we configure our service provider environment correctly,
then we can have their routes come through as internal.
And that's exactly what we're going
to be exploring in this video.
So let's start off by taking a look at the current situation
on our topology.
Then we'll talk about what we're trying to accomplish.
And then of course, we'll jump into the command line
and see all of this in action.
So for this video, we'll be using MPLS Topology 3.
And let's talk about what we currently have configured.
First, we know that our core network is, of course,
running OSPF and BGP.
The important aspect of our BGP configuration
is we have neighborships between the route reflector
and routers 1, 2, and 5.
So multiprotocol BGP is already configured.
There is a VRF for customer A created on router 1.
There are actually two VRFs for customer A created on router 5.
Router 1 and router 5 are configured
to do mutual redistribution between OSPF and BGP.
And probably the most important thing for this particular video
is that customer A is also configured to run OSPF.
And their devices are all in area 0.
So we can already begin to see why the routes are
coming through as external.
Router 6, for example, sends an update to router 1.
Router 1 does it's redistribution into BGP.
That then gets sent up to the route reflector.
The route reflector reflects it back down to router 5--
router 2 as well.
But that's not part of our current discussion.
And then of course, router 5 does its redistribution back
into OSPF and sends it back out to the customer sites.
The problem is that from an OSPF perspective, that
makes these updates right here, by default, E2s,
or external type twos.
And of course, the problem is this is the same customer.
It's customer A at all three of these locations.
Their routes should be internal.
Remember, the fundamental principle of layer 3 VPN
is we're supposed to be acting as a WAN
service for the customer.
So in theory, we should sort of be
invisible in this environment as the service provider.
Now, we can't completely do that with OSPF.
We'll see that as we go through this video.
Yes, we can get the routes to show up as internal.
But without a whole lot of work, which we'll also discuss,
we can't have them actually show up as if they're
coming from the same area.
So as we proceed, keep in mind that these
are in the same area.
But the routes are still going to come through as
if they're in different areas.
But at least we can make them internal.
And that's what we're going to be shooting to do.
So let's first jump into the command line
and take a look at what the current problem is
and why they're not showing up that way.
And then, of course, we'll make that happen.
So we can start here on router 6 just by doing a show ip route.
And we can see that we have OSPF routes
for all the networks on the other side-- in other words,
the remote sites.
However, we can also see that all of the OSPF routes
are in fact showing up as external type twos,
just as we said they would.
And from our discussion, hopefully, we now
understand why, because they are being
redistributed through BGP.
And our environment is working perfectly fine.
If we were to trace to, say, router 8's loopback
and source it from our loopback, we
can see that this works perfectly fine.
Now, even though this is working,
it's really not ideal for the customer.
The customer doesn't want their OSPF routes
showing up as external.
If for no other reason, keep in mind
that part of the OSPF route selection process
is to choose internal routes over external routes.
So if they had other links to these remote sites,
such as maybe a backup link, this
is going to really create a problem.
Now, that is a problem we will be addressing in an upcoming
video in this skill.
So we're going to get there.
But overall, we really don't want customer routes
to show up for the customer as external.
So let's take a look at why this is happening
and what we can do to fix it.
So to do that, let's jump over to router 1.
And let's take a look at what these routes look
like right now in BGP.
So let's start by doing a show bgp vpnv4 unicast for the vrf
Customer A. And let's look specifically at that prefix
that we were just focusing on, the 10.8.8.8.
So we can see here that we have two different paths coming
from router 5.
One of those would be from router 8.
One of them would be from router 9 on the other side.
Now, the way that we're going to get these routes to come
through as OSPF internal is for these OSPF extended community
attributes to actually match on both sides.
Now, something like the router ID
that it's learned from, of course,
won't match, just like in normal OSPF.
But the domain ID and the route type are going to be critical.
Our main focus is going to be on the domain ID.
If we focus on the domain ID, notice that it
starts with a 0x5 colon.
That is actually the domain ID type.
This is then followed by the domain ID
itself, which are the next 4 bytes, which
is this section of the number right here.
This is then followed by two more bytes,
which are actually unused.
If we take a look here at this knowledge base article,
talking specifically about the OSPF domain identifier,
we can actually see how it's split up between the domain ID
type and the actual value.
If we go down here a little bit further, focusing in on point 1
here, the OSPF domain ID, which is a total of 8 bytes,
this says, on Cisco IOS--
and they mean specifically IOS XE.
We're going to see in just a moment
that IOS XR does not do exactly the same thing here.
However, what they are saying is that it's
set to the OSPF process ID by default.
And this is what we're going to want to change.
We'll see why in just a moment.
So like we said, it starts off with that 2-byte Type field.
And for Cisco, it actually defaults to 0005.
Now, we really have no good reason to change that.
But there are a few other ones available--
0105 and 0205.
But again, we're not going to do that.
We're just going to go with the Cisco default.
We have no good reason to change the type.
We don't even really have to understand
what the different types are, although, of course,
they are documented out there.
What we're going to care about is the actual domain
identification section, as we pointed that out.
So now that we have a little more information here,
let's go ahead and jump back and take a look at our domain ID.
So now that we understand all of that about our domain ID,
we can see here that this path has a domain ID of 65.
And this one is 66.
Those are the hex equivalents of the process ID on router 5.
If we look here on router 5, when we do a show ip ospf,
remember that we have this routing process right here,
which is OSPF 101 and this process that's OSPF 102--
again, the equivalence of 65 and 66.
But if we go back over to router 1,
and instead of looking at that loopback, what if we look
at the one coming from IOS XR coming
from customer headquarters?
Notice that IOS XR is just a bit different here.
Now, we still have the entry.
And notice we still have extended communities, where
we have the OSPF route type, the OSPF router ID, the route
target, and so on.
But notice what's missing is the domain ID.
IOS XR running here on router 1, which
is what's responsible for originating this path,
is not setting the domain ID to the OSPF process ID by default.
Instead, it sets it to a null value.
So here's the fundamental problem.
When OSPF redistributes these BGP routes,
it looks at these values, and not just the domain
ID but the route type as well.
But it looks at these values and sees if they match.
If they match, it will send it into OSPF as an internal route.
If they don't match, well, we've seen the result.
It will come in as an OSPF external route.
So the easiest way to make these routes
show up as internal is simply this.
We just have to make the domain ID match on all of the VRFs
for a particular customer.
So usually, there would be like a customer ID associated
with each customer.
And we would probably just set their domain ID
to match that value.
In this case, we've been using 100
to be customer A, just based on our route targets
and things like that.
So let's just go ahead and stick with that.
And let's set our domain ID to 100, or ultimately,
what's going to be 64, once it gets converted into hex.
So let's take a look at how to do that on IOS XR and IOS XE,
because they are, of course, just a little bit different.
So let's start on IOS XR since we're already here.
All we have to do is go into the router ospf process.
We'll go into our vrf.
And we'll start by setting the domain-id.
The first thing it wants is type.
And you can see here, by the way,
we can also set a secondary domain ID.
So we could do this if we had a need to have more than one.
But we really don't, in this case,
since it's not setting one at all.
So we'll set the type.
And here we can see those different types
that we said were available.
And again, we'll just stick with Cisco's default
since we already know that that's
what IOS XE is setting anyway.
So we'll just do 0005.
The next thing it's going to want is the value.
And here we have to put the whole thing in, in hex.
It wants all six octets.
So we'll put in six zeros for the first three octets.
Then we'll put in our 64.
And again, even though they're not technically used,
Cisco does set these to 0200.
So we just need to make sure it's
going to match what's coming from IOS XE.
And if we look back up above, notice right here,
it's putting that 0200 after the domain ID.
So we're going to do the same thing so that they match.
So that's all we have to do.
We'll just hit Enter.
Commit the change.
And we'll exit configuration mode.
Now, remember, router 5 is still using the OSPF process ID.
So we have to go change router 5 as well.
So we simply go into configuration mode.
We'll start with router ospf 101.
We'll set the domain-id.
And in IOS XE, there's actually a few different ways
we could do this.
We could, if we wanted to, do the whole type thing,
put in those same type values.
And then we could, again, put in the value.
So again, could we do this the same way?
Yes, we absolutely could, if we wanted to.
But on IOS XE, there's actually an easier way here.
We can literally just put it in, in IP format.
So we can say 0.0.0.100 to set this to 64.
Really, whichever way works better for you,
you can, of course, do it either way here on IOS XE.
So we'll do it like this just to show you
that they do in fact work together just fine.
We'll do the exact same thing in router ospf 102,
again setting it to the exact same domain ID.
We'll exit configuration.
And then of course, we're going to have
to force BGP to reconverge.
Don't ever do what I'm about to do.
This is only because it's in a lab.
Hopefully, all of this would have been set up
from the very beginning in your environment anyway,
and you wouldn't be adding this sometime down the road.
We're going to clear all of our BGP VPNv4 sessions.
So this is going to force the neighborships to go
down and back up, of course.
Then we'll give BGP just a few moments to converge.
Meanwhile, we'll hop back over to router 1 and get
ready to do our testing.
So it's been a few seconds.
Let's go ahead and take a look at that update
coming from router 6 now.
We see that the update from router 6
now has the domain ID set.
It's the type 5.
It has the value of 64.
And it's got that 0200 on the end.
That should match the update coming from router 8 now.
And we see that it does.
Once again, the domain ID on this one
is now 64 for both paths.
So now these routes should be coming through as internal.
Let's go over and check on the customer router.
So remember, of course, before, we had all these routes coming
through as E2s.
If we do our show ip route again,
they are now showing up as O IA, or Interarea routes.
So are they showing up as internal?
Yes.
Are they showing up as coming from the same area?
No.
Now, can that be done?
Yes, it can.
And we'll get to that coming up here in just a few videos.
But it's not an easy thing to do.
And it's not something the service provider is normally
going to do.
This is how we would normally run OSPF as a CE-PE protocol
from the perspective of the route type.
We would get it to an O IA for the customer.
And that's probably about as far as we would normally go.
But there is one other thing we could do if we really had to.
Again, we'll get to that in just a minute.
Just for verification, let's make
sure they're showing up correctly on router 8 and 9
as well.
So we do a show ip route.
We see that our OSPF routes are internal here.
And on router 9, we see the exact same thing.
So this is functioning correctly.
So if we want, we can actually see this being
carried in the BGP updates.
Let's start a Wireshark capture and then clear our BGP updates
again and see the domain ID inside the BGP update.
So I started the packet capture.
And then I jumped in here under the route reflector.
And we're just going to do that clear bgp vpnv4 unicast
for everybody, just to make sure we're clearing out
the entire environment, all routers, to make
sure we're forcing that update.
That way, we make sure we capture it as the updates are
being sent to router 1.
So we see our neighborships coming back up.
Let's go ahead and jump back into Wireshark
and take a look at our capture.
So what we want to look for here in Wireshark
is this rather large update message going from the route
reflector, router 12--
so the 10.12.12.12-- going to router 1, 10.1.1.1.
And if we open this up, we see that there's
a lot of update messages here under Border Gateway protocol.
So if we open up one of these updates,
then we open Path attributes, EXTENDED_COMMUNITIES,
Carried extended communities, OSPF Domain Identifier,
then if we highlight the Subtype,
we can actually see that it's set to 0x5.
And we can see that down here in the packet decoder window.
We see that it's 05.
Now, if we look at the 4-Octet AN,
that might not look correct at first, because it says 6554112.
However, if we actually highlight that and we look
at it in the packet decoder, it's because it's getting that
00640200.
And as we said, the 0200 is just not used.
The part we're looking for is the 0064.
And we can see that is how we had set our domain ID.
So we see this information is being carried
in the VPNv4 update for BGP.
So in this video, we took a look at how to set the OSPF domain
ID on the PEs to ensure that the customer routes
coming through our layer 3 VPN environment come through
as at least OSPF internal.
Now, again, at this point, they're
coming through as O IA, indicating, of course,
that they're coming from a different area,
even though we actually know that the customer has all
of these routers in area zero.
Again, there's a way we can deal with that.
It's not exactly easy or something
that we usually do at scale.
However, it can be handled.
We'll get to that in an upcoming video.
However, before we get to that, we also
want to address OSPF loop prevention in our MPLS
environment.
And that's what we're actually going to do in our next video.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.