Tag Archives: VLANs

JUNOS routed interfaces

Quick one today and a memory refresh for myself. Routed L3 links between a SRX and an EX2200-C. I have currently two up links connected between the two. I want to advertise a L3 VLAN across to the SRX. I want the interconnect to be two L3 point to point link. First lets create the routed point to point links. The SRX first.

set interfaces fe-0/0/4 unit 0 family inet address 172.16.1.1/30
set interfaces fe-0/0/5 unit 0 family inet address 172.16.1.5/30

Now time for the EX.

set interfaces ge-0/1/1 unit 0 family inet address 172.16.1.6/30
set interfaces ge-0/1/0 unit 0 family inet address 172.16.1.2/30

With the links up we will create a vlan with a layer three interface on the EX switch. Put an interface with an active interface into the VLAN.

set interfaces vlan unit 15 description "ENGINEERING L3 INT"
set interfaces vlan unit 15 family inet address 10.0.15.1/24

set vlans ENGINEERING description "Engineering Department"
set vlans ENGINEERING vlan-id 15
set vlans ENGINEERING l3-interface vlan.15

set interfaces ge-0/0/10 unit 0 family ethernet-switching vlan members ENGINEERING

Juniper doesn’t have the equivalent of the Cisco auto-state ignore feature. This removes the pre-requisite of an active port in the VLAN for SVI up status. Now, with my Advanced Features licence, I can run OSPF on my EX. The following commands will advertise the required interfaces into OSPF.

set protocols ospf area 0.0.0.0 interface ge-0/1/0.0
set protocols ospf area 0.0.0.0 interface ge-0/1/1.0
set protocols ospf area 0.0.0.0 interface vlan.15

Then put the following configuration onto the SRX to advertise the required networks to the EX.

set protocols ospf area 0.0.0.0 interface fe-0/0/4.0
set protocols ospf area 0.0.0.0 interface fe-0/0/5.0
set protocols ospf area 0.0.0.0 interface vlan.0
set protocols ospf area 0.0.0.0 interface vlan.20

Now let us check the OSPF status to confirm a relationship and a L3 routed interface.

root@AU-MEL-DMZFW-01> show route 10.0.15 

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.15.0/24       *[OSPF/10] 00:01:28, metric 2
                      to 172.16.1.2 via fe-0/0/4.0
                    > to 172.16.1.6 via fe-0/0/5.0

root@AU-MEL-DMZFW-01> show ospf interface 
Interface           State   Area            DR ID           BDR ID          Nbrs
fe-0/0/4.0          BDR     0.0.0.0         10.0.15.1       1.1.1.1            1
fe-0/0/5.0          BDR     0.0.0.0         10.0.15.1       1.1.1.1            1

Awesome. Note that you can access the 10.0.15.0/24 network via two routed interfaces. The > denotes that it is the selected route. You have achieved two cool things in this lab. A routed interface and advertised a VLAN Layer 3 interface.

Disclaimer

I do have a disclaimer about my blog and how I operate in the blogging world with integrity. I do declare here and with other posts that this Juniper Networks EX2200-12P switch was provided to me by Francois Prowse, on behalf of Juniper Networks. I was not asked for positive, marketed, vendor drivel. I will blog honestly about the platform and my experiences and share what I find, good or bad.

Understanding switch constructs

Virtual networking isn’t a new thing. It has been around for a while and we get better at it as the months pass us by. Who hasn’t heard of SDN? Well before I buy into that realm and blog about it, lets harken back to a device which most people have had to deal with. VMware hosts attach themselves to most networks. VMWare provide a number of networking methods to provide intra-guest and inter-host communication. This communication from the physical card to the VM kernel and into a guest VM is very interesting. This blog will explore what a vSwitch can provide.

By default a new ESXi host will have the vSwitch0 installed by default. The first physical NIC will have a virtual adapter or vmnic0 assigned in the switch construct. This vmnic is presented through the VMware Hypervisor and presented to the construct. Upon installation you will assign a management IP. This is marked as a vmkernel port in which a various array of traffic types can pass. The first point of call for most is connection into the host with the VMware vSphere client.

