The next policy we're going to take a look at is the concept of the VPN membership policy.
We might look at this and say, what's the point of VPN membership policies?
Because I'm not going to see my vSmart or my SD-WAN controller.
I'm not going to see it pushing down those routes to a device that doesn't have the VPN configured.
And so when we look at our own lab environment, we know we've got edges 11 and 12 here at two different sites.
And we do have networks in VPN 20. So this is within the world of VPN 20.
We've used 10.20 to represent subnets within that routing space.
And then over here we have another site. We have sites or edges 13 and 14 at site 13.
And yeah, we've got VPN 10, but we do not have VPN 20.
And so what is happening with the SD-WAN controller is it receives the 20 routes
and it knows that 20 isn't configured at site 13.
Therefore, it's going to send those routes and reflect them back to one another.
But we don't actually send those to site 13.
So we can prove that out just by taking a look at edge 13 here at site 13.
So, for example, I can do a show IP route VRF 20 to take a look at the routing table for VPN 20.
It doesn't even exist.
And so I can also do my show SD-WAN OMP routes.
We'll take a quick look at that and see if we're even just sitting on any of those routes for VPN 10.
So when we look at our subnets here, I do see a few of the subnets that we've talked about getting advertised in here.
And as always, it's a little difficult at this resolution to read this.
It'll look a whole lot better on your screen.
But I do see VPN 10 routes in here, but I don't see any VPN 20 routes.
But we know VPN 20 is working.
If we look at the other hosts, we can ping back and forth.
So edge 13 doesn't have any VPN 20 information.
So I can go in and create a VPN membership policy on the SD-WAN controller,
and it'll make sure we don't send any VPN 20 information down to site 13.
So again, now we ask the question, well, wait a second.
We're already not sending that information down.
So why would we care about deploying a VPN membership policy?
Well, here's why.
Imagine that we are a service provider.
We have VPNs 10 and 20 run by or that represent different customers, different organizations entirely.
And so over here at site 13, we have a customer who manages their own router, and they have access to VPN 10.
Or for that matter, maybe we have a service tech that manages it.
We have our interns managing the routers, which is a classic case.
And so what happens is somebody does something they're not supposed to on edge 13.
We do a config T, and we just create the VRF definition for 20.
Now, this does require being a little bit intentional.
We would have to create the route distinguisher.
We talked about that earlier on.
And we'd have to do the entire configuration.
But this isn't a stretch to think that maybe we might see that somebody gets in here and thinks that this site needs.
I can't talk and type at the same time.
Somebody at this site might need VPN 20, we might think.
So we get on here, and we start creating the full configuration.
So we've got to get our route targets in place.
That would be an export and import route target that identifies the route distinguisher.
There we go.
And we'll commit this change.
So we haven't done anything.
We haven't configured any VPN 20 routes.
We haven't done anything from that perspective.
There are no subnets at this site.
But what I did do was we created VPN 20 or VRF 20 on edge 13.
Now let's run some of those same configurations.
If I do a show IP route VRF 20, look at that.
I see the routes from sites 11 and 12.
And naturally, if they're in the routing table, if I were to take a look at the OMP side of the house, we're going to see those routes listed in the OMP table as well.
And there they are at the bottom.
So VPN 20, VPN 20.
And that is the subnet from site 11, and this is the subnet from site 12.
Because we know that VPN 20 is not supposed to be advertised to this site for whatever reason it is.
It's usually tied to privacy and security concerns because we have two different customers, maybe multiple customers here.
I guess VPN 10 is one customer, VPN 20 is another.
And so we're now all of a sudden sharing some information from an organization with a site, and they don't actually exist at that site.
Even though it was a misconfiguration by either another customer or possibly my own people in my organization.
So what we want to do is we want to offer a control plane level of protection.
Yeah, this is already, you know, we're already not sharing those routes from an efficiency perspective.
But let's really make sure that we're not going to share routes with sites that we shouldn't be sharing routes with.
So we're going to log into our SD-WAN manager here, go over to configuration, scroll down to policies.
This is where our centralized policies get deployed.
And so we want to add a policy.
So I'm going to click Add Policy.
And as always, this is where we can create groups of interest.
But if I've already created all of my groups of interest and I have created my site lists as well as my VPN lists,
if I've already created them, I don't need to create them again.
So I'm just going to scroll down and say next.
And remember, this is where we created the topology configuration by adding a topology.
I'm going to flip over to this tab, VPN membership tab.
And I'm going to use the drop down here to create a new VPN membership policy.
So I'm going to give it a name, something like let's restrict VPN 20.
We don't want to advertise it.
So in the description, we can be a little more detailed.
Restrict VPN 20 from site 13.
And now we're going to create a site list.
So we're going to add sites 11 and 12 here.
And we're going to allow VPNs 10 and 20 into these sites.
So this is, again, where the creation of our site lists and VPN lists, if we only created individual ones, we'd have to select a bunch of lists.
We don't have to select a bunch of lists here because we created lists that consist of multiple entities, multiple sites, multiple VPNs.
And so we just select one site list and one VPN list in this case.
I'm also going to click add a list here.
And when it comes to site 13, we're only going to allow VPN 10.
So now I will click save.
And we should see the policy listed here.
I'm going to click next.
And then I'm, again, not going to add any other types of policies here into this framework.
So I'm going to click next here.
And now we need to name the policy itself.
So I'm going to call this policy restrict VPN 20.
And, again, we can call it restrict VPN 20 from site 13.
I could review the policy down here, but I'm just going to click save policy.
And now, just like before, we need to activate this.
So I'm going to notice this bottom one is the one I just created.
I click the ellipses.
I say activate.
We're going to apply this to the controllers.
I can click this over here just like we did before.
Go to the config diff.
Scroll all the way to the bottom.
And now we should see things that look a little familiar to us based on what we did with the topology.
So we enter policy mode and lists.
And, again, keep in mind, these lists are going to get pushed any time they're needed and they're not already on there.
We're not pushing all the lists, as we said.
We're only pushing the ones that are needed.
So in my case, I'm only pushing the VPN 10 and the combined VPN list.
I don't have to push the VPN 20 list because it's not in use by this policy.
I do need the site 13 list.
I need the sites 11 and 12 list.
And from here, I create my VPN membership policy.
So it gives this crazy long name because the automation process did that.
And, again, this is a match and action statement, so sequence 10.
We're matching against VPN 10 and saying we're accepting that, but we're rejecting all the other VPNs.
Then notice we have a second VPN membership policy where we're matching both VPNs and accepting.
So, as we can imagine, this one that's restricting, I'm not allowing VPN 20 here.
I'm rejecting it.
The one ending in 283 is going to have to go on site 13, whereas the other sites get both of the VPNs.
So 323, I just said that wrong, 283, I don't know where I got that, 283 right here is getting applied to site 13,
whereas the other policy is getting applied to the other two sites.
Notice with the VPN membership policies, by the way, they just get added as policies not in an inbound or outbound direction.
So we just have to know that this is something that gets applied in general as opposed to directionally.
So that's where some of our policies don't actually have directions.
So we're going to go ahead and activate this.
And once this is in place, we'll go ahead and flip over and take a look at what happened at the CLI.
Okay, so again, that only took a few seconds.
Let's go ahead and change over.
We'll go ahead and take a look at things from Edge 13's perspective.
So let's just go ahead and get the diagram back on there so we can see it.
If we want to call that a diagram, looks more like chicken scratches to me.
But, all right, so we're on Edge 13.
Let's just go and do a show IP route for VRF 20.
Now, remember, we still have this definition in place.
I got on here.
I created the definition.
I did not remove the definition, which is why it gives me a routing table.
We actually do have a routing table, but notice what's missing.
We don't have any routes.
We weren't given any routes before we were.
And now if I go take a look at OMP, as we might expect, we're going to find that I've got VPN 10 routes in here but not VPN 20.
And that's because now, rather than this situation where the controller was actually willing to push VPN 20 information down when VPN 20 was created,
now we have a policy in place that does not allow this.
So even though VPN 20 is still here on Edge 13, the controller is not willing to push that information down.
But it is still pushing it down to the other sites.
At least we should hope that.
So let's go ahead and take a look at that by logging into Edge 11 here.
And we'll do a show IP route for VRF 10.
Let's make sure we still have VPN 10 routes.
And we do.
And make sure we still have VPN 20 routes.
And we do.
So we still have the route to VPN 20 site 12.
And so I should be able to ping the host over there.
So ping in VRF 20.
And then it would be 10.20.12.15.50.
That would be our Ubuntu host.
And that did look good.
So let's go ahead and do a little bit of cleanup here.
And actually, now that I think about it, site 13 should never need VPN 20 routes.
So we'll just leave this policy in place.
No reason to do any amount of cleanup.
But hopefully now taking a look at this,
we understand that there is a big difference between being efficient with our VPN propagation
and being intentional, especially from a restriction and a security perspective.
We need to respect the privacy of our different customers.
And, therefore, we have the tools in place now to deploy a VPN membership policy
where we are in complete control of which sites
and potentially which edges belong to which VPNs.