VLAN Trunking, VLAN Trunking Protocol (VTP)

VLAN trunking allows switches, routers, and even PCs with the appropriate network interface cards (NIC) and/or software drivers to send traffic for multiple VLANs across a single link.

On trunks, 802.1Q does not tag frames sent inside the native VLAN, and assigns all received untagged frames to the native VLAN. The native VLAN feature allows a switch to attempt to use 802.1Q trunking on an interface, but if the other device does not support trunking, the traffic for that one native VLAN can still be sent over the link.It is absolutely necessary that the native VLANs on both ends of a  trunk link match; otherwise a native VLAN mismatch occurs, causing the two VLANs to effectively merge.

As a best practice, on each trunk, its native VLAN should be changed from VLAN 1 to a different VLAN,  and this VLAN should not be used for any other purpose except being configured as a native VLAN. This prevents users from attempting a VLAN hopping attack by sending double-tagged frames that would be detagged on trunks if the top tag matches the trunk’s native VLAN

DTP modes - Dynamic auto: The port will negotiate the mode automatically; however, it prefers to be an access port. Dynamic desirable: The port will negotiate the mode automatically; however, it prefers to be a trunk port.

While DTP and VTP are independent protocols, DTP carries the VTP domain name in its messages. Switches will successfully negotiate the link operating mode only if the VTP domain name on both switches is the same, or one switch has no VTP domain name configured yet (that is, it uses a NULL domain name).

Commands to check trunk

show interfaces trunk
show interfaces f0/1 trunk
show interfaces f0/1 switchport
show dtp

Configuring Trunk on Routers

Use subinterface numbers starting with 1; the subinterface number 0 is the physical interface itself (for example, interface Fa0/0.0 is the Fa0/0 itself).You can configure 802.1Q native VLANs under a subinterface or under the physical interface on a router. If they are configured under a subinterface, you use the encapsulation dot1q vlan-id native subcommand.If not configured on a subinterface, the router assumes that the native VLAN is associated with the physical interface. In this case, the encapsulation command is not needed nor supported  under the physical interface; the associated IP address, however, would need to be configured under the physical interface.

ISL configuration with no native VLAN

 #interface f0/0

 #no shut

 #interface f0/0.1

 #encapsulation isl 21

 #ip address 10.1.21.1 255.255.255.0

 #interface f0/0.2

 #encapsulation isl 22

 #ip address 10.1.22.1 255.255.255.0

802.1Q configuration with native VLAN (vlan21) on physical interface

 #interface f0/0

 #ip address 10.1.2.1.1 255.255.255.0

 #no shut

 #interface f0/0.2

 #encapsulation dot1q 22

 #ip address 10.1.22.1 255.255.255.0

VLAN Trunking Protocol 

VTP advertises VLAN configuration information to neighboring switches so that the VLAN configuration can be made on one switch, with all the other switches in the domain learning the VLAN information dynamically. VTP advertises the VLAN ID, VLAN name, and VLAN type and state for each VLAN.

In VTPv1 and VTPv2, a transparent switch whose VTP domain was NULL (that is, unconfigured) forwarded all VTP messages happily. A transparent switch with a configured domain forwarded VTP messages only if their domains matched.

One of the enhancements in VTPv3 is - The server role has been modified: There are two server types in VTPv3: primary and secondary. A primary server is allowed to modify VTP domain contents, and there can be at most one primary server per VTP domain at any time. A secondary server (often called just a server) is not allowed to modify VTP domain contents, but it can be promoted to the role of primary server, retaking the role from the existing primary server if it exists.

VTPv1 and VTPv2 use four types of messages

Summary Advertisement: This message is originated by VTP Server and Client switches every 5 minutes and, in addition, after each modification to the VLAN database. This message carries information about VTP domain name, revision number, identity of the last updater, time stamp of the last update, MD5 sum computed over the contents of the VLAN database and the VTP password (if configured), and the number of Subset Advertisement messages that optionally follow this Summary Advertisement. Summary Advertisement messages do not carry VLAN database contents.