It is important to note that although the behaviour of the vSwitch is designed to replicate that of a physical there are quite a few differences that need to be appreciated.

  • MAC address learning
    • The vSwitch is authoritative regarding this. It pulls the MAC address assigned to the NIC presented to the guest VM from the configuration file.
    • No learning is required in the traditional sense – record/store/forward
  • Zero participation in Spanning-Tree
    • Blocks inbound BPDUs
    • It uses, for a lack of a better term,  Split Horizon Switching
      • Packets received on one uplink cannot be passed and forwarded out another.
      • This is how it avoids creating network loops and a potential ‘Resume generating transaction’
  • Port-Groups are like ‘VLANs without the tagging’.
    • Guests are bound to port groups and different actions can take place.
    • Port-groups reside inside a vSwitch and can have different forwarding options applied.
  • Dynamic port allocation
    • Supports up to 4096 ports.
    • Subtract 8 for internal communications and forwarding leaving a total of 4088.
    • Supports up to 40Gb forwarding per vSwitch.
    • This doesn’t scale unlike Distributed vSwitch.
  • Additional to SPAN in 5.1
    • Support for RSPAN and ERSPAN
    • True IDP support
  • LACP support
    • Provides hosts bundled connectivity which can aid in HA mechanisms host and physical switch side.

My initial thoughts about the vSwitch are positive. The notion of dumb switch is tired. The spec sheet and throughput in software leveraging server backplane is impressive. There is a lot to be desired about the scalability options which saw the introduction of the distributed vSwitch. I find that it is rather a scary notion the simplicity in which someone can install this. This gives administrators without a strong networking background the ability to create sub-optimal situations for virtual networking environments. Although it houses a simple interface and point and click connectivity the VMware vSwitch requires thought and planning to ensure stable and high throughput operations.

VLANs and more

As I slowly diversify my skill set and acquire JUNOS knowledge I find that knowing the technology and underlying concepts are the same. Minor changes like routing preference and the like is easy to deal with. Slowly I am working through building a home network with a SRX110 as my main device. I have an Opengear ACM5504-G-E console server which I decided needed its own subnet and VLAN. I wanted to its own DHCP scope and the interface to reside in another VLAN. Today I will show you how to do this task.

My test network

Define the VLAN

First we make the VLANs and issue the following set commands from configuration mode.

set vlans Servers vlan-id 2
set vlans OOB-access vlan-id 100

Create SVI

Now we create the L3 interface that will form out default gateway for devices which reside in the different VLANs we create.

set interfaces vlan unit 2 family inet address 192.168.2.1/24
set interfaces vlan unit 100 family inet address 192.168.100.1/24

Apply interface to VLAN

Now we assign the required interfaces to each respect VLAN. Interface fe-0/0/7.0 is going into my OOB-access VLAN and my server is going onto fe-0/0/2.0 .

set interfaces fe-0/0/2 unit 0 family ethernet-switching vlan members Servers
set interfaces fe-0/0/7 unit 0 family ethernet-switching vlan members OOB-access

Create DHCP scope

Now for the moment I want to provide DHCP scopes for this VLAN. If this were a real deployment I would suggest using a dedicated DHCP server.

set system services dhcp pool 192.168.2.0/24 address-range low 192.168.2.10
set system services dhcp pool 192.168.2.0/24 address-range high 192.168.2.254
set system services dhcp pool 192.168.2.0/24 router 192.168.2.1
set system services dhcp pool 192.168.2.0/24 domain-name servers.ciscoinferno.net
set system services dhcp pool 192.168.100.0/24 address-range low 192.168.100.100
set system services dhcp pool 192.168.100.0/24 address-range high 192.168.100.254
set system services dhcp pool 192.168.100.0/24 domain-name oob.ciscoinferno.net
set system services dhcp pool 192.168.100.0/24 router 192.168.100.1

