|
0:00:11
|
So continuing where we left off yesterday
|
|
0:00:14
|
I want to take a couple of minutes to review what we talked about
|
|
0:00:18
|
with the Layer 2 switchports, the Layer 2 trunk interfaces,
|
|
0:00:22
|
and then creating the VLANs and doing any type of work in VTP.
|
|
0:00:27
|
So a lot of this Layer 2 stuff up to this point
|
|
0:00:30
|
hopefully is pretty straightforward for most people.
|
|
0:00:34
|
It should mostly be a review with the exception of some of those corner cases that we talked about.
|
|
0:00:39
|
So some of the commands, to review quickly,
|
|
0:00:43
|
that we can use for our verifications on the switches when we look at the show VLAN or show VLAN brief,
|
|
0:00:49
|
this is going to tell us about what the current state of the VLAN database is.
|
|
0:00:54
|
So usually in the network the VLAN databases should be synchronized
|
|
0:00:59
|
between the devices that are in the same Layer 2 network.
|
|
0:01:02
|
It means that they are agreeing on the same broadcast domain.
|
|
0:01:05
|
So in this case we can see switch one doesn't have any other VLANs other than the defaults.
|
|
0:01:11
|
So if there are switches that do have VLANs that switch one does not have
|
|
0:01:15
|
then maybe we would want to look into that particular problem.
|
|
0:01:19
|
Also when we look at the show interfaces switchport or for a particular link
|
|
0:01:25
|
This is basically going to tell us any Layer 2 information that we need to know about the particular interface.
|
|
0:01:32
|
So here we can see first and foremost that switchport is enabled.
|
|
0:01:36
|
This means that this link is running in Layer 2 mode.
|
|
0:01:39
|
The administrative mode is dynamic auto.
|
|
0:01:41
|
This is what is configured at the interface level
|
|
0:01:44
|
where the operational mode is the actual result of this.
|
|
0:01:47
|
So this means that in this case, FastEthernet 0/1 is running DTP.
|
|
0:01:52
|
It's a dynamic interface
|
|
0:01:54
|
but on the other end, DTP negotiation did not occur
|
|
0:01:58
|
so we're falling back into static access mode.
|
|
0:02:02
|
Since DTP is on, we're also negotiating the encapsulation for trunking.
|
|
0:02:08
|
And the operational trunking encapsulation is native.
|
|
0:02:11
|
This basically means that we're not running trunking.
|
|
0:02:13
|
So since the interface ended up being a static access port trunking is not enabled.
|
|
0:02:20
|
We could see also if it is an access interface, what is the VLAN.
|
|
0:02:24
|
In this case it's the default VLAN of one.
|
|
0:02:27
|
If we were running 802 dot1q
|
|
0:02:31
|
then the native VLAN in this case would be VLAN one.
|
|
0:02:35
|
Again, the only real key point about this is that if you change the native VLAN
|
|
0:02:39
|
you do need to make sure that it matches on both sides of the trunk link.
|
|
0:02:43
|
Otherwise we could run into a case where traffic is leaking between VLANs
|
|
0:02:48
|
if the two switches do not agree on what traffic should be untagged.
|
|
0:02:53
|
We have the administrative native VLAN tagging enabled.
|
|
0:02:57
|
This means on this particular switch
|
|
0:03:01
|
if we look at the show run include native...
|
|
0:03:08
|
It doesn't show up in the config here.
|
|
0:03:09
|
Let's say in global config, VLAN dot1q tag native.
|
|
0:03:16
|
Then again let's look at the show interface switchport.
|
|
0:03:23
|
So the administrative native VLAN tagging just basically means that even though
|
|
0:03:26
|
VLAN one is the native VLAN, it technically would get a tag if we were running this as a dot1q trunk link.
|
|
0:03:35
|
So again the main differences between ISL and dot1q,
|
|
0:03:38
|
ISL encapsulates everything.
|
|
0:03:40
|
Dot1q is going to tag everything with the exception of the native VLAN.
|
|
0:03:44
|
But then if we use that common
|
|
0:03:47
|
VLAN dot1q tag native in global config
|
|
0:03:50
|
it's basically going to not disable the normal properties of the native VLAN.
|
|
0:03:57
|
So again, most of the times you wouldn't need to do that.
|
|
0:03:59
|
It's really only if you have a very specific application
|
|
0:04:01
|
like some sort of firewall module or some sort of intrusion prevention system
|
|
0:04:06
|
that needs the VLAN tag in order to receive that type of traffic.
|
|
0:04:13
|
Okay, next we see that there's no particular voice VLAN.
|
|
0:04:16
|
We'll talk about this when we get into QoS and specifically our Layer 2 QoS.
|
|
0:04:21
|
Private VLANs, we'll talk about this in security.
|
|
0:04:25
|
Then we see the trunking VLANs
|
|
0:04:28
|
which is everything. This is what's controlled by the allowed list on the interface,
|
|
0:04:32
|
which is the switchport trunk allowed command.
|
|
0:04:35
|
Then after that we see the prune eligible list.
|
|
0:04:39
|
So again, remember the difference between these two
|
|
0:04:42
|
is that the trunking VLANs enable,
|
|
0:04:45
|
or the allowed list, if something is removed from that it means that that traffic will not go over the interface.
|
|
0:04:52
|
But if a VLAN is removed from the prune eligible list
|
|
0:04:56
|
or what's listed here as the pruning VLANs enabled,
|
|
0:05:00
|
this means that the traffic must be carried over the interface.
|
|
0:05:04
|
So it essentially means you cannot send a prune message for it.
|
|
0:05:09
|
Then capture mode is disabled. This means we're not doing any type of span or r span.
|
|
0:05:14
|
This is not a protected port.
|
|
0:05:16
|
We're not doing any unknown unicast blocking.
|
|
0:05:19
|
We'll talk about both of these when we get to security.
|
|
0:05:23
|
So key point being here that this
|
|
0:05:25
|
output from show interface switchport, it's basically going to show you anything you could possibly need
|
|
0:05:30
|
about the Layer 2 status of the interface.
|
|
0:05:34
|
Then we also looked at the show interface trunk.
|
|
0:05:38
|
This is going to tell us is the link currently trunking.
|
|
0:05:41
|
What is the mode?
|
|
0:05:43
|
This means are we running in dynamic mode, are we running in dynamic desirable, dynamic auto,
|
|
0:05:49
|
or in this case on which means I would have the switchport mode trunk command at the interface level.
|
|
0:05:56
|
The encapsulation is dot1q.
|
|
0:05:59
|
And we do not see an N before this
|
|
0:06:02
|
which means that the encapsulation was not negotiated.
|
|
0:06:06
|
So if we saw N-802 dot1q or N-ISL it would mean that was negotiated through DTP.
|
|
0:06:15
|
Status is trunking which is what we would want to see
|
|
0:06:18
|
since this is supposed to be a trunk link.
|
|
0:06:20
|
The native VLAN is one.
|
|
0:06:23
|
This basically means that any traffic in VLAN one would not receive a dot1q tag when it's sent over the interface.
|
|
0:06:32
|
Next portion here, VLANs allowed on the trunk - this is the allowed list which is everything by default.
|
|
0:06:38
|
Allowed and active in the management domain,
|
|
0:06:42
|
this means the VLANs that are actually in the database.
|
|
0:06:45
|
So we're not doing any filtering.
|
|
0:06:47
|
VLANs 1-4094 are allowed on the trunk.
|
|
0:06:52
|
But since only VLAN one was actually created, that's the only one that would be sent across.
|
|
0:06:59
|
Then our last output, this shows what's actually being forwarded over the link.
|
|
0:07:04
|
So remember here, this is the combination of what spanning tree says is in the forwarding state
|
|
0:07:09
|
and what VTP says is not being pruned.
|
|
0:07:13
|
So if you do not see a particular VLAN number there that you think you should
|
|
0:07:18
|
then the two outputs that you would want to check
|
|
0:07:21
|
would then be the show spanning tree, which is going to show
|
|
0:07:26
|
what particular VLANs are forwarding over the interfaces or on a particular interface, what VLANs are forwarding,
|
|
0:07:32
|
or the show interfaces pruning.
|
|
0:07:36
|
Again, the particular problem that we saw yesterday with the pruning design
|
|
0:07:42
|
was that if we had switch one configured as transparent mode
|
|
0:07:49
|
so transparent mode for VTP
|
|
0:07:52
|
and we had a case where there is
|
|
0:07:55
|
VLAN ten on switch one
|
|
0:07:58
|
VLAN ten on switch four
|
|
0:08:00
|
twenty on switch three and twenty on switch two
|
|
0:08:03
|
if VTP pruning is enabled
|
|
0:08:06
|
what would happen is that switch three sends this message out the trunk link
|
|
0:08:11
|
saying that I only need VLANs one and twenty and I want to remove anything else.
|
|
0:08:19
|
Since switch one is in transparent mode this message forwards on to switch two.
|
|
0:08:24
|
Switch two says my neighbor basically wants VLANs one and twenty and nothing else
|
|
0:08:30
|
so VLAN ten is removed from the interface in the forwarding state
|
|
0:08:35
|
which means that switch one is not going to receive that traffic.
|
|
0:08:38
|
So it's kind of a more obscure design
|
|
0:08:41
|
but you do want to be aware of the problem.
|
|
0:08:43
|
Any time you are running VTP transparent mode you should not be running pruning at the same time.
|
|
0:08:49
|
Also we saw some issues with the VTP authentication.
|
|
0:08:53
|
Even if we do not have a password configured
|
|
0:08:56
|
by default technically the switches are going to be authenticating each other.
|
|
0:09:00
|
They're going to be authenticating with a now password string.
|
|
0:09:07
|
So the password will be no by default but then this is salted with the configuration revision number.
|
|
0:09:16
|
So for some reason the revision number does not match between the switches
|
|
0:09:21
|
then you'll see that output where it says that MB5 authentication is failing.
|
|
0:09:26
|
So we can see the revision number when we look at the show VTP status.
|
|
0:09:32
|
This number here is going to tell us if the network is synchronized.
|
|
0:09:37
|
So ideally everyone in the same domain should have the same revision number.
|
|
0:09:42
|
The only exception for that would be for transparent mode switches.
|
|
0:09:46
|
They're going to have the revision number zero.
|
|
0:09:49
|
So it basically means they're not accepting updates from any of the other neighbors.
|
|
0:09:54
|
If the VLAN is removed from the prune eligible list
|
|
0:09:58
|
what is the end result of that?
|
|
0:10:01
|
So if we look at the diagram here,
|
|
0:10:08
|
the example I showed yesterday was that on switch two I removed VLAN 70
|
|
0:10:15
|
from the prune eligible list on this interface FastEthernet 0/13.
|
|
0:10:20
|
This means that when we look at the show interface trunk
|
|
0:10:23
|
even if no one has VLAN 70 assigned
|
|
0:10:27
|
switch two will be forwarding 70 out that link,
|
|
0:10:31
|
switch one will be forwarding it out this link,
|
|
0:10:35
|
and switch three will be forwarding it out this direction.
|
|
0:10:40
|
Because switch two says to switch one I need VLAN 70.
|
|
0:10:44
|
Switch one then in turn tells switch three
|
|
0:10:47
|
I am in the transit path for someone that needs 70 so you need to send me that traffic.
|
|
0:10:55
|
So the switches really don't care whether they have the VLAN assigned or whether they're in the transit path.
|
|
0:11:00
|
All they know is that they need to receive that particular VLAN number
|
|
0:11:04
|
and that's what the pruning message is used for
|
|
0:11:06
|
to tell the connected neighbor what particular VLANs that you should forward towards me.
|
|
0:11:12
|
When I talked about the native VLAN and leaking, the only way I was able to get this to work
|
|
0:11:17
|
is to disable spanning tree for that VLAN
|
|
0:11:20
|
because it will always go to blocking
|
|
0:11:22
|
and CDP complains about it.
|
|
0:11:25
|
But you can turn that off with no CDP on the interface.
|
|
0:11:28
|
Okay, so the case is that if
|
|
0:11:35
|
we have switch one connected to switch two and this is a dot1q trunk link.
|
|
0:11:45
|
On switch one I have host A that is in VLAN ten.
|
|
0:11:48
|
On switch two I have host B that is in VLAN twenty.
|
|
0:11:53
|
If switch one says that the native VLAN is ten
|
|
0:12:02
|
and switch two says that the native VLAN is twenty
|
|
0:12:08
|
it basically means that when a packet comes from A
|
|
0:12:13
|
so we have the Ethernet header
|
|
0:12:16
|
followed by the payload.
|
|
0:12:17
|
Okay, we'll assume this is IP followed by whatever the data is.
|
|
0:12:21
|
Normally as this leaves the dot1q trunk
|
|
0:12:25
|
the Ethernet headers should be edited to add the tag value that is essentially the VLAN number.
|
|
0:12:32
|
But in this case since native VLAN is ten on switch one it's going to be sent without a tag value.
|
|
0:12:40
|
This means that when switch two receives it inbound
|
|
0:12:43
|
it doesn't know what VLAN number it is because there's no tag in the header
|
|
0:12:47
|
so it assumes that it's part of the native VLAN.
|
|
0:12:51
|
So the result of this is that traffic from VLAN ten can leak into VLAN twenty.
|
|
0:12:58
|
Now the catalyst switches by default will actually try to prevent this
|
|
0:13:04
|
by using CDP to detect what is the native VLAN on both sides
|
|
0:13:09
|
and it will force DTP, the dynamic trunking protocol, to fail the negotiation.
|
|
0:13:17
|
So with the current versions of catalyst IOS they're trying to prevent this problem in the first place.
|
|
0:13:22
|
Really the only way that you could get this problem to occur
|
|
0:13:27
|
would be to disable CDP and to force the link to be a trunk.
|
|
0:13:33
|
So you would have to disable DTP on both sides and then configure the interface to be a trunk.
|
|
0:13:40
|
So we would say switchport no negotiate
|
|
0:13:43
|
switchport trunk encapsulation and switchport mode trunk.
|
|
0:13:46
|
Now additionally for this, depending on the mode of spanning tree that we are running,
|
|
0:13:52
|
if we are running per VLAN spanning tree plus, which is the default for the switches,
|
|
0:13:58
|
inside the BPDU, which is the spanning tree update,
|
|
0:14:02
|
There is going to be a field that essentially says what the VLAN number is.
|
|
0:14:07
|
So if switch one receives a BPDU that is supposed to be for VLAN twenty
|
|
0:14:14
|
and it receives it on its VLAN ten interface
|
|
0:14:17
|
the switch is going to discard that.
|
|
0:14:19
|
So with the current versions there's a bunch of protection mechanisms built in there.
|
|
0:14:24
|
So really you would have to disable spanning tree and disable CDP in order for this case to occur.
|
|
0:14:33
|
Now I believe there's one example that I put in the volume two workbook about this.
|
|
0:14:38
|
It's really an uncommon case nowadays that you would see the problem occur
|
|
0:14:44
|
but it really depends on the particular vendor's switches.
|
|
0:14:47
|
Also it depends on the version. If you have a catalyst that's running an older version,
|
|
0:14:51
|
it's not going to have this protection mechanism built in.
|
|
0:14:56
|
So theoretically the potential problem is still there
|
|
0:14:59
|
but the switch is going to try to prevent this automatically.
|
|
0:15:04
|
This example you're just showing if we had another host on switch one
|
|
0:15:09
|
that is in VLAN ten and another host on switch two which is in VLAN ten
|
|
0:15:15
|
will they be able to communicate?
|
|
0:15:17
|
Okay, and the key point is they will not.
|
|
0:15:20
|
So the modification to the design here is let's now say that we have
|
|
0:15:28
|
a second host, or a third host actually, C that is in VLAN ten
|
|
0:15:35
|
So A is in ten, C is in ten.
|
|
0:15:38
|
At this point, A and C will be able to talk to each other because they're on the same local switch.
|
|
0:15:46
|
Switch one knows that both of these interfaces are in VLAN ten.
|
|
0:15:50
|
Now if there's a fourth host that is on switch two in VLAN ten.
|
|
0:15:54
|
Let's say this is D.
|
|
0:15:57
|
Normally A and C should be able to talk to D because they're in the same broadcast domain.
|
|
0:16:03
|
The problem though is that since there is the native VLAN mismatch
|
|
0:16:07
|
there's no way for frames to come from C and then properly get delivered to D.
|
|
0:16:13
|
Because again, when switch two receives the packet inbound,
|
|
0:16:17
|
it is assuming that this traffic is supposed to be in VLAN twenty
|
|
0:16:22
|
when in reality it should not. It should be in VLAN ten.
|
|
0:16:25
|
Okay, there's another question - is there a debug to see the VLAN tags?
|
|
0:16:30
|
Unfortunately there is not. The only way that you would actually be able to see the frame as it goes across the link here
|
|
0:16:37
|
would be to do some sort of packet capture and packet analysis.
|
|
0:16:42
|
So if you had switch one, you could say for anything going out this port,
|
|
0:16:46
|
let's say that this is port ten,
|
|
0:16:49
|
we could configure a span session
|
|
0:16:51
|
that redirects to our packet sniffer and then we would be able to see what the full Layer 2 header is.
|
|
0:17:00
|
So we'll talk about this a little bit later.
|
|
0:17:03
|
Some of the additional features on the switches, like doing the span and the r span for this particular application,
|
|
0:17:10
|
But there's no debug you can do on the switches that will show the actual Layer 2 packet header.
|
|
0:17:15
|
There's another question here - to make this example work, did you say you would have to disable spanning tree on switch one and two?
|
|
0:17:21
|
Which spanning tree instance would you disable?
|
|
0:17:26
|
So if you did want to leak the traffic between VLANs,
|
|
0:17:31
|
on switch one,
|
|
0:17:34
|
you would have to disable spanning tree for VLAN ten
|
|
0:17:37
|
and on switch two you would have to disable it for VLAN twenty.
|
|
0:17:43
|
Or what you could do, you could run multiple spanning tree
|
|
0:17:48
|
and then put them in the same instance number
|
|
0:17:51
|
so that when they're receiving the BPDUs they actually would be part of the same spanning tree domain.
|
|
0:17:57
|
But the problem is in the first place, the native VLAN is not supposed to be mismatched.
|
|
0:18:03
|
As long as the native VLAN is the same on both ends of the link
|
|
0:18:07
|
you should not have the problem where traffic is going to leak between the segments.
|
