Changing Lives One Smile At A Time!

Trunking


Trunking Switches ( And the VLANs that love them )

Trunking  is the process of creating a logical connection between two physically connected switches, allowing frames to flow between them.

As you see, Switch 1 and 2  are connected with a cable (crossover cable)

A tag indicating the destination VLAN is placed into the frame by the transmitting switch . The receiving switch uses this frame tagging to see which VLAN should receive the frame.

This allows members in the same VLAN to communicate while physically attached to different switches. ( in real world networking, we’re going to have host on different switches being in the same VLANs.)

TRUNKING PROTOCOLS

We need a little help from a trunking protocol to build the trunk.  This is important stuff. Although not all Cisco switches support both of these protocols we will talk about.

1- ISL protocol (Inter-Switch Protocol)

  • Cisco-proprietary (it means that only Cisco Switches can use it)
  • Many Cisco switches don’t support ISL either.
  • Encapsulates the entire frame before sending it across the trunk, resulting in greater overhead than the other major trunking protocol, IEEE 802.1q (Encapsulation and De-Encapsulation would be extra work for the switches)
  • Does NOT recognize the concept of the native VLAN.

2- IEEE 802.1q ( “dot1q” )

  • The industry standard trunking protocol; can be used by non-Cisco and Cisco switches alike.
  • Does NOT encapsulate the frame.
  • Inserts a 4-byte value indicating the VLAN ID into the Ethernet header.
  • Recognizes the native VLAN concept.

NATIVE VLAN is simply the default VLAN, and we know that’s VLAN 1 by default on a Cisco switch. (The bad guys know that too.)

When Dot1q sees that a frame is destined for the native VLAN (recognizes the native VLAN and the two switches need to agree on what number the native VLAN is), it won’t even put that tiny 4-byte value into the Ethernet header. It’ll send the frame totally untagged. When the remote switch receives an untagged frame, it knows the frame is destined for the native VLAN, and the frame is forwarded to those ports belonging to that VLAN. ISL doesn’t know what a native VLAN is, and doesn’t care either;  it just encapsulate every single frame before sending it across the trunk whether to the native VLAN or not.

Let’s move our focus from the trunk to the ports at the ends of the trunk.

Access Ports, Trunk Ports, and Trunk Port Settings

When it comes to access ports and trunk ports, these terms are mutually exclusive.

A Cisco Switch port is going to be either an access port or a trunk port; it can’t be both.

Access ports belong to one and only one VLAN, and an access port can’t trunk. You can see the VLAN membership of all your access ports with “show vlan”  and “show vlan brief

You can see we’ve got a couple of empty VLANs there (20 and 30)  that we might be using later, and we’ve got four default VLANs there.

Right now, all of our ports are in VLAN1.

Trunk ports belong to all VLANs, and as you’d expect(that’s how they handle being a trunk), they can trunk.

We verify trunk ports with “show interface trunk”. Trunk ports will NOT appear in show vlan or show vlan brief .

In the above picture, you can see port 1 (Fa0/1) but you can’t see port 2 and 3 (we went from port 1 to port 4) !

Where did they go?!  They didn’t go anywhere as much as they’re trunking right now.

And there they are!

Let’s use IOS Help to display the port’s trunking options.

SW1(config-if)#switchport mode ?

The dot1q-tunnel and private-vlan options are for future study( which didn’t appear here), and the other three are definitely for your current studies.

The second one (dynamic) has some options you can’t see from here. So here is what we do:

So we have two modes of dynamic: Auto and Desirable (we saw “desirable” before as a mode for Fa0/2 and Fa0/3)

The three modes we’re concentrating on:

access makes the port an access port, which belongs to one and only one VLAN. In effect, this options turns trunking off.

trunk is the opposite of access; this option turns trunking on unconditionally.

dynamic negotiates trunking dynamically, and I realize that’s a Blinding Glimpse of the Obvious (BGO).

When you choose dynamic, you must specify whether the port will be in dynamic auto or dynamic desirable mode.