Subset Advertisement: This message is originated by VTP Server and Client switches after modifying the VLAN database. Subset Advertisements carry full contents of the VLAN database.

Advertisement Request: This message is originated by VTP Server and Client switches to request their neighbors send the complete VLAN database or a part of it.

Join: This message is originated by each VTP Server and Client switch periodically every 6 seconds if VTP Pruning is active.

Cisco switches default to use VTP server mode, but they do not start sending VTP updates until the switch has been configured with a VTP domain name.

At that point, the server begins to send its VTP updates, with an updated database and revision number each time its VLAN configuration changes. However, the VTP clients actually do not have to have the VTP domain name configured. If not configured yet, the client will assume that it should use the VTP domain name in the first received VTP update. 

MD5 hash is computed from vlan database and own VTP pasword. The receiving switch computes its own MD5 hash over the contents of the VLAN database reconstituted from these messages and its own VTP password, and compares it to the MD5 hash value indicated in the Summary Advertisement.

VTPv3 servers and clients will share their VLAN database only if they agree both on the 

domain name and on the identity of a primary server (given by its base MAC address). 

Even in VTPv3, a secondary server or a client switch with a higher revision number can overwrite a neighbor’s VLAN database, but for this to occur, these switches must first match on the domain name, primary server’s identity, and VTP password.  

The state of two or more server or client switches in a VTPv3 domain having different opinions about the identity of a primary server is called a  conflict . Conflicting switches do not synchronize their VLAN databases even if all other VTP parameters match. 

A switch newly promoted to the role of a primary server using the  vtp primary  command will flood its VLAN database to  its neighbors, and they will install and flood it further even if the new primary server’s revision number is lower. 

VTP Configuration

VTP sends updates out all active trunk interfaces (ISL or 802.1Q) by default.

Interface option specifies the interface whose IP address is used to identify this switch as an updater in VTP updates. By default, a configured IP address from the lowest numbered VLAN SVI interface will be used.  

In VTPv3, each switch must be configured individually for version 3 operation.

 #vtp version 3

 #vtp mode client

cannot create new Vlan on vtp client mode or on normal sever mode

server#do vtp primary

setting vtp pasword with hidden will never display clear text in config

server#vtp password cisco123 hidden

This encrypted string can be used to populate password settings on other switches

server#do show vtp password

VTP Password: 8C70EFBABDD6EC0300A57BE402409C48

After password is configured in the secret form,any attempt to promote a switch to the primary server role will require entering the password in the plain text form. So, without knowing the plaintext form of the password, it's not possible to designate a switch as a primary server.

If using VTPv1 or VTPv2, these additional VLANs cannot be configured in VLAN database mode, nor stored in the vlan.dat(in flash) file, nor advertised through VTP. To configure them, the switch must be in VTP transparent mode.  VTPv3 removes these limitations: Both normal- and extended-range VLANs can be advertised by VTPv3. Also, with VTPv3, information about all VLANs is again stored in the vlan.dat file in Flash.

Virtual LAN - VLAN

A VLAN can either be active, which is the default state, or it can be suspended.

Modifying the Operational state of VLANs
In vlan config,
 #state suspend
 #state activate
In VTP domain, can use "shutdown" configuration to locally shutdown the vlan without affecting other switches.

Private VLANs allow a switch to separate ports as if they were on different VLANs, while consuming only a single subnet.

Conceptually, a Private VLAN is a mechanism that partitions a given VLAN into an arbitrary number of nonoverlapping sub-VLANs, or  secondary VLANs. Outside world continues to see only the original VLAN - in this cased called primary VLAN.

Secondary VLANs can be of two types:  community  VLANs and  isolated  VLANs. Ports assigned to the same community VLAN can communicate with each other directly, but they are not allowed to communicate with ports in any other VLAN. This behavior is similar to ordinary VLANs.
Ports assigned to an isolated VLAN can neither communicate with each other nor with ports in any other VLAN.

