|
0:00:14
|
In our first section for Ethernet switching, we're gonna talk about the core components that make up the Ethernet network,
|
|
0:00:20
|
which specifically are the virtual local area networks or the VLANs,
|
|
0:00:25
|
the VLAN trunks, possibly the VLAN Trunking Protocol of VTP,
|
|
0:00:31
|
and the Spanning Tree Protocol or STP.
|
|
0:00:34
|
Within the scope of the CCIE Routing and Switching Written exam,
|
|
0:00:37
|
you don't necessarily need to know all of the configuration details behind these technologies,
|
|
0:00:43
|
but you do need to understand the fundamental theory behind them.
|
|
0:00:47
|
Ideally, up to this point, a lot of these information is gonna be a review
|
|
0:00:50
|
from the CCNA or CCNP type level material that's related to Ethernet switching.
|
|
0:00:56
|
And then, as you get later into your preparation and our actually going into the implementation of this,
|
|
0:01:00
|
the details for that are gonna be covered in the CCIE Routing and Switching Advanced Technologies Class.
|
|
0:01:07
|
So, mainly in this section, we're gonna talk about the general theory of these four core Ethernet switching points.
|
|
0:01:12
|
And then, in later sections, we'll get into some more of the advanced functionality of Ethernet.
|
|
0:01:18
|
But the first of these, the VLANs or the virtual local area network
|
|
0:01:22
|
are used to separate the ports of the switch into different broadcast domains.
|
|
0:01:28
|
Whereas we know that with Ethernet, there is a two different modes of operation
|
|
0:01:32
|
we could run from a transmission point of view, where we can run in half-duplex or full-duplex mode,
|
|
0:01:38
|
where in half-duplex, it means that the ports are in the same collision domain,
|
|
0:01:43
|
and a full-duplex, it means that the ports are in separate collision domain.
|
|
0:01:47
|
However, who can actually send frames to each other is gonna be based on the broadcast domain.
|
|
0:01:53
|
So, hosts that are sharing the same VLAN number,
|
|
0:01:56
|
they're gonna be sharing the same broadcast domain.
|
|
0:01:58
|
This means that when the Layer 2 switches learn the Mac addresses in the network,
|
|
0:02:03
|
they're gonna create what's known as the Content Addressable Memory table or the CAM table,
|
|
0:02:09
|
or simply the Mac address table that is gonna maintain the Mac addresses for the particular VLAN.
|
|
0:02:15
|
This means that traffic that is inside the VLAN is gonna be using Layer 2 switching,
|
|
0:02:21
|
because those devices are in the same broadcast domain.
|
|
0:02:24
|
Any traffic that wants to move between the VLANs,
|
|
0:02:26
|
that's gonna have to go to an outside Layer 3 router,
|
|
0:02:30
|
or in the case of the switches, also running Layer 3 routing like with a switch virtual interface,
|
|
0:02:35
|
the switch itself could be doing the Layer 2 packet rewrite,
|
|
0:02:38
|
which is gonna change the Layer 2 header in order to move the frames between
|
|
0:02:42
|
the different broadcast domains, or between the different VLANs.
|
|
0:02:45
|
Now, the VLANs themselves can span between the multiple physical switches,
|
|
0:02:49
|
and this is gonna be the job of the second core portion of the Ethernet switching network,
|
|
0:02:54
|
which is the VLAN trunks, or simply the trunks.
|
|
0:02:57
|
Where the interconnections between the switches typically are gonna be our VLAN trunks,
|
|
0:03:02
|
which means that we're gonna be encoding multiple VLAN numbers
|
|
0:03:06
|
as the traffic is being sent between the devices.
|
|
0:03:10
|
Specifically, for these numbers, this is what is gonna define the VLAN membership.
|
|
0:03:15
|
Where the VLAN number itself is a 12-bit field,
|
|
0:03:18
|
which means that it has a numerical range of 0 to 4095,
|
|
0:03:23
|
but the first number and the last number are reserved,
|
|
0:03:27
|
or the 802.1Q standard, which defines not only the trunking encapsulation,
|
|
0:03:32
|
but also the specific format of the VLAN and how the Ethernet header is gonna look.
|
|
0:03:37
|
So, the first number is 0, the last one is 4095. Those are gonna be reserved.
|
|
0:03:42
|
This means that our assignable ranges are gonna fall into sub-ranges.
|
|
0:03:47
|
The first of which is the normal VLANs,
|
|
0:03:50
|
which are gonna be from 1 to 1005.
|
|
0:03:54
|
Where the first of these is 1 and default Ethernet VLAN.
|
|
0:03:57
|
The last four of these which are 1002 and 1004, then, 1003 and 1005.
|
|
0:04:05
|
These are gonna be for the legacy FDDI and token ring encapsulations.
|
|
0:04:11
|
So, typically, in our Ethernet networks, we're using VLAN 1 as the default,
|
|
0:04:15
|
we don't need to worry about VLAN 1000 to 1005.
|
|
0:04:19
|
But the numbers above this that go from 1006 up to the last assignable number, which is 4094,
|
|
0:04:25
|
this is what we consider our extended VLAN range.
|
|
0:04:29
|
Where these numbers are gonna be used for applications like private VLANs,
|
|
0:04:34
|
or any type of application that we want more VLAN numbers to be locally significant
|
|
0:04:40
|
and not to be advertised through our VLAN trunking protocol,
|
|
0:04:44
|
because with the extended VLANs,
|
|
0:04:46
|
that's what we'll talk about when we get to VTP,
|
|
0:04:49
|
this is only going to be assignable when we are running in VTP transparent mode.
|
|
0:04:55
|
Now, in some of the newer platforms that support that third version of VTP,
|
|
0:04:59
|
the VLAN Trunking Protocol version 3,
|
|
0:05:01
|
the extended VLAN numbers can be advertised between the switches,
|
|
0:05:05
|
but with most of the platforms that support just VTP version 1 and VTP version 2,
|
|
0:05:10
|
you can only advertise your normal VLAN ranges, which are again 1001,
|
|
0:05:15
|
or excuse me, 1 to 1005.
|
|
0:05:18
|
The ones above these, the 1006 to 4094, these ones are not gonna be advertised.
|
|
0:05:25
|
Now, it does necessarily mean though
|
|
0:05:27
|
that the broadcast domains are gonna be locally significant.
|
|
0:05:31
|
So, any devices that are sharing the same VLAN number,
|
|
0:05:34
|
and as long as we are sending traffic for that particular VLAN number,
|
|
0:05:38
|
like with a trunk, or with an access port between the switches,
|
|
0:05:44
|
then, it means that that particular VLAN number is gonna create an end-to-end broadcast domain.
|
|
0:05:50
|
Typically, the way that we would do this is with our VLAN trunks.
|
|
0:05:53
|
Where we want transport traffic for multiple VLANs at the same time over a single physical link
|
|
0:05:59
|
as opposed to dedicating one interface to VLAN 1 between the switches and another interface for VLAN 2, 3, 4, etc.
|
|
0:06:07
|
So, traffic that is going across these trunk links is gonna need an additional encapsulation.
|
|
0:06:12
|
What we consider out trunking encapsulation or simply our trunking,
|
|
0:06:16
|
because the normal Ethernet header, it doesn't have a field that is gonna specify what the VLAN number is.
|
|
0:06:23
|
This is where our either inter-switch link or 802.1Q encapsulations,
|
|
0:06:29
|
which are commonly referred to as ISL and .1Q,
|
|
0:06:33
|
that's what we're gonna using this for, to encode the VLAN number
|
|
0:06:37
|
as it is sent between the different devices.
|
|
0:06:41
|
The main differences between these two encapsulations
|
|
0:06:44
|
is that ISL is a Cisco proprietary implementation.
|
|
0:06:49
|
As compared to .1Q, it has a larger encapsulation overhead,
|
|
0:06:54
|
where it uses 30 bytes of encapsulation for all frames,
|
|
0:06:57
|
which is made up of two different sub-fields.
|
|
0:07:00
|
There's 26 bytes at the front or, 26 bytes for the header,
|
|
0:07:04
|
and then, 4 bytes for the new trailer, which is the frame check sequence or the FCS.
|
|
0:07:12
|
With ISL encapsulation, the switch will not be modifying the original frame as it is sent across the link,
|
|
0:07:18
|
because we have a new complete header and a new complete trailer.
|
|
0:07:22
|
Whereas with the 802.1Q standard, which is a IEEE standard,
|
|
0:07:27
|
we have a 4-byte value that is gonna be used for encoding the VLAN number or simply the VLAN tag,
|
|
0:07:35
|
and we will be modifying the original frame
|
|
0:07:37
|
because the tag value is inserted inside the existing Ethernet header,
|
|
0:07:43
|
which means that we have to regenerate the trailer, which is the frame check sequence.
|
|
0:07:49
|
For more specific info on this,
|
|
0:07:52
|
there's a good document on Cisco's website that is the Inter-Switch Link and IEEE 802.1Q Frame Formats,
|
|
0:07:59
|
which goes over the specifics of how the actual frames work.
|
|
0:08:05
|
So, at this point, we're not gonna get into the actual bit level details of what's the difference between ISL and .1Q,
|
|
0:08:11
|
but you can find that information here,
|
|
0:08:13
|
which again is under this document and the Inter-Switch Link and IEEE 802.1Q Frame Formats.
|
|
0:08:22
|
So again, the goal of these trunking encapsulations
|
|
0:08:25
|
is to get multiple VLANs to move between multiple different physical switches,
|
|
0:08:30
|
or multiple physical devices in the network.
|
|
0:08:34
|
Now, in order to do this, the Catalyst-IOS specifically supports
|
|
0:08:38
|
a couple difference of what we consider switchport modes.
|
|
0:08:42
|
Where a switchport on the Catalyst-IOS is a Layer 2 interface.
|
|
0:08:47
|
Layer 2 interface is gonna run either as an access switchport, a trunk switchport, a dynamic switchport,
|
|
0:08:55
|
which is then made up of two sub-modes,
|
|
0:08:58
|
the dynamic desirable and the dynamic auto.
|
|
0:09:00
|
Or we could run as an 802.1Q tunnel.
|
|
0:09:06
|
So, 5 different types here for these switchport, access trunk, dynamic desirable, dynamic auto, and tunnel.
|
|
0:09:13
|
For the access port and the trunk port,
|
|
0:09:16
|
these are fairly self-explanatory with the access port means that there's only one VLAN assigned,
|
|
0:09:22
|
a trunk port means that there's gonna be multiple VLANs assigned.
|
|
0:09:26
|
The dynamic modes, whether we're talking about dynamic desirable or dynamic auto
|
|
0:09:30
|
means that the switch is automatically going to choose this on its own.
|
|
0:09:34
|
Whether we should be running in access mode or whether we should be running in trunking mode.
|
|
0:09:40
|
And the way that is does this is through a protocol that is known as the Dynamic Trunking Protocol, or DTP.
|
|
0:09:47
|
What DTP is gonna allow us to do
|
|
0:09:49
|
is for the switch to figure out, should the link be an ISL trunk,
|
|
0:09:53
|
should it be an 802.1Q trunk,
|
|
0:09:56
|
or should it simply be an access port.
|
|
0:09:59
|
The result of this is gonna be dependent on whether both devices
|
|
0:10:04
|
are running the dynamic trunking protocol on what their specific configuration is.
|
|
0:10:09
|
Where to configure the port as a dynamic port,
|
|
0:10:12
|
it would be either the switchport mode dynamic auto, or the switchport mode dynamic desirable at the interface level,
|
|
0:10:18
|
and you would see that different versions of Catalyst-IOS,
|
|
0:10:22
|
and different Catalyst-IOS platforms will have different defaults for this.
|
|
0:10:27
|
In either case, if you were to look at the output of the Show Interface Switchport,
|
|
0:10:31
|
that's gonna show you the specifics as to what the administrative mode is.
|
|
0:10:36
|
Or essentially, what is the interface configured as,
|
|
0:10:39
|
is it dynamic auto or dynamic desirable?
|
|
0:10:42
|
To disable the dynamic trunking protocol or DTP,
|
|
0:10:46
|
we can either issue the Switchport No Negotiate,
|
|
0:10:49
|
or the Switchport Mode Access command.
|
|
0:10:53
|
Where if the interface is running as an access port and only has one VLAN assignment,
|
|
0:10:57
|
which means that it should never negotiate as a trunk.
|
|
0:11:01
|
There can be certain cases where you want to run trunking though,
|
|
0:11:04
|
but you don't wanna run dynamic trunking protocol.
|
|
0:11:07
|
This is where you would set the mode of the interface to be trunk
|
|
0:11:10
|
along with the Switchport No Negotiate command.
|
|
0:11:14
|
The key point for this with the dynamic modes and the dynamic trunking protocol
|
|
0:11:19
|
is that you need to make sure that both switches or both devices
|
|
0:11:24
|
agree on whether the trunk link will or will not be formed,
|
|
0:11:28
|
and if it is gonna be formed, we need to make sure that we have the different compatible modes.
|
|
0:11:34
|
Where if we were to have two switches, switch 1 trying to configure a trunk to switch 2,
|
|
0:11:41
|
there's a couple different operational modes that we could have
|
|
0:11:43
|
that are gonna successfully result in a trunk link.
|
|
0:11:47
|
If switch 1 were to say that the switchport mode
|
|
0:11:55
|
is on,
|
|
0:11:57
|
if switch 2 agrees on this with the on mode, with the dynamic desirable mode,
|
|
0:12:06
|
or with the dynamic auto mode,
|
|
0:12:10
|
then, we will be able to form a trunk link.
|
|
0:12:15
|
This is assuming that switch 1 has not disabled DTP with the Switchport No Negotiate command.
|
|
0:12:22
|
So, if we have all the defaults on the interface,
|
|
0:12:24
|
one of the switches says that the switchport mode is trunk,
|
|
0:12:26
|
the other side says that switchport mode is trunk,
|
|
0:12:29
|
the switchport mode is dynamic desirable or dynamic auto,
|
|
0:12:33
|
then, we're gonna be able to run this in trunking mode.
|
|
0:12:36
|
Now, where the problem comes in is that if one side has disabled DTP,
|
|
0:12:42
|
so, if switch 1 were to say, the commands Switchport No Negotiate,
|
|
0:12:53
|
it means that on the other side, we can only have on.
|
|
0:12:57
|
The dynamic desirable and the dynamic auto modes would not work
|
|
0:13:00
|
because the switches are then not configured to negotiate the mode of the interface,
|
|
0:13:05
|
and also to negotiate the encapsulation.
|
|
0:13:08
|
Where DTP is gonna prefer to negotiate ISL encapsulation first.
|
|
0:13:13
|
If ISL encapsulation fails, then, it's gonna fall back to 802.1Q.
|
|
0:13:18
|
If that fails, then, it's gonna fall back to an access port.
|
|
0:13:24
|
So again, the key is that we need to make sure that the two devices agree on what the port mode is gonna be.
|
|
0:13:30
|
One side says it's on, the other can say it's on, it's either dynamic desirable or dynamic auto
|
|
0:13:36
|
as long as the dynamic trunking protocol is on.
|
|
0:13:41
|
In this case, where Switchport No Negotiate were turning the dynamic trunking protocol off,
|
|
0:13:46
|
so both sides would have to agree that the link is on, or the trunk is on.
|
|
0:13:52
|
If we were to completely try to dynamically negotiate this,
|
|
0:13:56
|
if one side is dynamic auto, the other side would have to be dynamic desirable.
|
|
0:14:05
|
Essentially, the difference between them is that the dynamic auto mode is only going to listen for the negotiation.
|
|
0:14:12
|
It's not going to initiate the negotiation.
|
|
0:14:14
|
Where dynamic desirable says that you're gonna do both.
|
|
0:14:17
|
You're gonna start the negotiation and you're gonna listen for it.
|
|
0:14:20
|
So, both auto and desirable would work and desirable and desirable,
|
|
0:14:27
|
but not auto and auto,
|
|
0:14:30
|
because this means then that neither of the devices are starting the trunking negotiation.
|
|
0:14:37
|
Regardless of how we have this configured, we can always verify this with the Show Interface Trunk Output,
|
|
0:14:42
|
and also with the Show Interface Switchport.
|
|
0:14:45
|
Where Show Interface Switchport is gonna show all of the details behind the Layer 2 configuration.
|
|
0:14:49
|
Show Interface Trunk is gonna show just whether the interface is probably running in trunking mode.
|
|
0:14:58
|
Now, once the trunks a properly up between the devices,
|
|
0:15:01
|
then, we need to make sure that all of them agree on what are the same VLAN numbers.
|
|
0:15:05
|
Because ultimately, the VLAN numbers are going to define what are the broadcast domains.
|
|
0:15:12
|
One of the potential issues with this is that once the size of the Layer 2 network starts to grow,
|
|
0:15:17
|
meaning, physically, we have lots of switches in the network that we're trying to maintain.
|
|
0:15:21
|
It gets difficult from an administration point of view,
|
|
0:15:24
|
how do we actually maintain these VLAN numbers
|
|
0:15:27
|
and make sure that they agree between the switches that we want to use the same broadcast domains on.
|
|
0:15:32
|
So, this is where our next portion of switching comes in, the VLAN trunking protocol, or VTP.
|
|
0:15:38
|
Where VTP is used just to solve the administration problem
|
|
0:15:42
|
that we wanna make sure that the switches agree on the same VLAN numbers.
|
|
0:15:47
|
So, technically, VTP does not define the broadcast domains.
|
|
0:15:51
|
It's used just to make sure that switches agree on what are the VLAN numbers.
|
|
0:15:55
|
The actual broadcast domains are defined by the port assignments,
|
|
0:15:59
|
where we would say Switchport Access VLAN command at the actual interface level.
|
|
0:16:06
|
So, specifically, with VTP, it is a Cisco proprietary protocol,
|
|
0:16:10
|
where sometimes, it's called the VLAN Trunk Protocol or the VLAN Trunking Protocol,
|
|
0:16:16
|
but the idea behind this is that we're gonna use it to dynamically advertise what are the properties of the VLANs.
|
|
0:16:21
|
So, what are the VLAN numbers, what are the VLAN names, what are the VLAN MTUs,
|
|
0:16:27
|
a couple of other attributes that you can advertise there.
|
|
0:16:30
|
And we could also use it to negotiate which particular VLANs should actually be forwarded between the switches.
|
|
0:16:37
|
Which is a feature known as VTP Pruning.
|
|
0:16:43
|
Now again, the key with VTP is that it's not used to affect the actual VLAN assignments.
|
|
0:16:50
|
So, VTP does not define the broadcast domains.
|
|
0:16:53
|
We still need to do this manually at the interface level with the Switchport Access VLAN command.
|
|
0:16:58
|
The way that VTP works is first gonna be based on what we define as the VTP domain, or the domain name.
|
|
0:17:06
|
Where switches that are sharing the same VTP domain name
|
|
0:17:10
|
are gonna be sharing the same copy of the VLAN database, or the VTP database.
|
|
0:17:16
|
Inside this domain, we're then gonna have different type of VTP modes for the devices.
|
|
0:17:22
|
This is ultimately gonna control who can advertise new information,
|
|
0:17:26
|
and who can change previously added information.
|
|
0:17:29
|
Like who can create a new VLAN, who can delete a VLAN, who can change its attributes.
|
|
0:17:34
|
Where the modes are gonna be three different possible values.
|
|
0:17:37
|
VTP server, VTP client, or VTP transparent.
|
|
0:17:43
|
Additionally, we have a key advertisement property of the VLAN Trunking Protocol which is known as the revision number.
|
|
0:17:50
|
The revision number is basically gonna be the sequence number for the VTP database or for the VLAN database.
|
|
0:17:57
|
Where whatever device has the highest revision number,
|
|
0:18:00
|
it indicates that it has the most updated copy of the database.
|
|
0:18:08
|
Now, the VTP domain, again is gonna control which devices is going to accept each other's advertisements.
|
|
0:18:14
|
So, if two switches are in the same domain,
|
|
0:18:16
|
they ideally should have the same copy of the VLAN numbers and their attributes, like the names.
|
|
0:18:22
|
Although, the VTP domain again, it doesn't define the broadcast domains.
|
|
0:18:26
|
You can have certain designs where switches are in different VTP domains,
|
|
0:18:32
|
but if they're sharing the same VLAN number,
|
|
0:18:34
|
that VLAN would still be part of the same broadcast domain.
|
|
0:18:38
|
Because again, VTP is used just for the administration.
|
|
0:18:41
|
It doesn't have to do with the actual CAM table or the Mac address table of the switches.
|
|
0:18:46
|
Ultimately, the Mac address table is gonna define what is the broadcast domain
|
|
0:18:50
|
or where can I send my Layer 2 frames?
|
|
0:18:54
|
Configuration of this portion, the VTP domain is simply gonna be the VTP Domain command,
|
|
0:19:01
|
where the switches normally are gonna start with a null value of this,
|
|
0:19:05
|
or simply no value for the VTP domain.
|
|
0:19:09
|
You would also see that the switch is going to inherit or learn
|
|
0:19:13
|
whatever the domain name is of the first advertisement it hears.
|
|
0:19:18
|
This means that if we were to have two switches, where neither of them have VTP configured,
|
|
0:19:23
|
On the first switch, if I were to say, VTP Domain A,
|
|
0:19:28
|
the other switch that I did not configure this on is automatically gonna learn that this VTP domain should be A.
|
|
0:19:35
|
Now, again, inside the domain, we have three different modes, the first of which is gonna be the server mode.
|
|
0:19:41
|
This is what all of the switches will run as by default.
|
|
0:19:45
|
This is gonna allow them to make additions to the VLAN database to delete information, to modify it,
|
|
0:19:51
|
basically to add VLANs or to change their names or change the other attributes.
|
|
0:19:57
|
Any changes that are made on the server are automatically going to over write the rest of the network
|
|
0:20:03
|
assuming that that server has the highest VTP revision number.
|
|
0:20:08
|
Where again, the highest revision number is gonna be the most updated copy of the database.
|
|
0:20:12
|
So, whoever has this highest number is gonna be override all of the other switches.
|
|
0:20:18
|
To set the switch as the server, this would be the VTP Mode Server Command.
|
|
0:20:23
|
Whereas the second mode, the VTP client
|
|
0:20:27
|
is not gonna be able to add information or to modify any information.
|
|
0:20:32
|
It's still gonna be listening for advertisements that are coming from the servers.
|
|
0:20:36
|
It's gonna use this information locally, it's gonna continue to pass it on,
|
|
0:20:40
|
but it's not gonna make any changes.
|
|
0:20:42
|
This would be configured with the VTP Mode Client command.
|
|
0:20:48
|
Now, the one potential issue that can come in to a VTP convergence,
|
|
0:20:52
|
where the switches are trying to agree on the same copy of the VLAN database
|
|
0:20:56
|
is that you have certain cases where this is a client that has a higher revision number than the servers.
|
|
0:21:05
|
The client's information can actually override the severs, or overwrite the servers.
|
|
0:21:10
|
Because we're not making changes to the network, but we're continuing to advertise these updates on.
|
|
0:21:15
|
So, regardless of whether you're a server or a client, whoever has the highest revision number
|
|
0:21:20
|
is gonna be advertising that out and then that's what everyone else is going to be installed.
|
|
0:21:26
|
The only time that this does not happen is when you are running in VTP transparent mode,
|
|
0:21:33
|
which essentially means that your VLAN database or your VTP database
|
|
0:21:37
|
is gonna be separate from the rest of the domain or from the rest of the topology.
|
|
0:21:49
|
The key difference between a VTP transparent mode switch versus the client or the server
|
|
0:21:55
|
is that it's not going to originate any advertisements.
|
|
0:21:59
|
This means that changes that you make on a transparent mode switch
|
|
0:22:02
|
are not gonna affect the rest of the network.
|
|
0:22:06
|
What it will still do though is receive updates from other client's or servers,
|
|
0:22:10
|
and then continue to pass them on.
|
|
0:22:14
|
Whereas the name implies, this is going to be transparently sent in the updates.
|
|
0:22:18
|
But if it receives it in, it continues to advertise it out, but it's not making any changes.
|
|
0:22:23
|
There are certain features in the Catalyst-IOS that would require you to run transparent mode.
|
|
0:22:29
|
Like I mentioned before, one of them is the private VLAN feature.
|
|
0:22:34
|
Where for the switches that do not support VTP version 3,
|
|
0:22:38
|
which means that cannot advertise extended VLAN numbers.
|
|
0:22:42
|
Anytime that you are using a feature which needs, or if you are configuring extended VLAN numbers,
|
|
0:22:47
|
normally means you're gonna be in VTP transparent mode.
|
|
0:22:51
|
Which is then configured with the VTP mode transparent.
|
|
0:22:58
|
Some of the other key features for the VLAN trunking protocol would be its security
|
|
0:23:03
|
that you would generally wanna make sure that someone
|
|
0:23:06
|
who is not authorized to be a portion of your network, your Layer 2 topology cannot add or remove VLANs.
|
|
0:23:14
|
So, to do this, the most basic security of VTP is just gonna be to use MD-5 based authentication.
|
|
0:23:21
|
It means that anyone who doesn't have that correct password
|
|
0:23:25
|
is not gonna be able to add VLANs, they're not gonna be able to delete or to change the VLANs.
|
|
0:23:31
|
However, this security with the password technically doesn't prevent against a misconfiguration.
|
|
0:23:38
|
Which as I mentioned before, could be related to a device having a higher VTP revision number.
|
|
0:23:45
|
Where if a switch is being configured in some other network, or maybe in a test lab,
|
|
0:23:51
|
it joins the network with a higher revision number.
|
|
0:23:54
|
It can actually overwrite the rest of the network with the wrong information or with no information.
|
|
0:24:01
|
Basically meaning, it could delete all of the VLAN numbers from the topology.
|
|
0:24:06
|
So, you wanna make sure that your current servers have always the highest revision number,
|
|
0:24:10
|
then, as you're adding new switches to the network,
|
|
0:24:13
|
when you look at the Show VTP Status, you wanna make sure that they're revision number is less
|
|
0:24:18
|
than what the current network is.
|
|
0:24:22
|
One way that you could quickly solve this is to change the switch from
|
|
0:24:25
|
either client or server to transparent mode and then back,
|
|
0:24:30
|
that would reset the revision number to 1.
|
|
0:24:36
|
The other key feature with VTP is what is known as VTP Pruning.
|
|
0:24:42
|
Where VTP Pruning is gonna allow the switches to automatically advertise to each other
|
|
0:24:46
|
what VLAN numbers are they actually assigning,
|
|
0:24:49
|
and ultimately figure out which VLAN should be forwarded over their trunk links.
|
|
0:24:56
|
The reason that you would want to do this
|
|
0:24:57
|
is that normally, the switches are gonna send broadcasts or unknown frames,
|
|
0:25:03
|
which means, "I don't know where the destination is either for a unicast or a multicast frame."
|
|
0:25:08
|
Those are gonna be flooded throughout the entire network.
|
|
0:25:12
|
Which means that the frame is gonna be sent out every port
|
|
0:25:15
|
except the one that it came in on that is in the same VLAN, which is going to include the trunk links.
|
|
0:25:24
|
Now, there is another way that you can do this manually be changing the allowed list on a trunk interface,
|
|
0:25:31
|
but the problem is that this is generally administratively prohibited
|
|
0:25:36
|
that to maintain manual trunk allowed list,
|
|
0:25:39
|
it's gonna take a lot more administrations, it's gonna take a lot more documentation of the network.
|
|
0:25:44
|
It also means that changing things in the network is gonna be more difficult.
|
|
0:25:48
|
There's more commands that you have to enter on all of the devices.
|
|
0:25:52
|
So, VTP Pruning is trying to automate this procedure,
|
|
0:25:55
|
where essentially, the switches advertise what VLANs that they have assigned,
|
|
0:25:59
|
and which VLANs they want to receive.
|
|
0:26:02
|
For any numbers that aren't needed, those are gonna be removed or essentially pruned off of the links.
|
|
0:26:10
|
The only other requirement for this though is that it doesn't work in transparent mode.
|
|
0:26:15
|
Since the switches are gonna be advertising to each other,
|
|
0:26:17
|
what VLAN numbers they are using,
|
|
0:26:20
|
it means they have to have the same copy of the VLAN database everywhere.
|
|
0:26:25
|
Where in the case of VTP transparent, this is not the same copy.
|
|
0:26:28
|
It's a separate independent copy of the rest of the database.
|
|
0:26:33
|
So, to configure this VTP Pruning feature just on one of the servers of the network, you would enable the feature.
|
|
0:26:38
|
And it's automatically gonna be advertised as part of the VTP updates
|
|
0:26:42
|
out to trunk links to either of the other clients or to the other servers.
|
