When we're configuring OSPF, and for that matter,
any of these routing protocols,
we really have to think about how the VRF configuration
impacts the routing protocol that we're talking about.
So with Edge 13, for example,
we're talking about communicating with a device
that's on VPN 10.
So we want to form an OSPF adjacency
between Edge 13 and router 134.
And again, that's going to take place
within the scope of VPN 10, which is VRF 10 on Edge 13.
There's going to be some implications with that,
and it's going to impact some of our configurations.
And so we just want to be paying attention as we go.
Also, there's a very super important detail
that we absolutely must know when we're looking at SD-WAN
and configuring OSPF.
And we'll cover it here in just a moment.
All right, so when we want to configure OSPF,
we're going to do our config-t,
and we're going to configure the OSPF on this side.
So interestingly, we're going to configure it
under the SD-WAN section,
and then once we configure OSPF here,
it'll push it to the iOS XE section as well.
And here's the super important part about this.
If we're going to configure OSPF,
we must use a process ID, which is usually arbitrary,
but we need to use a process ID that matches the VRF ID.
If we don't do this,
then the SD-WAN framework is not going to recognize OSPF
as needing to be injected back into the SD-WAN environment.
Furthermore, we do have to specify the VRF
as part of this command.
So router OSPF 10, VRF 10, and that's it.
We just had to create the routing process, whoops.
And so we created the routing process there,
and now I'm going to, or now I'm back in iOS XE mode here,
I'm just at configuration prompt.
So I'm going to get onto my interface,
which is Gigabit Ethernet 3, that's my downstream interface,
and I'm going to activate OSPF on this interface.
So IP OSPF process 10, and then I need to specify the area.
So I don't have to specify the VRF here
because the interface itself is already in VRF 10.
So I hit Enter, and that should be it.
I'm going to commit, and that was super fast.
We already see that we have formed a neighborship
with router 134, and keep in mind that the default router ID
is going to take the highest IP address
that's on a loopback.
So the 200s, which technically is the loopback
that's going to be active for BGP,
is the one that's chosen, that's not a surprise.
So I'm going to back out of this and run some show commands.
So for example, show IP OSPF neighbor,
and we do see that we've got that neighbor active right now.
And then I can do a show IP route for VRF 10,
and see, hey, am I learning a OSPF route?
And indeed I am there.
So that's fantastic.
So here's the question, what do I need to do
to get this route injected into OMP?
If I were to do a show SD-WAN OMP routes,
what's going to show up here?
Well, interestingly, the answer is that it's already there.
We are automatically distributing OSPF internal routes.
So earlier we talked about how connected and static routes
are both automatically injected into OMP.
So are OSPF internal routes,
not external routes, but internal routes are.
And we're not going to find that that's true for EIGRP
or BGP, but for OSPF internal routes,
they automatically get propagated, which is fascinating.
Because now if I look over here on the other side,
for example, edge, let's go on to edge 11 here.
If I do a show IP route for VRF 10,
I actually have that route in my routing table.
So I see that I've got 110.110.110.110.
That would be the loopback that we're advertising for OSPF.
And notice that that's there learned via OMP.
So this is exactly what we were hoping to accomplish.
We didn't even have to configure anything,
but there is a small problem here.
If I were to try to ping 110.110.110.110,
this isn't going to work.
Here's the question.
Why is it not going to work at this point?
Remember, routing must be end to end.
This device here knows where 110.110.110.110 is.
I wrote a little bit off screen.
110.110, there, like that.
What about router 134?
Does it know where any routes are?
We are taking OSPF learned routes
and injecting it into SD-WAN via OMP.
But we are not doing the same thing in reverse.
I'm not taking my OMP routes
and putting them back into OSPF, at least not yet.
And so if I were to look at router 134 here,
and I do a show IP route,
I don't have to specify the VRF
because it's not running VRFs.
It hasn't learned anything via OSPF yet.
So let's go ahead and do that.
Let's inject our OMP,
or yeah, OMP learned routes into OSPF.
So I'm going to get on to my config-t here.
I'm going to get into my router process.
And yes, this is the iOS side of things.
I'm not getting into it from the SD-WAN side.
And I'm going to use the redistribute command,
specifically redistribute OMP and then tack on subnets.
So that will advertise the subnets as they're learned.
I'm going to commit and end.
And we shouldn't see any difference on the SD-WAN side,
but on router 134,
we should see now that we're learning things via OSPF.
So it's learned as an external type two,
which is perfectly expected
because anytime I redistribute
from a different routing protocol into OSPF,
we would expect them to be external type twos.
So now if I go back to edge 11 and I ping that loop back,
we should get a response because we can, oops,
you know what?
I didn't specify the VRF.
So you'll have to trust me that this ping
wouldn't have worked in VRF 10,
but now we're going to do ping VRF 10,
110.110.110.110.
And now we can ping it.
So that is how we configure OSPF using the CLI.
Now let's take a look at the graphical user interface.
How would we have done this if we wanted to put OSPF
on a like edge 11 here, which is managed by vManage.
So let's log into manager here.
I'm going to go to configuration
and then go down to templates.
And I'm going to look at my feature templates
and we'll add one here.
So add for 8,000 V.
And then when I scroll down here,
we should see one for Cisco OSPF right here.
I'm going to add a feature template for OSPF.
This is going to add a routing process to my device.
And so we can see, let me scroll all the way up here.
I can name it something like OSPF VRF 10
or maybe we'd want to use VPN 10
since we're in the Viptela space here.
OSPF for VPN 10 is a good description.
And we start to see the different configurations.
I can assign a router ID.
I can change the administrative distance
for the different route types.
Cisco, by the way, does use 110
for all three route types for OSPF.
So keep that in mind.
This is where I could add a redistribution.
So I could choose which protocol to redistribute.
So I might want to advertise OMP back into OSPF, for example.
So that would be a good thing to do here.
And then I would scroll down a little bit more
and we'd see the area space here.
So I could say new area, area number zero.
And then I might want to add an interface here.
So I could click add interface, gigabit ethernet.
Let's say gigaethernet3.
So we're basically just replicating the configuration
that we did via CLI,
but now we're doing it via the graphical user interface.
I can also scroll down and look at the advanced options here.
And this is where I can configure OSPF authentication
on a per interface basis.
So OSPF configs like to go on the interfaces.
And so that's where they are here.
I'm just going to click add here.
And let's see here.
So now we've got the area specified.
We've got an interface in here.
One big caveat to remember is you have to click add here
because if you click save,
it's not going to warn you about the fact
that this was erased.
Trust me, I know from personal experience
that you have to click add first
and make sure it's locked in.
And then we could save if we wanted to.
Before we go though,
let's pay attention a little bit
to these advanced configurations.
Reference bandwidth is very important
in a lot of OSPF environments.
And so we would probably want to change this,
especially if we have any 10 gig links or even greater,
like we're running OSPF in the data center.
We might have 40 gig, 100 gig or greater
and reference bandwidth of 100 megabits per second
is basically saying that we'll assign an OSPF cost
to 100 megabits per second or greater.
And even if we just have gig links,
we'd really rather know the difference in OSPF.
So usually we're changing that right off the bat.
It just needs to match all the other OSPF routers
in the environment.
RFC 1583 compatible.
This is a backward compatibility concept
for running older OSPF route costs,
how route costs are calculated.
So if you're running this with older OSPF routers,
then you might want to keep this compatibility on,
which is on by default.
Originate is where we can send a default route
into the OSPF process.
And then we can specify our timers here.
But in the end, we can just click save.
And we see that we now have,
right here at the top,
we have our OSPF feature template that we just configured.
And now here's where we have to be a little bit careful.
So we don't want to just scroll down
until we see something for OSPF, like right here,
and say, oh, I'm gonna add OSPF.
Notice the section we're in for the device,
for the device template.
Transport and management VPN, this is VPN zero.
So we are talking about the transport side.
And if we need to run OSPF for any reason
to our service provider,
or maybe we're managing our own underlay
and we're running OSPF, whatever the situation is,
if I add OSPF here, that's not for VPN 10.
This is going to apply this configuration to VPN zero,
even though it's named VPN 10,
the configuration's agnostic.
It can go to any VPN.
So I'm going to not add it to this section.
Instead, keep scrolling down to the service VPN section.
This is where I want to enable it, is under VPN 10.
So I'd edit VPN 10, and I would add Cisco OSPF here,
and select my VPN 10 here.
So this is where I could click save,
and then I can update the device template if I want.
Now, I don't want, in my case,
to apply this to edges 11 and 12.
I'm just going to cancel out of this,
but that is how we would do this in manager or vManage.
So one last note on OSPF external routes.
We mentioned external routes are not injected back
into OMP by default.
So if router 134 had some static routes
it injected into OSPF, and edge 13 learned it,
it would not automatically send those.
It would only send the internal OSPF routes.
So what if I wanted to send the external routes?
Well, let's take a look at how we do that
in the user interface,
and then we'll take a look at the CLI real quick.
So here, I would go to feature templates,
and what I need to do is tell OMP
to advertise the external.
So if I need to configure OMP,
I would need to use an OMP, really highlight this,
a Cisco OMP feature template.
Now, we already configured this OMP feature template earlier,
so let's just go ahead and edit it real quick.
And right here in the advertise section,
this is where we can enable OSPF external routes,
and we can do the same thing for OSPF v3.
So that was how we do it via the UI.
Let's take a look at the CLI.
And the way we're gonna do this here,
if I just do a show SD-WAN run,
we're gonna see exactly how to configure it
based on the bottom here at the very end,
this OMP section.
We're gonna use this
for some of the other routing protocols.
We didn't have to get in here and even specify.
We don't even see advertise OSPF here.
It's not a configuration that we have to add,
nor will we see it here, it just sort of happens.
But if I wanna add OSPF external, well, I can do that.
I can do my config-t,
get into the SD-WAN side of the house,
get into OMP configuration mode,
and then use that advertise, whoops,
advertise, I need to get onto the address family first.
That's what I forgot.
Address family IPv4.
Now we can advertise a specific type of route.
And so I can choose OSPF here or OSPF v3.
And we notice that external is an option.
So I can hit enter here, I can commit.
And so that's what was required
if we do have external routes in our environment
that need to be advertised.