A single primary VLAN can be associated with zero or more community VLANs and with at most one isolated VLAN. A secondary VLAN, either a community or an isolated VLAN, must be associated with exactly one primary VLAN.
Both community and isolated ports behave as normal access ports—they technically belong to a single VLAN and they do not tag frames.

A promiscuous port is not associated with any particular secondary VLAN. Instead, it is associated with the corresponding primary VLAN itself. A device connected to a promiscuous port can communicate with devices in all secondary VLANs associated with this primary VLAN and vice versa.

A frame received on a promiscuous, community, or isolated port can always be forwarded through a trunk port.

 A frame received on a community or isolated port will be tagged with the ID of the corresponding secondary VLAN when forwarded out a trunk.

A frame received on a promiscuous port will be tagged with the ID of the corresponding primary VLAN when forwarded out a trunk.

A Primary VLAN can be seen as a VLAN carrying “downstream” traffic from promiscuous ports to other promiscuous ports and hosts in all associated secondary VLANs.  

Secondary VLANs do not exist “inside” their primary VLAN; rather, they are only associated  with it.

Promiscuous PVLAN Trunk - Whenever a frame from a secondary VLAN is going to be sent out such a trunk, its VLAN tag will be rewritten with the appropriate primary VLAN ID. Rewrites is necessary when a trunk carrying a set of VLANs including Private VLANs is to be connected to an external device that does not support Private VLANs, yet which shall be reachable from the Private VLANs as if connected to a promiscuous port.

In essence, a Promiscuous PVLAN Trunk port rewrites the secondary VLAN ID into the pri mary PVLAN ID upon sending a frame. When a frame is received, no tag manipulation is performed. Also, no tag manipulation is performed for frames in ordinary VLANs.

Isolated PVLAN Trunk - translates a primary VLAN ID into the ID of the isolated VLAN that is associated with the primary VLAN. This is used to extend the isolated VLAN over a trunk carrying multiple VLANs to a switch that does not support Private VLANs but is capable of isolating its own ports.

In essence, an Isolated PVLAN Trunk port rewrites the primary VLAN ID into the isolated secondary VLAN ID upon sending a frame. When a frame is received, no tag manipulation is performed. Also, no tag manipulation is performed for frames in ordinary VLANs.

Configuration 

//If not running VTPv3, a switch must be put into VTP Transparent mode before configuring Private VLANs

 #vlan 199
 #name Isolated
 #private-vlan isolated
 #vlan 101
 #name Community1
 #private-vlan community
 #vlan 102
 #name Community2
 #private-vlan community
 #vlan 103
 #name Community3
 #private-vlan community
 #vlan 100
 #name Primary1
 #private-vlan primary
 #private-vlan association 101-103,199

 #int range f0/1 -3
 #switchport mode private-vlan host
 #switchport private-vlan host-association 100 101
 #int f0/13
 #switchport mode private-vlan promiscuous
 #switchport private-vlan mapping 100 101-103,199

 If a SVI is used as a gateway for devices associated with primary Vlan100, it must also be configured as promicuous
 #interface vlan100
 #private-vlan mapping 101-103,199
 #ip address 192.168.100.254 255.255.255.0

show vlan private-vlan

IP TCP UPD headers

• The MTU is the maximum size of an IP packet that can be transmitted without fragmentation.
  IPv4 mandates a path MTU of at least 576 bytes, IPv6 of at least 1280 bytes.
  Ethernet has an MTU of 1500 bytes.
• An IP packet is composed of two parts: the packet header and the payload.
  The size of an IPv4 header is at least 20 bytes, the size of an IPv6 header at least 40 bytes.
  The payload of an IP packet is typically a TCP segment or a UDP datagram.
• A UDP datagram consists of a UDP header and the transported data.
  The size of a UDP header is 8 bytes.
• The size of a TCP header is at least 20 bytes.

This means an IP packet with an empty UDP datagram as payload takes at least 28 (IPv4) or 48 (IPv6) bytes, but may take more bytes.

For TCP segments, a minimum of 40 bytes are needed for TCP and IP headers. 