Apply to correct security zone

Now we need to add each VLAN to the required security zone. For now I am just going to use the built int trust zone as I will explore zones further into my JNCIS-SEC studies.

set security zones security-zone trust interfaces fe-0/0/2.0
set security zones security-zone trust interfaces vlan.2
set security zones security-zone trust interfaces vlan.100
set security zones security-zone trust interfaces fe-0/0/7.0

Here is some verification to make sure the magic is happening

root@SRX110> show vlans                             
Name           Tag     Interfaces
Servers        100    
                       fe-0/0/2.0, fe-0/0/7.0*
default        1      
                       None
vlan-trust     2      
                       fe-0/0/1.0*, fe-0/0/3.0, fe-0/0/4.0, fe-0/0/5.0,
                       fe-0/0/6.0

root@SRX110> show system services dhcp binding 
IP address       Hardware address   Type     Lease expires at
192.168.100.101  00:13:c6:00:a2:bb  dynamic  2012-12-06 17:57:51 EST
192.168.2.10     00:16:cb:8d:06:b5  dynamic  2012-12-06 15:57:12 EST

root@SRX110> show security zones trust     

Security zone: trust
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes  
  Interfaces bound: 5
  Interfaces:
    fe-0/0/1.0
    fe-0/0/2.0
    fe-0/0/7.0
    vlan.100
    vlan.2

vlan                    up    up  
vlan.2                  up    up   inet     192.168.2.1/24  
vlan.100                up    up   inet     192.168.100.1/24

Enjoy. Go forth my minions and configure those VLANs.

The importance of skinning cats

Once again the VLAN topic comes to the forefront but immediately I know this will apply to all aspects of the blueprint. The old adage goes something like “There are many ways to skin a cat”.

Lets take the example of creating a VLANs. How many ways can you do it? Well I know of three. I will give an example of each below to show my point.

First Method – VLAN Database

S1#vlan database
% Warning: It is recommended to configure VLAN from config mode,
 as VLAN database mode is being deprecated. Please consult user
 documentation for configuring VTP/VLAN in config mode.
S1(vlan)#vlan 100 name CCIE-vlan100
VLAN 100 added:
 Name: CCIE-vlan100

Note here that we have added a VLAN into the VLAN Database. Remember that you can only have VLANs that are in the standard range which consists of 1-1004. Note also that this method is being deprecated but at time of writing still relevant.

Second Method – Global Configuration

S1(config)#vlan 150
S1(config-vlan)#name CCIE-vlan150

This method is quite easy in comparison. This method is what has replaced directly interacting with vlan.dat via the VLAN database. This is the method that most students are taught when getting their CCNA studies under their belt.

Third Method – Interface creation

S1(config)#int fa0/10
S1(config-if)#switchport access vlan 200
% Access VLAN does not exist. Creating vlan 200

Note here that we have created a VLAN inadvertently by placing an interface into a VLAN which has not been defined. This creates the VLAN in the database. This only applies to standard range VLANs and does not work on all devices.

If you have read my previous article discussing the difference between standard and extended range VLANs you will have more clarity in regards to the following error.

S1(config-if)#switchport access vlan 3500
% Access VLAN does not exist. Creating vlan 3500
S1(config-if)#
00:08:28: %PM-2-VLAN_ADD: Failed to add VLAN 3500 - VTP error.

This error will rear its head due to the fact that the switch cannot write an extended VLAN to the vlan.dat database. The VTP mode which allows extended VLANs to be utilized and written to the running config is transparent mode. VTPv3 does alleviate issues posed here but at this current time is outside the bounds and scope of the CCIE blueprint.

This entry was designed not as a guide to skinning our feline kitties. It’s purpose is to understand that a task may require a different way of execution. I know for a fact restrictions on the CCIE exam make some simple tasks a little trickier. It even takes trickier tasks to the extreme.

By understanding different methods such as those listed above you may avoid some obstacles. If a task stated

  • VLANs 500,1000,2000 must be created. VLAN information must be added to the running configuration concurrently.

