It's one thing and a pretty good thing
to configure private VLANs.
It's even a better thing to verify
that it's working, which is exactly what we're going
to do in this video right now.
So here on the switch, let's do a show interface status.
That's a good one.
So show interface status shows us that we have,
for the ports that we configured,
we've got a couple of VLANs associated
with a primary VLAN and the secondary VLANs respectively.
That's a very good sign.
Another great command is show VLAN private,
and that's going to show us our association WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that's going to show us our association
between primary and secondary VLANs,
also the type of secondary VLANs,
whether it's isolated or community,
and then also the ports involved with that.
If we hit the Up Arrow key and we
added the keyword Type, that's going to show us
very similar information, but it won't show us
the ports involved.
So we have VLANs 100, 200, 300 and 400
respectively and their types, primary, community
and isolated.
Another really great command is if we took a look at a port.
For example, let's take a look at port gig 0/1.
If we did a show interface gig 0/1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we did a show interface gig 0/1,
I highlighted it to copy it and I didn't use it,
and then we tag along the words switch port.
That's going to give us good detail about what's really
going on with that port including how it's
administratively configured, how it's operationally functioning,
so private VLAN host, and then under here,
the administrative private VLAN host association,
it shows 100 is the primary VLAN.
That's my title, by the way, based
on the name I gave that VLAN, and it
shows the secondary VLAN, which is
appropriate for that port gig 0/1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
appropriate for that port gig 0/1.
If we did that for a port in the VLAN 300, it was 1/1,
and that shows us the secondary VLAN of 300.
And if would do the Up Arrow key again,
2/1 should be in the isolated secondary VLAN,
which was VLAN 400.
So sure enough, so there's the host association.
100 is the primary VLAN and 400 is the isolated VLAN.
So besides looking at the show commands, what's
another way we can really verify that the private VLANs are
controlling the traffic the way we expect them to? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
controlling the traffic the way we expect them to?
And the answer to that would be, let's connect some devices
to those ports and verify whether the traffic is allowed
or not.
So to verify that, here's what I did.
I took the switch that we just configured and I connected
a couple of virtual PCs to it.
So this is the secondary VLAN of 200
which we associated gig 0/1 0/2 with, and then 1/1 and 1/2,
we did the secondary VLAN of 300,
and those were both community secondary VLANs.
And then this guy, 400, we associated
ports 2/1 and 2/2, and this is an isolated VLAN. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ports 2/1 and 2/2, and this is an isolated VLAN.
So what should happen is these devices,
we should have connectivity between here and here
and between here and here, but we should not
have any connectivity between devices
that are in the secondary VLAN of 200
and the devices that are in the secondary VLAN of 300,
and then for these poor saps over here,
because this is the isolated VLAN,
that secondary VLAN is not allowing any communication
between each other.
Now the good news is they should all
have access to the promiscuous port, which is our SVI. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have access to the promiscuous port, which is our SVI.
So interface VLAN 100, which is the primary VLAN, that's
the interface for it.
We associated that interface with the secondary VLANs
of 200, 300, 400, so all these devices should be able to ping
10.100.0.1, which is the IP address associated with this
SVI, the Switch Virtual Interface,
because it is a promiscuous port associated with the primary
VLAN of 100.
So also, let me configure some DHCP services
right here so I won't have to manually hand out
IP addresses to these devices as they come up WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
IP addresses to these devices as they come up
and the multilayer switch off of this SVI
which they all have access to.
Because it's a promiscuous port, we
should be able to hand out IP addresses from this range.
It's in 100.0 network via DHCP.
So let's do that real quick to make it a little easier
to test, and then we'll test.
So here the switch will go into configuration mode
and we'll make a DHCP pool.
We'll call our pool, and then we'll put in a network
of 10.100.0.0, the 24-bit mask. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of 10.100.0.0, the 24-bit mask.
We really don't need a default gateway
because everybody's giving me that same logical IP subnet.
And we'll type in exit, then we also exclude some addresses.
So IP DHCP, excluded address, and we'll exclude 10.100.0.1
all the way through 10.100.0.50.
All right, with DHCP services in place on the multilayer switch,
give me a moment.
I'll up those virtual PCs and then we'll go to the CLI
for each one of them.
All right, so there's 200.1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, so there's 200.1.
That's the first PC and the secondary VLAN of 200,
and there's two IP DHCP.
And there we go, discover, offer, request, acknowledge.
Fantastic.
I'll repeat that for the rest here, IP DHCP.
These are little virtual PCs as part of either GNS3 or Eve-NG.
I happen to be using Eve-NG for this lab.
And we'll go to 300-2 IP DHCP, and that
looks like it's working, and then we'll to 400-1 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
looks like it's working, and then we'll to 400-1
And we'll go to 400-2 and just make sure
that it's working across the board.
All right, that's great.
And let me also do this.
I'm going to close my connection to the switch
and bring up an option that I can send commands to all
these devices at the same time.
It'll save us a bunch of time as well.
So I'm going to click on View, and I'm
going to go to the Command bar.
And this is secure CRT by the way.
I'm going to go and do a Send Commands to all sessions
and let's do a Show IP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and let's do a Show IP.
That'd be great.
That way, we can see the IP addresses on all these devices.
So 201 is 51, and then we have 52, 53, 54.
That's because I brought them up in order.
And they just got IP addresses from DHCP.
OK, great.
So what should be able to happen, if we go to 200-1,
it should be able to ping .52 because they
are in the same secondary community VLAN.
So if we do a ping to 10.100.0.52, that works,
but if we are going to try to ping like anybody WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but if we are going to try to ping like anybody
in the secondary community with a VLAN of 300 or 400,
that wouldn't work.
So that's good to device.
This is 300.
Let's try 53 and also 55.
Those should both fail.
So we'll try to pin 53, and because it's
in a different community, this isn't working.
And if we go to the last one, which
is-- what was the address?
55, that's device 400-1 in the isolated VLAN,
and we try to ping that, we're not
going any success there either because isolated devices can't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going any success there either because isolated devices can't
ping any devices in other communities.
If we went to these two devices, which is 400-1 400-2,
and they are at the IP addresses of 55 and 56.
They won't be able to ping even each other.
So if we go ping 10.100.0.55, so even though PC 400-1 and 400-2
are both in the same secondary VLAN,
because it's a type isolated, the switch is not allowing any
frames of traffic between any of those ports in that same VLAN.
Now what should be allowed to happen is every one of these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now what should be allowed to happen is every one of these
devices should be able to ping the promiscuous switch virtual
interface up on the multilayer switch,
so if we did a ping to 10.100.0.1,
that should be successful from all of our devices.
So if we go back and look at all of them,
the two PCs in the secondary VLAN of 200,
they both had success.
The two pieces, and the secondary VLAN of 300,
they both had success, and the two PCs in the isolated VLAN,
they also had success. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they also had success.
And the reason all these devices and all these secondary VLANs
can ping that SVI, that Switch Virtual Interface address,
is because that switch virtual interface is associated
with the primary VLAN and it was told
about these secondary VLANs it was able to communicate with.
So effectively, it's a promiscuous type of port
or interface on the multilayer switch that all those devices
could then use as a default gateway if they needed forward
packets off of the local 10.100.0 subnet.
I'd also like to discuss with you further WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'd also like to discuss with you further
about how VLAN tagging is used if we have private VLANs
and yet we have a trunk that goes from our switch
to yet another switch.
Let me walk you through that in the next video.
Meanwhile, I hope this has been informative for you
and I'd like to thank you for viewing.