Also note that in the case of Ethernet, the IP packet will additionally be wrapped in a MAC packet (14 byte header + 4 byte CRC) which will be embedded in an Ethernet frame (8 byte preamble sequence). This adds 26 bytes of data to the IP packet, but doesn't count against the MTU.

Virtual Switch System

The fundamental reason for employing a VSS is to logically combine a pair of switches into a single network element.

The VSS active and standby switches perform packet forwarding for ingress data traffic on their locally hosted interfaces. However, the VSS standby switch sends all control traffic to the VSS active switch for processing.

The virtual switch link (VSL) is a special link that carries control and data traffic between the two switches of a VSS.

Data traffic is load balanced  among the VSL links by either the default or the configured EtherChannel load-balancing algorithm.

MultiChasis EtherChannel (MCE)

Layer 2 protocols operate on the EtherChannel as a single logical entity.

VSS enables the creation of Multichassis EtherChannel (MEC), which is an EtherChannel whose member ports can be distributed across the member switches in a VSS.

A VSS can support a maximum of 256 EtherChannels.

VSS Configuration

You have to create the same virtual switch domain on both sides of the VSS.

Switch domain number must fall between 1 and 255.
During the configuration, both port channels are set up on the VSS active switch.
Check that both port channel numbers are available on both of the peer switches.

 SW1#switch virtual domain 10
 SW1#switch 1
 SW1#exit

 SW2#switch virtual domain 10
 SW2#switch 2
 SW2#exit

 SW1#int port-channel 5
 SW1#switchport
 SW1#switch virtual link 1
 SW1#no shut
 SW1#exit

 SW2#int port-channel 10
 SW2#switchport
 SW2#switch virtual link 2
 SW2#no shut
 SW2#exit

 SW1#int range g7/3 - 4
 SW1#switchport mode trunk
 SW1#channel-group 5 mode on
 SW1#exit

 SW2#int range g4/4 - 5
 SW2#switchport mode trunk
 SW2#channel group 10 mode on
 SW2#exit

 SW1#switch convert mode virtual
 reboot

 SW2#switch convert mode virtual
 reboot

Verification
 #show switch virtual
 #show switch virtual role
 #show switch virtual link
 #show switch virtual link port-channel

SPAN, RSPAN and ERSPAN

SPAN sessions can be sourced from a port or ports, or from a VLAN.

In RSPAN, a specific VLAN must be configured across the entire switching path from the source port or VLAN to the RSPAN destination port. This requires that the RSPAN VLAN be included in any trunks in that path, too.

Create a SPAN source that consists of at least one port or at least one VLAN on a switch.

Regardless of the type of SPAN we are running, a SPAN source port can be any type of port — a routed port, a physical switch port, an access port, a trunk port, an EtherChannel port (either one physical port or the entire port-channel interface).

On a SPAN source VLAN, all active ports in that VLAN are monitored.

A port configured as a SPAN destination cannot be part of a SPAN source VLAN.

Restrictions and Conditions

When you configure a destination port, its original configuration is overwritten. If the SPAN configuration is removed, the original configuration on that port is restored.  

When you configure a destination port, the port is removed from any EtherChannel bundle if it were part of one. If it were a routed port, the SPAN destination configuration overrides the routed port configuration.  

Destination ports do not support port security, 802.1x authentication, or private VLANs. In general, SPAN/RSPAN and 802.1x are incompatible.  

Destination ports do not support any Layer 2 protocols, including CDP, Spanning Tree, VTP, DTP, and so on.  

SPAN source can be either one or more ports or a VLAN, but not a mix of these.  

Up to 64 SPAN destination ports can be configured on a switch.

A SPAN destination port cannot be a source port, and a source port cannot be a destination port.  

A SPAN destination port stop acting as a normal switch port. It passes only SPAN-related traffic.  

Traffic that is routed from another VLAN to a source VLAN cannot be monitored with SPAN.

For receive(RX) SPAN, the traffic is forwarded to SPAN destination before any filtering,QoS or even ingress or egress policing