You would have to weigh up what method and mode best suits the requirements of the question.

Fundamental understanding of technologies and their applications are important. Playing at the CLI also will reveal what the cause and effect of each word you type. The CCIE awaits me and I best get back to study.

Extended VLANs: Don’t get caught out.

Now VLANs may seem simple but you need to understand every facet when working towards the CCIE.

The VLAN database can only store 1-1004 VLAN within it due to it only seeing 10 bits within the VLAN ID field. This had come from the days of ISL trunking. Due to 802.1q using 12 bits in the VLAN ID field it can happily support up to 4096 combinations of VLANs.

The following terms will give scope to the previous paragraph.

Normal-range VLAN
A vlan which is made up using the first 10 bits of the VLAN ID header.

Extended-range VLAN
A vlan which utilizes the extra bits within the VLAN ID field as defined in 802.1q.

Now that a little background has been given. Lets see what Extended-range actually means and what you should be aware of. When configuring VLANS and VTP it is important to remember where they are stored and why. IOS can put this configuration in one of two possible places – either in the Flash Memory ( VLAN.DAT anyone?) or appends it to the running configuration.

The VLAN range and VTP mode directly affect and interact the way this occurs.

VLAN range type

VTP server

VTP transparent

Standard

VLAN Database

VLAN Database/Running Configuration *

Extended

Not Configurable

Running Configuration

*Ensure VTP domain names are in sync between VLAN.dat and start-up configuration as VLAN.dat takes precedence.

As you can see from the table above it is important to understand what you are configuring. Normal range VLANs in VTP Server mode write information as per usual to the vlan database. Within transparent mode it also writes to the running configuration.

On the other hand with extended VLAN range you cannot even write an extended vlan to the database – Check our the funky error below.

S1(config)#vlan 3000
S1(config-vlan)#exit
% Failed to create VLANs 3000
Extended VLAN(s) not allowed in current VTP mode.
%Failed to commit extended VLAN(s) changes.
S1(config)#
02:15:15: %SW_VLAN-4-VLAN_CREATE_FAIL: Failed to create VLANs 3000: extended VLAN(s) not allowed in current VTP mode

Only when I changed VTP mode to transparent and tried to execute the command again was I met with success.

S1(config)#vtp mode trans
Setting device to VTP TRANSPARENT mode.
S1(config)#vlan 3000
S1(config-vlan)#name ciscoinferno-3000

I went to clarify the vlan – first in the VLAN database.

S1#vlan database
% Warning: It is recommended to configure VLAN from config mode,
 as VLAN database mode is being deprecated. Please consult user
 documentation for configuring VTP/VLAN in config mode.
S1(vlan)#sh current ? 
 <1-1005> ID number of the VLAN shown

Well that didn’t work. As listed above – the maximum standard VLAN range is all that is allowed. Let me try the old-fashioned way.

SW1#sh vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active 
21 VLAN0021 active 
1002 fddi-default act/unsup 
1003 token-ring-default act/unsup 
1004 fddinet-default act/unsup 
1005 trnet-default act/unsup 
3000 ciscoinferno-3000 active

Now to confirm that it has appended itself to the running config.

S1#sh run | beg vlan
vlan internal allocation policy ascending
!
vlan 21 
!
vlan 3000
 name ciscoinferno-3000

Look at that. It is in the configuration. Now if you were attempting something crazy like trying to revert back to VTP server mode you’re out of luck.

S1(config)#vtp mode server
Device mode cannot be VTP SERVER because extended VLAN(s) exist

Being met with this error? Stop being silly and understand the facts.
What I have gained?

I have learnt a lot from my little VLAN database dive. The importance of understanding why this something is designed that way in the first place. Generally due to addressing one problem or another. This leads to clarity when reading built-on technologies and discovering their origins.

The exercise that I wanted to share with you today is that it is worth diving into tasks and technologies. It is important to understand information such as the caveats discussed in this blog. It may just save you time when rolling out changes, troubleshooting L2 connectivity issues, or even designing a enterprise wide template.

