[AUDIO LOGO]
So the next thing we want to look at here
is loop prevention with OSPF in an MPLS layer 3 VPN
environment.
So we'll start off with a decent discussion on our diagram
about what the problem is and why we need the downward bit
to address it.
The fact of the matter is the downward bit
is set automatically on our equipment.
And this isn't something that we really need
to be overly concerned with.
But you do have to understand why it's needed
and when and how it gets set.
The other thing that's going to be of concern
and we'll spend a decent amount of time on in this video
is how this affects our customers
if they, for whatever reason, choose to use a VRF for OSPF
in their environment.
That's going to become an issue.
And we have to talk about how to handle that.
So those are going to be our two main topics--
why we need the downward bit and how that downward bit
is going to be dealt with if the customer decides to run a VRF.
So let's go ahead and jump in.
Again, we'll start off on that diagram,
talking about what the actual problem is
and why we need the downward bit to begin with.
So here's why we need loop prevention for OSPF in the MPLS
environment.
Let's take, for example, this prefix
up here on router 6 at customer A's headquarters.
This prefix, of course, is going to get advertised up here
to router 1.
This is going to get redistributed on router 1, who
is going to send it through BGP up to the route reflector.
And then of course, the route reflector
is going to reflect this back down to router 5.
At this point, router 5 is learning this update
through iBGP.
And let's keep in mind that iBGP has an admin distance of 200.
It's then going to take this update
and redistribute it back into OSPF.
This update now gets sent via OSPF to router 8.
Now, it will send it to router 9 as well.
But that's not our discussion at the moment.
I'm trying to show you how the loop can occur.
Router 8 gets the update, sends it
through this potential backdoor link between the customer's
sites up here to router 9.
Now, of course, if the customer did not
have this backdoor link, this wouldn't be happening.
However, we have to assume that the customer might have this.
This might not be two different sites.
Maybe this is just dual-attached routers at the same site.
So in my example, yes, I drew it as two different sites.
But it doesn't have to be.
Again, it could just be dual routers at the same site.
For whatever reason, routers 8 and 9
are directly connected through OSPF.
And here's where the potential problem comes in.
Router 9 could potentially advertise this
back up to router 5.
Now, remember, this is coming from OSPF now.
That means that this will have an admin distance of 110.
110 beats 200.
So the potential problem is that router 5
discards the iBGP update and starts following this OSPF
route instead.
So we can see the potential problem here
because we know that we've lost the real route now.
The route coming from the other side
is now potentially being replaced by the loop.
And if you're having any trouble seeing the loop,
just follow the green arrows.
That's your loop.
It's going to go router 5 to router 8 to router 9
to router 5, and so on.
So this is our potential problem.
Now, the very simple fix for this
would be to filter these routes as they come in on router 5.
Router 5 should not be learning any routes from OSPF
that belong to the other side--
in other words to customer A's headquarters over here,
this prefix that we started off with.
So this is exactly where the downward bit comes in.
Now, before we jump into it, are there other ways
we could filter this?
Are there other things we can do?
Of course.
If you have been following along through this entire course,
you know we have a lot of things that we
can do to filter routes.
But OSPF gives us a built-in method called the downward bit.
And here's how it works.
Remember that we are using VRFs here
on router 5 for each of these customers.
Whenever you are running OSPF in a VRF,
that router acts like a PE.
We have that sort of buried in there.
But it's acting like a PE.
What does that mean?
It means that it's implementing PE loop prevention.
PE loop prevention does two things.
Number one, when the root is first redistributed into OSPF,
it's going to set the downward bit on this update
as it's sent into OSPF.
Now, router 8 here, which is not using a VRF,
and router 9, which is not using a VRF,
will simply ignore that downward bit.
So what happens is as the update is sent between the routers
now, this downward bit is carried
through the environment.
And if this route were to get echoed back up
here to router 5, it would again have
the downward bit set on it.
This is where the second thing that PE loop prevention does
kicks in.
If you receive an update with the downward bit set
on it from OSPF in a VRF, you discard that update.
And you do not use it.
And that is where our loop prevention comes in.
Now, we're going to jump into the command line.
And we'll see that the OSPF routes have this downward bit
set on them.
As I said during the introduction,
the problem here isn't setting the downward bit.
The equipment does this for us.
We just need to understand what it does, why it's there,
and understand its functionality.
But now let's go ahead and take a look
at the potential problem with the downward bit
from the customer's perspective.
What happens if for any reason--
and it's not really for us to decide,
because we're not the customer.
What if the customer decides that they
want to use a VRF up here on router 8 for their OSPF
environment?
Well, the problem is their router
8 will then assume, since you're running OSPF in a VRF,
that it is supposed to act like a PE.
And as soon as it's supposed to act like a PE,
not only would it start setting the downward bit on its routes
potentially.
But the more important thing is the discarding
of these updates would start happening right up here now,
because now the routes coming from the service provider
have the downward bit set.
And router 8 is acting like a PE.
So essentially, we need a way to tell
router 8 that just because you're running OSPF in a VRF
does not mean you are a PE.
And for this, we have a particular feature
we're going to be looking at.
This is called VRF-Lite.
So these are the things we're going
to look at as we jump into the command line.
First, we'll just look at the updates
and see that they have the downward bit set.
And then we'll take a look at what
happens if a customer actually wants to use a VRF.
We'll actually go ahead and implement this on router 6.
But either way, it works the same way.
It's just less interfaces to have
to move to demonstrate how VRF-Lite works.
So all of that said, let's go ahead
and jump into the command line and take a look
at the downward bit.
So we'll start here on router 5, looking at the update coming
in for router 6's loopback.
So we're going to want to look at the OSPF database here.
So we'll say show ip ospf for the process 101.
We'll look for the database.
This is going to be a type 3 LSA.
So it will be a summary.
And we're looking for 10.6.6.6.
What we're looking for here is simply
that it has this flag under Options,
where it says Downward.
If you look at a prefix that does not have the downward bit
set, this will simply say Upward.
So like I said, actually setting the downward bit isn't anything
we need to worry about.
We just wanted to be aware of how it operates.
What we really want to do here is
see what happens if a customer tries to use a VRF.
So for that, let's jump over to router 6.
So what we're going to do is we're simply
going to create a VRF here.
We'll just call it WAN, for example.
We'll activate our address-family.
If we do a show ip interface brief,
this will give us an idea of the interfaces
that we need to move into the VRF.
So the first thing we want to do is go into interface gigabit 1.
We'll say vrf forwarding WAN.
This will, of course, remove the IP address from it.
So we'll have to put that back on.
The IP address here was 192.168.16.6.
And this was a /24.
So that puts the IP address back on there.
We also need to move our interface loopback 0 interface,
since that's what we were focusing on.
So again, vrf forwarding WAN.
This is saying it removed an IPv6 address as well.
And that's OK.
We're not going to worry about that for right now.
We're just going to put our /32 loopback address back on here
for IPv4.
Finally, we also need to move our loopback 100.
This is the loopback that's simply sort of pretending
to be the customer network, the customer LAN side, if you will.
If we do a show vrf, we see that we've now successfully moved
our gigabit 1, our loopback 0, and our loopback 100 interfaces
into the VRF called WAN.
Now, the problem is right now, our OSPF process
has been operating in the global routing table.
So what we need to do is we now need
to say "no router ospf 1" in order to get rid
of that global process.
Then we'll say "router ospf 1" for the vrf WAN.
We'll set our router ID again.
And we'll just again use a network statement that brings
all the networks into area 0.
We'll exit out of configuration.
And if we give this just a few seconds,
our OSPF neighborship with router 1
should come back up in this VRF.
So here we have our neighborship back up.
And let's go back over to router 1 and take
a look at our routes.
So the first thing we see here on the console
is where the neighborship went down, when we first
started configuring.
And it came back up when we were done
configuring the OSPF process.
But if we were to say show ip route for vrf Customer A,
the main thing we want to see here is that the 10.6.6.6/32 is
still coming in.
Well, it's coming in as of 35 seconds ago,
when we just reconfigured it.
What's the point?
The point here is that using a VRF on the customer router
is not affecting the customer's routes from coming
in to the service provider.
In fact, we'll hop over to router 8 and 9
and see that router 6's routes are still there as well.
It's not a problem with the outgoing routes, so to speak.
The problem is going to be on the incoming routes.
So let's verify routers 8 and 9 real quick.
And then we'll jump back over to router 6 and see
what's happening.
So again, here on router 8, we see that we have the 10.6.6.6
update.
So that's good.
And if we go to router 9, we see the 10.6.6.6 here as well.
So again, not affecting the outgoing
routes from the customer.
But of course, here's the problem.
If we go back over to router 6, and we
were to say show ip route for the vrf WAN,
well, as you can see, there's nothing here,
except local and connected.
And again, this is because the updates
are coming in from the service provider with the downward bit
set.
And of course, router 6 is now throwing those away
because it's implementing PE loop prevention.
Now, we already mentioned how to fix this.
So let's go ahead and turn on the feature VRF-Lite.
And then we'll see how we suddenly
start getting all of our updates back
in on router 6, because it's no longer acting as a PE.
Now, a couple of things to look at before we
actually turn on the feature though.
First, let's do a show ip ospf database for the 10.8.8.8.
What we want to see here is that we are, in fact,
receiving the update.
It's in our database.
It just has the downward bit set.
And therefore, we are not using it.
We're discarding it.
Discarding it, simply meaning we're not using it.
We're not going to discard it from the OSPF database.
But we're not going to use it.
So let's go ahead into configuration mode
for router ospf 1.
And this feature is as easy as this.
You say capability.
And notice it doesn't have a whole lot.
But the one we're looking for, of course, is the vrf-lite.
And notice, it even says on the description,
"do not perform PE-specific checks."
It means to not look at the downward bit.
Do not implement PE loop prevention.
So let's go ahead and turn that feature on.
We'll exit out of configuration.
Notice, as we do so that it once again bounces
that OSPF neighborship.
So clearly, this would need to be set up
during a maintenance window.
But either way, let's go ahead and check our routing table
again.
So we'll do a show ip route for vrf WAN.
And we see here that all of our OSPF routes for the other side
are back.
So there's still O IA routes.
This doesn't affect that in any way.
But they are back because we are ignoring the downward bit.
It doesn't get rid of the downward bit.
If we look at our database summary again,
this entry looks exactly the same.
It still has the downward bit.
We're just not using it for loop prevention.
So in this video, we just took a look
at how to do OSPF loop prevention
with the downward bit.
And again, it's not that we have to do anything.
We just wanted to get a clear understanding of how it works,
and see that it gets set automatically by the equipment,
and how it shows up in the database.
And we did all those things.
We also took a look at how this can adversely
affect a customer if they want to, for whatever reason,
use a VRF on the customer router.
But we also saw that there is a feature in IOS XE called
capability VRF-Lite that allows us to turn off that PE loop
prevention and allow those routers to accept the routes,
even if they have the downward bit set.
Now, the next thing we want to look at
is how to handle routes that have a backup if we want to use
MPLS as the primary path.
That can be an interesting problem,
given that our routes are currently
showing up as O IA routes.
So we have to implement something called a sham link.
And that's exactly what we get to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.