For transmit(TX) SPAN,all relevant modification or filtering is done before it's forwarded to R/SPAN destination.So frames delivered may or may not match original frames.

SPAN Configuration

 #monitor session 11 source interface fa0/18 rx
 #monitor session 11 source interface fa0/9 tx
 #monitor session 11 source interface fa0/19 (trunk port)
 #monitor session 11 filter vlan 1 - 3, 229
 #monitor session 11 destination interface fa0/24 encapsulation replicate

RSPAN COnfiguration (session number must be 1 to 66)
On source switch
 #vlan 199
 #remote span
 #exit
 #monitor session 11 source vlan 66 - 68 rx
 #monitor session 11 destination remote vlan 199

On destination switch
 #vlan 199
 #remote span
 #exit
 #monitor session 63 source remote vlan 199
 #monitor session 63 destination interface fa0/24


ERSPAN Configuration
 #monitor sesion 1 type erspan-source
 #source interface g0/1/0 rx
 #no shutdown
 #destination
 #erspan-id 101
 #ip address 10.1.1.1
 #origin ip address 172.16.1.1

 #monitor session 2 type erspan-destination
 #destination interface g2/2/1
 #no shutdown
 #source
 #erspan-id 101
 #ip address 10.1.1.1

Verification command
 #show monitor session

IPSec Site to Site VPN

Reverse Route Injection (RRI) - after ASA is configured with crypto ACL/map to for traffic from source to destination subnets, and after successful SA, destination networks are added to routing table as static routes.Those routes can be redistributed into internal routing protocols for other internal routers.


Document Resource

SSL VPN Configuration Guide, Cisco IOS.Release 15M&T

Group Encrypted Transport VPN (GET VPN)

Ingredients
 -Key Servers (KS)
 -Key Encryption Key (KEK) - used between Key server and GMs for rekeying(TEK),policy push down after IKE phase 1 sa is torn down
 -Traffic Encryption Key (TEK)- 1 SA(key for encrypting/decrypting traffic for all group members)
 -Key Distribution (IKE, Group Domain of Interpretation(GDOI))
 -Group Members (GM)
 -Group SA
 -Rekeying

Why GET VPN?
For other types of VPNs(like site to site VPN), multicast traffic has to send multiple times from Hub to spokes as each spoke has a separate tunnels.
For Flex VPN & DMVPN where dynamic tunnels are built automatically, first few packets might be lost or routed through hub before direct tunnel is built between spokes. This might not be acceptable sometimes.

In GET VPN, they don't need direct tunnel between them and they can still send encrypted traffic.
GET VPN is not the perfect solution for every topology. Default topoloy for GET VPN is designed is for Full Mesh.

