In this video, I'd like to chat with you
about private VLANs integrated with trunking
between two switches.
So let's imagine that this is switch one
that we configured and verified in our previous videos,
and that we have a trunk on 0 slash
0 that goes over to switch 2.
Now, if we have traffic that is sent,
let's say a broadcast is sent from this device in VLAN 200,
that broadcast is going to be seen
by other ports in that same secondary VLAN,
and it's also going to be seen by the promiscuous port, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it's also going to be seen by the promiscuous port, which
is handy if we want things like default gateways
to respond to us and so forth.
And in addition to the devices here in that same VLAN
and the promiscuous port, the broadcast
is also going to be sent over any trunks associated
with that VLAN.
So on the trunk, it would look like a broadcast source from
this device which on the 802.1Q trunk is going to be tagged
with VLAN 200.
So if this trunk is carrying VLAN 200 traffic, when
switch 2 sees it, it just sees a broadcast for VLAN 200. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
switch 2 sees it, it just sees a broadcast for VLAN 200.
So what does that mean?
Well, if we don't want VLAN 200 to be seen over here
on switch 2, we could eliminate it or remove it
from the trunk, and that way that broadcast can never
make it.
But the broadcast does go over the trunk,
and there is a VLAN 200 over here,
what's switch 2 going to do?
It's just going to forward it to all the other ports in VLAN
200.
And if switch 2 is not using private VLANs,
it won't know anything about security measures
that switch 1 was taking.
It's just going to forward that broadcast WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's just going to forward that broadcast
to all other ports in VLAN 200 and be done with it.
So I wanted you to be aware of the trunking,
and also that switch 2, by default,
is not going to know anything about our isolation
that we're trying to set up over here on switch 1.
Now, what we could do is we could implement private VLANs
in the same structure over here on switch 2.
And if we did so, and a broadcast
was sent sourced from VLAN 200, when it's received over here,
it would only be sent to the devices in the secondary VLAN
of 200, which also would be configured as a type community.
So devices over here in the secondary VLAN of 200 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So devices over here in the secondary VLAN of 200
would be able to communicate with devices over here
in the secondary VLAN of 200 as well.
So I thought for fun, here's what we could do.
I've configured private VLANs just as we did over here
on switch 1 on switch 2.
And as a test what should be able to happen
is, if we connected this roamer into a port that is associated
with VLAN 200, it should be able to communicate
with devices over here in that same secondary VLAN.
Or if we connected it to VLAN 300 over here on switch 2, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or if we connected it to VLAN 300 over here on switch 2,
it should be able to communicate with other devices
in that same VLAN 300 over here on switch 1.
And if we put it in the isolated port
it shouldn't be able to talk to anybody.
Not over here, not here, not here.
Because if it's an isolated secondary VLAN,
his port is isolated, and he's not talking to anybody
except for a promiscuous port.
So as a test, here's what I'd like to do.
Let's connect this guy over to, let's go ahead
and use gig 1 slash 1, which is part of VLAN 300, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and use gig 1 slash 1, which is part of VLAN 300,
because I basically replicated the private VLAN configuration
we had on switch 1, and I replicated it over here
on switch 2.
Now, the trunk is nothing more than a standard 802.1 Q
trunk that's connecting these two switches together carrying
all the VLANs.
It doesn't have any private VLAN specific information
configured on the trunks.
So let's go ahead and connect this guy up,
get him an IP address, and verify
that this roamer, as part of VLAN 300
in the private VLANs configured on switch 2,
that it should be able to communicate with the IP address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that it should be able to communicate with the IP address
associated with 300 dash 1 and 300 dash 2.
So while we're here, let's go ahead and connect him.
So I just drag him over, and we want to put him on port gig 1
slash 1.
Let's also, just for grins, verify that port 1 slash 1
really is associated with the secondary VLAN of 300
on switch 2.
So there's our console message saying the interface came up.
That's a good sign.
Let's do a show VLAN, private VLAN.
All right, so, right there gig 1 slash
1, where we just connected to that PC,
is associated with a secondary VLAN WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is associated with a secondary VLAN
300, which is a type community.
Fantastic start.
Let's go ahead and bring up a console interface
to our roamer PC.
So here is our roamer.
Now because I have a trunk all the way over to switch 1,
in fact, let's do this.
On switch 2, let me just verify that we have a trunk.
And we do.
So gig 0/0 is a trunk, and all the VLANs are being allowed.
That's a great start.
And let's go to the virtual PC, and let's go ahead and IP DHCP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's go to the virtual PC, and let's go ahead and IP DHCP.
So this DDORA process for DHCP, it's
getting IP address over the trunk.
In fact, what I'd like to do is, let me capture all the traffic,
start a capture, and we can see it in action.
So we'll go back to switch 2, right click, click on Capture,
and then we want to capture in gig 0 slash 0
that traffic goes across the trunk.
So I'll specify we're looking for ethernet traffic
as far as the encapsulation.
Let me bring that full screen.
All right, so it's going.
Let's go back to our client.
So let me just do an IP DHCP again WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let me just do an IP DHCP again
so we can see that traffic on the capture.
And let's go to device, here we go, 300 dash 1 on the left hand
side of the topology.
Its IP address is 10, 100, 0, 53.
We should be able to reach that from the roamer on the right.
So we'll do a ping, of 10.100.0.53, and that works.
And what we should not be able to hit
is we should not be able to hit anybody who's
in the secondary VLAN of 200 or anybody that's in the isolated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in the secondary VLAN of 200 or anybody that's in the isolated
secondary VLAN of 400.
And we could test that as well.
If we go to a device that's in the secondary VLAN of 200
on the other side, this is 200 dash 1 on the PC,
we'll do a show IP, his IP address is this right here.
I'll just copy that.
And from the roamer PC, we'll do a ping and paste that in.
And because it's in a different community VLAN,
we should not be able to reach it.
And the benefit of capturing all that is we
can now look at the packet captures
for the traffic that did work and see exactly what happened.
So I'm going to go ahead and stop the capture WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm going to go ahead and stop the capture
and make this a little bit bigger.
And there's a whole bunch of spanning tree going on.
But here's our DHCP, and if we take a look at the 802.1Q
header, it's showing that the VLAN it came from was the VLAN
ID of 300.
And then the offer came back from 10.100.0.1,
this switch 1 the DHCP server.
And look at this, the reply traffic,
I'm really glad I looked at this.
This is the switched virtual interface,
who's responsible for handing out the IP addresses.
And it's associated with the primary VLAN of 100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's associated with the primary VLAN of 100.
And so then we have the client here who made the request,
802.1Q tag of 300, and then we have the acknowledgment coming
back on 100.
All right, and then if we get down to our pings,
let me go and do a filter for ICMP,
and here we have our ping requests.
And if we take the 802.1Q header,
it's going to have 300 on the outbound,
and it's going to have 300 for the reply,
because both those devices, the roamer on the right hand side
of the topology and the client on the left,
which is also in the secondary VLAN of 300,
are both literally in VLAN 300. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are both literally in VLAN 300.
In this video, we verified that we can extend a private VLAN
across multiple switches over an 802.1Q trunk.
Now the trunk itself, nothing special about that.
It's just 802.1Q.
It's the configuration of the private VLANs on both switches
that enforces the policy.
So thanks for joining me in this video,
and I'll see you in the next one.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.