SW1(config-if)#switchport mode dynamic ?

auto  Set trunking mode dynamic negotiation parameter to AUTO

desirable Set trunking mode dynamic negotiation parameter to DESIRABLE

There’s a fifth option that doesn’t appear with the others:

SW1(config-if)#switchport negotiate

So we actually have five options for our trunk ports:

  • Unconditional trunking with switchport mode trunk
  • Unconditional non-trunking with switchport mode access
  • Active dynamic trunking with switchport mode dynamic desirable, which means the port is actively attempting to trunk. If the remote port is in on, desirable, or auto mode, a trunk will form.
  • Passive dynamic trunking with switchport mode dynamic auto. This means the port will trunk, but the other side has to initiate the process. If the remote port is in desirable or on mode, you’ve got a trunk. If both sides are in auto, no trunk will form as each end of the trunk is waiting for the other side to get this thing started.
  • The switchport nonegotiate option puts a port into permanent trunking mode, but Dynamic Trunking Protocol (DTP) frames are not sent across the trunk.

DTP is a negotiating protocol used to decide which trunking protocol to use (if both switches support both protocols) and whether trunking is to occur at all.

You may have created a trunk or two without knowing about the trunking protocols or the models! We have a trunk between these two switches inour lab right now, but I didn’t enter a single command to make it happen.

Filtering Traffic On A Per-VLAN Basis

We know trunk ports are members of every VLAN  on the switch. On occasion, that universal  VLAN  membership results in unnecessary forwarding of traffic, which in turn results in extra work for our switches and wasted bandwidth.

  • SW2 has no hosts in VLAN 30, so there’s no reason for SW1 to forward VLAN 30 traffic to SW2.
  • SW3 has no ports in VLAN 20,  so there’s no reason for SW1 to forward VLAN 20 traffic to SW3.

But by default, that’s exactly what’s going to happen.

We can deny traffic the ability to cross ( we can filter it before it goes across) the trunk on a per-VLAN basis with “switchport trunk allowed vlan”, followed by enough options to allow you to come up with any combination of permitted or denied VLANs.

So we want to prevent traffic from VLAN 30 for going from SW1 to SW2, and prevent VLAN 20 traffic from going from SW1 to SW3.

Let’s use the lab that we were looking at earlier.

As you notice, we don’t have the port numbers on that diagram. How can we get those?

We’ll go to SW1 (instead of 3)

It’s not really showing us who we’re trunking with.

Most likely in Lab environment, Fa0/2 is going to lead to SW2, and Fa0/3 is going to lead to SW3, but how can I absolutely verify that?

Now let’s get to the configuration at large.

First on port leading to SW2, I want to allow all my VLAN traffic now and in the future except for VLAN30.

Now we need to verify this. we can do that with show interface trunk

 As you can see, except the first field, the rest of them have changed. (Important for the exam!)

For example: in the 2nd field, on port 2, only 30 is not allowed on trunk and on port 3, only 20 is not allowed on trunk.

This is a great wat to cut down on unnecessary traffic. Because we’ve already filtered some traffic that was going out and didn’t need to go out and when it got there, it was going to be dropped anyway!

But you’ve got to watch the big picture with this kind of thing. Because if in the future, a couple of other switches get at it, then you might need to go back and do some work on it!

For example: Let’s assume that SW4 and SW5 just came online: ( If they have been there in the first place, we wouldn’t have done the filtering)

It’s true that SW2 doesn’t need VLAN30 traffic but SW4 does, and the only way to get from SW1 to SW4 with this topology is through SW2 ( the same goes for SW3 and SW1 and SW5)

So here we wouldn’t have done any filtering.

But let’s say SW4 and SW5 just came online and we have to take off that editing (that filtering we did)

We can use interface range command here because we’re going to put the same command on each interface:

So let’s get on config, and then show int trunk

You can see that we’re gone right back to where we were at the beginning.

Leave a Reply

Your email address will not be published. Required fields are marked *