In GET VPN, IP header from source A to dest B is not modified; it preserves IP header.So, the ISP or any intermediate routers must know how to route this traffic between source A and dest B. This is different from other VPN types where these source,dest IP headers are hiiden inside IPSec. That's how hub needs to send only once for multicast traffic in GET VPN.
In GET VPN behind IP header, there is still ESP(protocol #50) used by IPSec.

Group members use the same Traffic encryption key(TEK) and same security association (SA).
It is made possible by Group Domain of Interpretation(GDOI).

Which traffic to be encrypted is decided by Policy.
On Key Server, we define what traffic to encrypt/decrypt using ACL.

Who are the GM?
Any device that have registered and authenticated with Key Server.
Group server and Group member authenticate each other using IKE.

GET VPN Configuration

Key Server
R5#crypto isakmp policy 10
  #hash sha256/sha
  #authentication pre-share
  #group 14/5
  #lifetime 180
  #encryption aes 256
  #crypto isakmp key cisco123 address 0.0.0.0

  #crypto key gen rsa general label GETVPN mod 1024 exportable

  #crypto ipsec transform-set Our-TSET esp-aes 192 esp-sha-hmac

  #crypto ipsec profile GDOI-Profile
  #set transform-set Our-TSET
  #set security-association lifetime seconds 300 //traffic encryption key lifetime
!
  #crypto gdoi group Our-GETVPN
  #identity number 6783 //need to match in Key server and group members
  #server local
  # address ipv4 5.5.5.5 //group server address
  #rekey transport unicast //adv of unicast is KS will wait for ack from GM.
  #rekey lifetime seconds 600 //lifetime of key encryption key
  #rekey retransmit 10 number 2
  #rekey authentication mypubkey rsa GETVPN //the one generated earlier

  #sa ipsec 1
  #profile GDOI-Profile //the one we created earlier
  #match address ipv4 101 //acl whether to encrypt the traffic
  #replay time window-size 5
!
  #ip access-list extended 101
  #permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

  #router ospf 1
  #net 0.0.0.0 255.255.255.255 area 0

R1
  #crypto isakmp policy 10
  #hash sha256/sha
  #authentication pre-share
  #group 14/5
  #lifetime 180
  #encryption aes 256
  #crypto isakmp key cisco123 address 0.0.0.0

  #crypto gdoi group Our-GETVPN
  #identity number 6783 //need to match in Key server and group members
  #server address ipv4 5.5.5.5 //group server address

  #crypto map GETVPN-MAP 10 gdoi
  #set group Our-GETVPN //the one we created earlier

  #int f0/0 //outside interface
  #crypto map GETVPN-MAP
  #ip tcp adjust-mss 1360

  #router ospf 1
  #net 0.0.0.0 255.255.255.255 area 0

sh crypto gdoi
sh crypto gdoi ks policy
sh crypto gdoi ks acl
sh crypto gdoi ks rekey
sh crypto gdoi ks member
sh crypto session

Public Key Infrastructure - PKI - Certificates

PKI
Authenticate CA (R1 request CA's public key from CA)
Enrol (R1 sends public key portion of generated private/public key pair to CA; with

other details to request its own digital certifcate from CA)
CA issues Identity certificate to R1
R1 and R2 validate each other by looking at signature of the digital certificate

signed by CA(they both trust).R1 and R2 can verify the signature of the CA because
they both have authenticated with CA and they both have a copy of public key of CA)

Configuration Steps to act Router as a CA
-can act as a ntp server (#ntp master 5)

//manually generate and use rsa key for CA
Server(config)#crypto key generate rsa label VPN-KEYS modulus 1024 exportable
Server(config)#crypto pki trustpoint CA
Server(ca-trustpoint)#rsakeypair VPN-KEYS
Server(ca-trustpoint)#exit

-#ip http server
-#crypto pki server CA
-#issuer-name CN=CA, O=cbtlocal
-#grant auto
-#no shutdown
show crypto pki server

Steps to enroll Router to CA to obtain a Digital Certificate,Creating a trustpoint
generate rsa key and give it a name
-#crypto pki trustpoint Trusted-CA
-#enrollment url http://5.5.5.5
-#rsakeypair r1.cbtnuggets.com
-#fqdn r1.cbtnuggets.com
-#subject-name CN=r1,O=cbtnuggets.com
-#revocation-check none

To get public key of the CA (authenticating the CA)
-#crypto pki authenticate Trusted-CA
show crypto pki trustpoints
show crypto pki certificates

To enroll to obtain digital cert
-#crypto pki enroll Trusted-CA

RSA Signature IKEv2 Authentication

Create a certificate map

 can match a few things, for example, issuer-name

Create IKE v2 proposal

 specify encryption, integrity and dh group

Create IKE v2 policy

 Use the proposal created above

Create IKE v2 profile

 need to specify Authentication methods for local and remote;identity or match certificate statement

 (optional: virtural template number must be specified here for DVTI)

Specify certificate authorities to trust

Create IPSec Transform set

 example, esp-aes esp-sha-hmac

 Mode transport

Create IPSec Profile

 set the transform set created earlier

 set the ike profile created earlier

Create a tunnel interface or virtual template interface

 Also run routing protocol is necessary

Configuration Files

CA.cfg

R1.cfg

R2.cfg

R3.cfg