Multiple Tenant, Same Switch – Private VLANs

A private VLAN allows conservation of IP and VLANs via L2 separation within a VLAN. It allows web hosts and ISPs to segregate or group devices whilst conserving IP addressing.  PVLANs restrict communication between ports and allow communication with promiscuous  port. Think VLAN inside a VLAN!

Primary PVLAN

  • Primary PVLAN can be composed of many secondary PVLANs. The secondary PVLANs belong to the same subnet as the Primary PVLAN. The primary VLAN has the task of also carrying data from the promiscuous port to the isolated, community, and other promiscuous ports in the same primary PVLAN.

Secondary PVLAN

  • A child PVLAN to the primary PVLAN, a secondary PVLAN is mapped to a single primary PLVAN. Secondary PVLAN are what hosts attach to.

Types of Secondary PVLANs

  • Community PVLANS
    • Ports can communicate with other community members and the promiscuous port of the primary PVLAN
  • Isolated Private VLAN
    • Ports can only communicate with the promiscuous ports only.

NOTE: Promiscuous ports only service and work with one primary PVLAN. A promiscuous port can service  one isolated PVLAN or many community PVLANs

PVLAN Port types

  • Isolated
    • Isolated ports are completely separated at L2 from any other ports except those listed as promiscuous. These ports block all traffic to other isolated ports. Traffic is forward to promiscuous ports only
      • Servers, Hosts (Think web-hosting!)
  • Promiscuous
    • These ports communicated with all ports within a PVLAN including community and isolated ports. Promiscuous ports are apart of one primary PVLAN and each promiscuous port can map themselves to multiple secondary PVLANS.
      • Routers, Shared Servers, SVIs, Routed Switch ports
  • Community
    • These ports communicate amongst themselves and their promiscuous ports. L2 communities are isolated from other communities and isolated ports within their PVLAN.
      • Servers, Server Farms

 

Configuration of Private VLANs

The objective of this exercise is meet the requirements of a webhosting company.  They have employed you to configure the following PVLAN setup for their tenants.

VLANs in your VLANs so you can isolate while you isolate

 

First of all we define the PVLAN Type. This allows us to assign which VLAN will be a primary, community or isolated PVLAN

Defining the VLAN type
vlan 50
  private-vlan primary
vlan 51
  private-vlan community
vlan 52
  private-vlan isolated
vlan 50
  private-vlan association 51,52
Now that we have assigned our PVLAN type we need to
Assigning  ports to their PVLAN and port role
int gi0/10
  switchport mode private-vlan host
  switchport private-vlan host-association 50 51
int gi0/11
  switchport mode private-vlan host
  switchport private-vlan host-association 50 51
int gi0/12
  switchport mode private-vlan host
  switchport private-vlan host-association 50 52
int gi0/13
  switchport mode private-vlan host
  switchport private-vlan host-association 50 52
int gi0/15
  switchport mode private-vlan promiscuous
  switchport private-vlan mapping 50 add 51,52
Confirmation of PVLAN settings
show vlan private-vlan type
Vlan Type
---- -----------------
50   primary
51   community
52   isolated
show vlan private-vlan
Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
50      51        community         Gi0/10, Gi0/11, Gi0/15
50      52        isolated          Gi0/12, Gi0/13, Gi0/15

 

Easy enough. I was always daunted by this topic but now after labbing it I have found it to be quite nice and easy. Also remember that this is a 3560 series and higher technology. Sorry 3550!

 

Inter-VLAN Routing

Making VLAN’s speak to others

In the previous post regarding VLAN’s and Trunking we went through what a vlan was and how to configure one. We also discussed how to communicate between switches with trunks. Now the time has come to establish communication between vlan’s and start creating our campus segregation.

I won’t be covering inter-vlan routing in regards to router-on-a-stick configurations. It doesn’t scale and it’s just not on. I will highlight why Layer 3 switching is better done on switches. Personal Preference.

