We covered some complex topics here in the skill, everything from backup paths to multicast operations.
So let's go ahead and jump into a topology challenge here just to make sure that we've got it all down.
We understand the scenarios that cause the need for backup paths, as well as how multicast traffic would flow in a real topology.
So we'll start with question number one here. Which site's in danger of losing access to subnet A in the event of a link failure?
The answer here is site 200. Site 200 is at risk. If we have a couple of things not go our way, then site 200 could lose access to subnet A over on the left.
Even though there might still be a viable path, let's say this way, we might still not be able to access that path.
And so that leads us to question two, which is what configuration and what event are required for the site to lose access to subnet A?
Well, first of all, we need edge 101 here to have a superior path. So maybe we're running OSPF and we have a cost of one here, and this has a cost of 10.
We just need it to have a superior path here. Now we are seeing that we've got two TLOCs. 102 has two TLOCs.
And we know these are getting advertised, four different TLOCs are getting advertised for access to subnet A to the SD-WAN controller.
The problem we have is that it has the 101 paths through the Internet and through MPLS, and these are seen as superior,
and therefore the 102 Internet and 102 MPLS are not going to get advertised.
So we're really only pushing two TLOCs down for edge 201 to consider, one of which is MPLS, which can't be used,
and the other of which is the Internet, which means that we do have a path this way, but it's our only path.
So in steady state operation, everything's good, but we know that this specific configuration is going to cause a problem,
and then the event that would cause a problem is if this link goes down, because it's our only path to subnet A.
Even though you and I can look at it and say, hey, we should go this way, it doesn't have knowledge of that path because this is not getting advertised.
So how many paths to subnet A are being advertised is a question three.
If backup paths are disabled, if backup paths are disabled, we are only advertising two paths.
But what if they're enabled? Well, if they are enabled, we get onto the SD-WAN controller,
and we configure it to send backup paths under the OMP process, then we will send all four paths.
So then we'd be sending four TLOCs here instead of two, and in the event that this goes down,
we already have another path to subnet A via edge 102, and we can take advantage of that,
because now, in this scenario, we are aware of it.
So this is where we have to look at our own network topology and try to decide, is this a concern?
Could we find ourselves in a scenario where we lose access to a subnet without backup paths?
Now, certainly, there's relatively no harm in just enabling backup paths.
We could just enable it, send the backup paths, and we'll always send the next best path.
In a lot of situations, that's not going to increase our OMP routing table by a significant degree.
But that does come with a huge caveat, which is that depends on the scale of the network.
So do we have such a large scale that we are going to be pushing out that many more routes
and populating our OMP tables to maybe too large of a degree?
So that's something we have to consider.
But we can also just look at our network and say, can this happen?
Maybe we don't have any single circuit sites.
I mean, certainly, we could have, you know, maybe site 200 has a link to the MPLS cloud,
but it happens to be down for maintenance when all of this, everything else goes down.
So that's a decision we have to make as an organization.
But just importantly, it's important for us to know that it does come disabled by default.
So that is backup paths.
Let's move on to multicast.
So a multicast source starts streaming over here on subnet A.
So it hits router 10.
It's going to try to send it upstream towards its rendezvous point.
So in our case, it might actually just send a join, let's say, to edge 101.
Or I said send a join.
It's actually just going to send the traffic to edge 101.
So this source is streaming, and we have four hosts over here, host 1, host 2, host 3, host 4, that all want to receive it.
So here's the question.
How many packets are sent by edge 101 when it receives a multicast packet for that group?
And then how many packets are sent by the replicator?
So we have to understand the traffic flow here.
We don't have PIM enabled across the SD-WAN environment.
This means I don't know to send it here and to send it here, the two sites that require the multicast traffic.
Edge 101 has no idea about that, and therefore, instead, it's going to look at OMP and realize that we have a replicator on the network.
And so we're going to send a single copy of that packet to the replicator.
So the answer to the first part of this question, how many packets are sent by edge 101?
It's only going to be a single copy of that packet.
We're just sending one packet to the replicator.
Now, the replicator is going to, thanks to OMP, have information downloading from OMP.
It's going to know that all of these hosts want a copy.
So how many packets is it going to send?
Well, it's going to send a copy to edge 301, and it's going to send a copy to edge 201, once again, importantly, via our unicast tunnels.
We can't leverage multicast for the PIM scaling as well as the fact that our underlays probably don't support multicast anyways.
And so we are going to have to perform unicast replication.
But fortunately, we only have to send a copy to each site that needs it.
If I have another site out there, let's say I have site 500 over here, and nobody actually wants that,
I don't have to send it to site 500 because nobody at that site wants it, and I know that because of OMP
and the fact that OMP is going to register every device or when a device is looking for that particular group.
So last question here, identify which edges and routers in this architecture would need to be PIM neighbors.
The big reason I'm asking this question is to make sure we know that we're not forming PIM neighborships across the SD-WAN like this.
Instead, for PIM to work, that belongs on layer three links.
So over on the left, we would need PIM running.
If you've included 102 in there, then maybe it was required.
Maybe it wasn't, depending on your vision for the topology and the scenario.
But we're likely going to have PIM enabled on all of our edges.
That would be very good.
And then over on the right, we would need PIM enabled on these routers.
And again, optionally between routers five and six certainly would give us some redundancy.
If this link were to go down, for example, then we could run multicast through those other routers.
So PIM really only belongs on the service side.
It does not belong on the transport side.
I'm not forming PIM neighborhoods with other edges or certainly not with my SD-WAN controller.
Instead, that is downstream, again, to the service side on those VPNs.
And then I leverage the replicator as part of, well, really as the centerpiece of my architecture for getting traffic across the SD-WAN in as efficient a manner as possible.
So that concludes our conversation and our challenge here as far as backup paths and multicast are concerned.
If you could answer all of these questions or at least have a really good idea of what we were getting at,
then you're in good shape because these are complex topics.
And if for any reason some of these questions are still kind of head scratchers,
then be sure to go back and rewatch these videos and maybe sit down and try to do this challenge again.
Having this knowledge at your fingertips is going to be very important for not only possibly going and taking an exam,
but also very crucially for deploying a good, robust architecture into our enterprises when we're dealing with an SD-WAN network that possibly needs some backup paths and might need to support multicast as well.
I hope this has been informative for you, and I'd like to thank you for viewing.