[AUDIO LOGO]
Next up, we are on Trouble Ticket 2.
We are still on MPLS Topology 3.
And let's check out our ticket.
OSPF routes on router 8--
so we're talking about looking at this router over here--
from the customer A headquarters--
so this site over here--
are showing up as OSPF E2 routes, or external type 2
routes, as opposed to Interarea routes, or O IA routes.
So we're going to be looking at the routes, of course, going
from router 6 to router 8, as it specifies.
And hopefully, we remember that if OSPF routes are showing up
as external, it's most likely due to a domain ID problem.
So let's jump in here and see if we can figure our
where the problem is.
Again, we're probably going to be focusing in on domain ID.
So again, we always want to start by verifying the trouble
ticket.
So let's just start with a show ip route here on router 8.
And we see that, yes, in fact, we
do have OSPF external type 2s coming
in for the routes on router 6.
As we mentioned, this is most likely due
to a domain ID problem.
So we might as well start our investigation
with the closest PE.
Let's just hop over to router 5 and see if we can
get an idea of what's going on.
So let's just start with a show bgp
vpnv4 unicast for the vrf Customer A1.
So we see here that we are, in fact, getting the routes
from the other side through BGP, which, of course,
we were pretty sure of, or the routes wouldn't be showing up
already.
So what we really want to do, of course,
is look at more detail on one of these prefixes.
So let's go ahead and repeat our command.
And this time, add the prefix 10.100.1.6.
So if we take a look at the details of this advertisement,
again focusing in on the domain ID,
we see that the important part of our domain ID
is set to 64, which we know is domain ID 100.
And this is how we configured all of this when we set it up
originally in this course.
So we could maybe make the assumption
that this is probably correct.
But what we really care about is not actually the number itself
but whether it matches between the different locations.
So let's go ahead and keep looking
at some more information.
Let's take a look at a route that's
coming in locally on this side, which would be 10.8.
So what we see here is on this prefix, it doesn't match.
This one is a 65, which, of course, is the equivalent
of 101 in decimal.
So as we sort of already suspected,
clearly, the domain IDs do not match.
So this is the root cause of the problem.
But let's see if we can figure out why they don't match
and what's not configured properly.
Let's start here with a show run.
And we'll look at the section OSPF.
So here we can see our problem already.
We have router OSPF 101 for VRF customer A.
And it's redistributing BGP 100 subnets.
However, there's no domain ID specified, which means,
on IOS XE, it's going to use the OSPF process
number, which is 101.
We also see, even though we weren't specifically looking
for it, that customer A2s VRF, which is OSPF process 102,
is actually configured the exact same way.
So what we need to do here is configure the domain ID.
So let's go into configuration mode into router OSPF 101.
And we'll simply set the domain ID to 0.0.0.100
to match the other side.
We'll do the same thing for process 102.
We'll exit configuration.
And again, since this is a lab, we can force this to refresh.
We'll just do a clear bgp vpnv4 unicast star.
And we'll just let this completely reset.
We'll give this just a moment to converge.
And then we'll come back and look at it.
So now that we waited a few moments, if we do our show bgp
vpnv4 unicast for the VRF customer A,
looking at our local prefix, again, this
should now hopefully be updated.
And we can see that on both of our paths,
both to router 8 and router 9, we see
that the domain ID is 64 now.
We already know that that's the domain
ID coming from the router 1 side, or the headquarters side.
So that means that they should now match.
Let's go ahead and verify the original ticket.
Let's go out to router 8 and take a look at those routes.
So on router 8, we'll simply do our show ip route again.
And we see clearly that the OSPF routes are now showing up
as O IA, which is what the ticket said
was supposed to be done.
So this is now fixed.
So in this video, we saw how OSPF routes passing
through our layer 3 VPN environment
will come out the other side as external because, of course,
they passed through BGP in the middle.
However, if our domain IDs match on the two PEs,
they will then come through as O IA, or Interarea routes.
I hope this has been informative for you,
and I'd like to thank you for viewing.