Let’s get chatty.

Now we have some Vlan’s set up. 1 by default and 20, 21 and 22. Currently the switches in our network contain these  vlan’s and trunks interconnect the switches. STP is blocking redundant ports and everyone is happy. Now the time has come to make the vlan’s talk to one another.

By definition a vlan is a broadcast domain. It confines layer 2 traffic to the vlan. This vlan may be local or end to end. Generally vlan’s are associated with a subnet. For reference with this article here is the IP’s and vlan names I am going to use.

  • Vlan 1 – Default
  • Vlan 20 – Servers – 192.168.20.0/24
  • Vlan 21 – Marketing Switch – 192.168.21.0/24
  • Vlan 22 – Accounting Switch – 192.168.22.0/24
When you create a vlan on a layer 3 multi layer switch, the device creates a switched virtual interface or an SVI. This SVI becomes an interface. This is show like any other physical interface. It is like a loopback on a router. You can assign an IP address to this SVI and you can use it as a gateway.
By default, vlan1 has a SVI created for it that allows for remote management when an IP address is assigned. Please don’t use vlan 1 for switch management. Make a separate vlan and use access lists to control who and where people can access your infrastructure from.
The 3560 used in this example is my distribution layer switch with 2 2960′s downstream from gi0/1 and gi0/2
3560(config)# vlan 20
3560(config-vlan)# name SERVERS
3560(config-vlan)# exit

3560(config)#interface vlan 20
3560(config)#ip address 192.168.20.1 255.255.255.0
3560(config)#no shutdown

Here I have configured the Server vlan. I prefer to use capitals for vlan names, descriptions and access list names as it stands out in the show running config. I have created the vlan with the top two commands. Upon issuing the int vlan 20 command I have created a SVI that I mentioned earlier. This will be the gateway for our server vlan.

I will cover DHCP and the like in a later blog but for now static IP’s are the order for the day. (Servers generally have statics anyway but in this case all vlan’s will have static for todays example)

The SVI is now a gateway for traffic to leave the vlan and communicate with other Vlans.

3560(config)# vlan 21
3560(config-vlan)# name MARKETING_SWITCH
3560(config-vlan)# exit

3560(config)#interface vlan 21
3560(config)#ip address 192.168.21.1 255.255.255.0
3560(config)#no shutdown

Here is the secondary VLAN in which I want to communicate with. 2960-1 is the marketing department switch. Gi0/1 on each switch is a trunk. See my other blog mentioned at the top to configure the trunk. With VTP on at this stage and settings configured correctly my vlan’s will propagate from the 3560 to the 2960 quickly and without me configuring them. Thanks for that.

3560(config)# interface range gi0/10 - 20
3560(config-if)# switchport mode access
3560(config-if)# switchport access vlan 20
2960-1(config)# interface range gi0/2 - 24
2960-1(config-if)# switchport mode access
2960-1(config-if)# switchport access vlan 21

With some simple interface range commands I have configured and plugged in my devices. Servers into the distribution 3560 vlan 20 access ports and the marketing iMacs into the 2960-1 Marketing DERPartment switch.

Due to the fact that both SVI’s are connected interfaces they both now can connect to each other and talk. We have successfully enabled inter-vlan routing.

3560#sh ip route
Codes: <<!! Omitted for Brevity !! >>

C    192.168.20.0/24 is directly connected, Vlan20
C    192.168.21.0/24 is directly connected, Vlan21

Here we confirm the information regarding out SVI’s. Now to ping

IPv4 Address. . . . . . . . . . . : 192.168.21.10
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 192.168.21.1

ping 192.168.20.10

Pinging 192.168.20.10 with 32 bytes of data:
Reply from 192.168.20.10: bytes=32 time<1ms TTL=128
Reply from 192.168.20.10: bytes=32 time<1ms TTL=128
Reply from 192.168.20.10: bytes=32 time<1ms TTL=128
Reply from 192.168.20.10: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.20.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

