So now we're going to turn our attention to routing throughout the domain. We just saw a
scenario where we had OSPF, for example, and up until now our focus has been on connected routes.
In our lab environment, for example, we've got a set of edges that all have directly connected
subnets and we're just seeing that these get automatically added into OMP. And for that
matter, as we talked about earlier, we can also include static routes and these also get
automatically distributed into OMP and vice versa. But let's go ahead and talk about why
we might want to consider deploying something like OSPF or EIGRP, or for that matter, potentially
even BGP. We have the capability of supporting these different routing protocols
and we might, in fact, very often in SD-WAN deployments, we're going to find that we need
to support routing protocols. So what does this look like? Well, for the most part, when we have
an edge device, a big part of what the edge device is trying to do is perform edge connectivity to
our wide area network. Now we know this is a software defined wide area network, but in the
end, we're connecting to internet, MPLS, Metro Ethernet, maybe LTE or some kind of cellular
service. So we see a lot of different wide area network technologies that are coming into these
edge devices. But the wide area network is typically pretty separated from the local area
network where our clients live. And so we often are using the wide area network to connect to other
sites, maybe other branch offices or get the branch offices to our headquarters or possibly connect
us to the data center. But what's happening down here is typically completely independent of what's
happening on our wide area network. For example, it's fairly common for me to have a pair of
distribution switches and these are running a bunch of SVIs, we call them switched virtual
interfaces, which is really just a fancy way of saying that they are VLAN interfaces.
Now, what do we use VLAN interfaces for? Well, typically we're using them for our default
gateways for our clients. So we come down here to the access layer. We've got a bunch of access
layer switches that are all communicating to the distribution layer switches, like so. And then we
have our end devices. So we have our laptops and our PCs. We have our wireless access points
communicating wirelessly to our mobile devices, tablets and phones. We've got actual IP phones,
hard wired phones, not our mobile devices, but actual phones on our desks. And maybe we've even
got things like printers out there. Maybe some kind of IP enabled fax machine, who knows?
But just all kinds of access layer devices. And these devices are the ones trying to communicate
out through the wide area network. So at this point, the question is, how do we end up connecting
all of these devices together? And the answer is usually via layer three links. I'm going to
connect a layer three link down to my distribution switches. But now notice what we have here. We've
got a bunch of VLAN interfaces. This amounts to a bunch of subnets. So how does the edge know
where these subnets live? Well, this is where we have to explore something in this realm here,
because these subnets are no longer attached to the edge device. Instead, the edge device must
learn about these in some fashion. Now, you and I, as the network admin, we could get on and
configure static routes. I'd get on here and I'd say, hey, guess what? Maybe there's only
three subnets here, subnets A, B and C. And so I'm going to get on here and say, A lives this way
and this way for redundancy, and I'm going to configure static route for B and static route for C.
Well, that starts to get untenable really, really quickly, because I could do that for all three
subnets, but there's redundancy involved, so I need to point to each individual distribution switch.
But if I have 13 subnets or 20 subnets, it starts to get really cumbersome really quickly.
And furthermore, redundancy and failures really throw a curveball at static routing. It's
typically not what we want to do for the sake of scale. Instead, our scaling is really going
to look at one of these options, these dynamic routing protocols, which is the opposite of
something that's static. If it's dynamic, it's moving. If it's static, it stays still. And that's
what we're describing our routes as doing. For example, if a subnet goes down, a dynamic routing
protocol will handle that for us a lot better than a static route would. So this is a very common
scenario. This right here might be a headquarters location. It might be a large remote site.
But we see that we've got distribution switches with SVIs that must advertise routes back and
forth. And so that's exactly what we end up doing here, is we won't run routing protocols
to the distribution switches. And again, we can take our pick here. In most cases, we'll pick OSPF
or EIGRP because these are fairly simple to deploy and they scale very well. They're really
very speed-oriented routing protocols. We want things to be very fast from a subnet advertising
perspective. BGP, on the other hand, this is a little bit more built for service providers,
especially in the internet. And so there are scenarios where large corporations will deploy
BGP into this space, but most of our organizations are probably running EIGRP or OSPF. And we can
support either one with SD-WAN. So what ends up happening here is we have the concept of
redistribution. Redistribution comes back to the fact that we're automatically deploying connected
and static routes into OMP, but we're not actually doing so with OSPF and EIGRP and BGP for that
matter. In other words, I need to take, let's say EIGRP routes, and I need to advertise them or
redistribute them into OMP. But it goes the other way too. OMP routes need to come into EIGRP.
For example, if I have an edge device down here and I have subnet D living off of that edge,
well, how do these distribution switches know where D lives? Well, I'm only going to know where
D lives if OMP takes route D and advertises it back into EIGRP in the same way that EIGRP is
advertising routes A, B, and C into OMP so that the remote devices down here know where they are.
And as we know, that goes through the SD-WAN controller and the edge will build out its
routes to get to this edge if it needs to communicate. So these two edges need to know
where each other's routes are. And so what we end up with is we end up with this giant OMP
domain here in the middle, and this is where all of our edges operate, knowing full well that the
controller is the control plane. And so we've got this reflection kind of happening in the OMP realm.
But then off of any one of these edge locations like this, this could be an EIGRP domain,
and this could be an EIGRP domain. Or for that matter, it could be an OSPF domain. We don't have
to use the same routing protocols because we're not interacting directly with one another. And
for that matter, we might have two edges that share a domain. At this point, we would want to
run a single routing protocol, so maybe EIGRP or OSPF there. And so we've got all these individual
routing domains set up, and then we're performing the redistribution as we describe where EIGRP
Now a very important note in all of this is that when we configure a routing protocol
like this, this is going to be VRF specific. It's going to be configured for a single VRF at a time,
and yes, always from an SD-WAN perspective, this is a VPN. So if I have an edge device,
and I've got VPN 10, and I've got VPN 20, well I might have to configure a routing protocol for
each one. And so I could configure OSPF here and EIGRP down here, or potentially I could configure
OSPF for both. But these will be two separate routing protocol instances. OSPF in VPN 10 is very
different from OSPF running in VPN 20. These two do not interact in any way, so we don't want to
think about it as deploying one OSPF instance across all my service side VPNs. Instead, each VPN
will get its own routing protocol instances. Now we just said that this is focused on service side,
which is very important. If we want to be able to communicate from edge subnets to edge subnets
that are located out across a different, maybe at a different branch's office or something like that,
that's very important. I mean this is the entire point of the overlay.
What about the underlay? What about in here? We know OMP is running across the overlay like this
among our different edge devices, but we also know that there is an underlay down here
that's actually physically carrying the traffic from one edge to another, and for that matter
from the edges to the controllers. So what is running down here? Well the answer is usually
it's going to be something like BGP, although we could run a different routing protocol as well.
And so if that's the case, that's fine for all of these underlay service provider routers to be
running something like that, but what about this connection and this connection? If this is my edge
and this is my edge, what about these connections here? Can they run BGP if needed in order to know
how to form a connection over to the other side? And the answer is absolutely. We could absolutely
run BGP or whatever routing protocol is required there in order to communicate with our service
provider, and so that is going to happen on the transport side as well. So we can run routing
protocols on the transport side or the service side. In either case, just keep in mind the transport
side is always going to be VPN zero is going to operate in. Meanwhile the service side is going to
be VRF or VPN specific, and that's what's going to be used to exchange our edge or customer routes
across that overlay.