With conformation from the devices in each vlan we can happily sign off that our inter-vlan routing configuration works.

Some additional notes

SVI autostate is where the conditions of the virtual interface have been met and the SVI status is up/up.
  • Vlan exists and is active in vlan.dat on that switch
  • Vlan interface exists and is not administratively down
  • One layer 2 port exists on the switch in the up state and is in spanning-tree forwarding state.

 

 

 

Deepdive into VLANs and Trunking

Here within for my own reference is VLAN study notes. VLAN technology is a layer 2 broadcast domain that is ultra powerful.

VLANS

End to End

Vlan’s that span the enterprise. Geographically dispersed. For example, Student VLAN at each end of the campus that traverses multiple switches. VTP modes should be set to client or ~shudder~ server.

Local

Significant to the local switch. Generally confined to a wiring closet. Layer 2 switching is performed at the access layer with routing performed at distribution and core layers. One switch for a room for 20 users who are all in Marketing. Vlan 20 – Marketing would be better placed as a local vlan to this switch than on every switch in the enterprise.

VTP modes should be set to transparent to allow the vlan to stay local.

Saves on unessential traffic through distribution and core layers!

Considerations

  • Grouping users on a common sub-network. ie Staff, Students, Servers, Marketing. Different VLAN’s can help reduce broadcast traffic
  • Security is a fantastic reason for Vlan’s. I may not want the students accessing Marketing’s information.
  • A Voice vlan could be given a different QoS policy opposed to the students.
  • If most of the traffic is destined for devices in the same vlan then there is a reduced impact on routing/inter-vlan routing
  • If you use end to end Vlan’s note that broadcast traffic will traverse trunks. EVEN if there are no switch-ports assigned to that vlan on that switch!
  • Local vlan’s have a smaller failure domain than end to end. Imagine a VTP mishap on end to end.
Healthy VLAN Design Practice
  • Local vlan’s should have 1-3 vlan’s per switch.
  • Blackhole vlan’s should be anything but vlan 1.
  • Avoid VTP with local vlan’s.
  • Only permit control protocols on vlan 1.
  • SSH support on management vlan’s. Block telnet!
Simple VLAN configuration
switch(config)# vlan 10
switch(config-vlan)# name Management
switch(config-vlan)# exit

switch(config)# interface vlan 10
switch(config)# ip address 192.168.10.10 255.255.255.0
switch(config)# no shutdown

The first part of the configuration defines the VLAN in the vlan database. We set a name to identify it. We then enter the switching virtual interface (SVI) for the vlan and we assign a management IP address. No shutdown finally to bring up the Vlan 10 interface.

switch(config)# interface gi0/1
switch(config-if)# switchport mode access
switch(config-if)# switchport access vlan 10

We select the interface we want to associate to the VLAN. Change the mode to access to allow an end-user device and we set the switchport to reside in vlan 10.

Detail port information can come from issuing the following commands. The output is invaluable in my opinion. What situation do you feel will yield the most value?

switch#show int gi1/0/8 switchport
Name: Gi1/0/8
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 10 (Management)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

This verification allows us to confirm which vlan the switch-port is accessing and includes such information as native vlan and port settings. Fantastic command.

Trunks and Trunking

What is a trunk?

Trunks carry multiple vlan’s across a single physical link by using a trunking encapsulation protocol. If a frame from a vlan wants to traverse a trunk link, the encapsulation protocol uses the vlan id (VID) to ID the frame. The destination switch removes the frame and forwards it to the access port!

The two encapsulation protocols are ISL and 802.1q. ISL is Cisco proprietary and 802.1q is IEEE standard. ISL is almost obsolete. The important things to know about it is how it encapsulation the normal ethernet frame. ISL adds a 26 byte header and a 4 byte Frame Check Sequence. In a standard ethernet frame there is a FCS field already.

802.1q is widely supported. I use it. You use it. I think my cat might. 802.1q has a smaller frame overhead and therefore is more efficient. 4 bytes vs 30 bytes per frame. That can add up fast. There is also support for 802.1p fields for QoS. Handy in this day and age.

802.1q Frame Deep Dive

  • Dest: Destination Mac (6 bytes)
  • Src: Source Mac (6 bytes)
  • Tag: 802.1q Shivs this in (4 bytes)
  • Ethertype(TPID): Set to 0×8100 specifies tag to follow
  • PRI: 3-bit QoS 802.1p priority field
  • CFI: 0 = Ethernet 1= Token Ring
  • VLAN ID: 12 bit VLAN field. 4096 – 2 Total Vlans. VID of 0 indicates priority frames. 4095 (FFF) is reserved. 
  • Len/Etype: Specifies length or type (2 bytes)
  • Data: Contents
  • FCS: Frame Check Sequence (4 bytes)
That red that stands out denotes the information that 802.1q shivs in on a normal ethernet frame. Rather small if you are to compare ISL. 802.1q leverages the existing FCS where ISL adds its own.
What is the Native VLAN and why do I need to know what it is?
Switches forward all un tagged frames to its native vlan. Native VLAN at each end must match. If there is a mismatch, CDP will display a native vlan mismatch error.
Trunk Configs
switch(config)# interface gi0/24
switch(config-if)# switchport trunk encapsulation dot1q
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk native vlan 2

switch(config-if)# switchport trunk allowed vlan all
                 ----or----
switch(config-if)# switchport trunk allowed vlan add 1,10,20

Here we have an example trunk config. Look at how it is very similar to the access port. There are quite a few features but if you have read this far you will notice some things we spoke about. Under the interface we set the encapsulation to dot1q, the port mode to trunk, change the default vlan to two (Remember to it at the other end!)

The last two lines are what is known as vlan pruning. We are specifying what vlan’s we would like to traverse out trunks. The first command allows all across this trunk. The second command allows only 1,10,20. You could issue the allowed all command and then remove unwanted vlan’s or add exceptions.

Confirm trunk status and information

 

Verification! The CCNP certification loves this word. You should too.
switch#show int gi1/0/2 trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/2     on           802.1q         trunk-inbndl  2
                                      (Po1)

Port        Vlans allowed on trunk
Gi1/0/2     1-4094

Port        Vlans allowed and active in management domain
Gi1/0/2     1,5,10-12,20,24-25,30,40,50,60,100-101,140,148-149,172,200

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/2     1,5,10-12,20,24-25,30,40,50,60,100-101,140,148-149,172,200

Here is the trunk information and the vlan’s which are allowed onto the trunk. Encapsulation is listed here.

 

switch#show int gi1/0/2 switchport
Name: Gi1/0/2
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk (member of bundle Po1)
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 2 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

Again, like the access port, all the juicy information about the switchport in regards to layer 2 switching are kept here. Notice trunking encapsulation is set to 802.1q and the administrative mode is set to trunk.

Happy Days!

VTP – Very Trying Protocol (Vlan Trunking Protocol)

The last couple of weeks I have been designing and working on a rather large switched project. Overall the topology isn’t complex, it just spans a large area. The length is about 3 kilometres.

The project uses 2960S/G and 3560x model switches with SFP SM Fibre between each with redundancy in between each switch. Once spanning tree was sorted with setting priorities as required by the brief I started to implement VTP.

Working over two days I was copying the config of VTP across from a base config. I have found a few little caveats.

  • VTP configs aren’t displayed in Show Run. When you are making a base template for a common group of switches you must ensure you either input the information or manually add it to each switch.
  • VTP Password. Make sure you have the same password across the entire domain! Enough said.
I found in hindsight it is best to configure VTP if you decide on using it before you create VLANs. Designate what switches you want to be the servers and where you want client and transparent switches. This way you won’t have to deal with any issues pertaining to revision numbers or human input!
I did lose my VLAN database once due to not paying attention and placing the wrong switch as a server. Shoop! There goes some VLANs!
No wonder there are though out there who love/hate it. It’s that kind of protocol!
And as always, wr mem.