CCNP ROUTE 300-101 Part 3.8 – Configure and Verify VRF-Lite

Cisco Virtual Routing and Forwarding-Lite

In this article I’m sharing the basics of VRF Lite with two practical labs. I’ve received a couple of requests about this some time ago so, here it is. Note that the second lab is one I found on the internet and made a few changes.

Service providers often need to allow their customers’ traffic to pass through their cloud
without one customer’s traffic (and corresponding routes) be exposed to another customer.

VRF configuration isn’t at all dependent on MPLS but often the two components are chosen to run together. In Cisco terminology, deployment of VRFs without MPLS is known as VRF Lite.

Similarly, enterprise networks might need to segregate various application types, such as keeping voice and video traffic separate from data. These are just a couple of scenarios that could benefit from the Cisco Virtual Routing and Forwarding (VRF) feature.

VRF allows a single physical router to host multiple virtual routers, with those virtual routers logically isolated from one another, each with its own IP routing table. Simply put it, VRF’s are VLANs for layer 3, and is the basics to understanding MPLS.

Note:  Some Cisco documentation states that VRF is an acronym for Virtual Routing and
Forwarding, while other Cisco documentation states that VRF is an acronym for VPN Routing/Forwarding because of its common use in Virtual Private Networks VPN.

Cisco Easy Virtual Network (EVN), is a newer approach to VRF configuration, as compared to VRF-Lite. With VRF-Lite, if you want to send traffic for multiple virtual networks (that is, multiple VRFs) between two routers, you need to create a subinterface for each VRF on each router. However, with Cisco EVN, you instead create a trunk (called a Virtual Network
(VNET) trunk) between the routers. Then, traffic for multiple virtual networks can travel
over that single trunk interface, which uses tags to identify the virtual networks to which
packets belong.

Even though Cisco EVN can help reduce the amount of configuration required for a VRF
solution, VRF-Lite configuration is still often used in VRF networks. This section covers
the basics of setting up and verifying a VRF configuration, for VRFs using OSPF as their IGP.

 

VRF-Lite Configuration and Verification

Below lists the steps to configure a basic VRF-Lite configuration for VRF instances
running OSPF.

Note:  VRF-Lite has several other options, beyond the scope of this post. For example,
you can allow VRF to selectively “leak” routes between VRF instances.

ip vrf vrf-name: A global command that creates a VRF and enters VRF configuration mode.

ip vrf forwarding vrf-name: Interface or subinterface configuration command that assigns an interface or a subinterface to a VRF instance. (Note: If the interface or subinterface already had an IP address assigned, this command will remove that address, and you will need to add it back.)

router ospf process-id vrf vrf-name: A global configuration command that
associates a unique process ID with a VRF instance and enters OSPF router configuration mode for a specific VRF instance.

 

Below is a simple topology using VRF running two different instances and OSPF. I have configured overlapping networks so we can clearly see that using VRF-Lite inside an enterprise or between an HQ and a Branch office with overlapping networks is not a problem at all. It’s also useful to understand how each VRF instance is completely separated from each other, thus its considered VPN.

 

VRF-Lite OSPF

 

Routers CA1, CA2, CB1 and CB2 have the initial configurations. I’ll add the ISP router’s configuration now. Enabling VRF globally and defining the VRFs, CA and CB respectively. Interface configuration for both VRF’s and finalizing with the OSPF configuration for VRF CA and CB. The OSPF adjacencies with both customer’s HQ and Branch offices routers should come up instantly. Let’s do it.

ISP# conf t
Enter configuration commands, one per line. End with CNTL/Z.
ISP(config)# ip vrf CA
ISP(config-vrf)# ip vrf CB
ISP(config-vrf)# int f0/0
ISP(config-if)# ip vrf forwarding CA
ISP(config-if)# description TO->CA1_HQ
ISP(config-if)# ip add 172.31.100.2 255.255.255.0
ISP(config-if)# no shut
ISP(config-if)#
*Mar 1 00:03:43.623: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 1 00:03:44.623: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
ISP(config-if)# int f1/0
ISP(config-if)# ip vrf forwarding CA
ISP(config-if)# description TO->CA2_Branch
ISP(config-if)# ip add 172.31.200.2 255.255.255.0 
ISP(config-if)# no shut
ISP(config-if)#
*Mar 1 00:08:19.927: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 00:08:20.927: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
ISP(config-if)# router ospf 100 vrf CA
ISP(config-router)# net 172.31.100.2 0.0.0.255 area 0
ISP(config-router)# net 172.31.200.2 0.0.0.255 area 0
ISP(config-router)# exit
ISP(config)# int f2/0
ISP(config-if)# ip vrf forwarding CB
ISP(config-if)# description TO->CB1_HQ 
ISP(config-if)# ip address 172.31.100.2 255.255.255.0
ISP(config-if)# no shut
*Mar 1 00:16:54.691: %LINK-3-UPDOWN: Interface FastEthernet2/0, changed state to up
*Mar 1 00:16:55.691: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to up
ISP(config)# int f3/0
ISP(config-if)# ip vrf forwarding CB
ISP(config-if)# description TO->CB2_Branch 
ISP(config-if)# ip address 172.31.200.2 255.255.255.0 
ISP(config-if)# no shut
ISP(config-if)#
*Mar 1 00:12:57.515: %LINK-3-UPDOWN: Interface FastEthernet3/0, changed state to up
*Mar 1 00:12:58.515: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up
ISP(config-if)# router ospf 200 vrf CB
ISP(config-router)# net 172.31.100.0 0.0.0.255 area 0
ISP(config-router)# net 172.31.200.0 0.0.0.255 area 0
ISP(config-router)# end
ISP#
*Mar 1 00:19:30.199: %SYS-5-CONFIG_I: Configured from console by console
ISP#
*Mar 1 03:10:06.223: %OSPF-5-ADJCHG: Process 200, Nbr 2.2.2.2 on FastEthernet3/0 from LOADING to FULL, Loading Done
ISP#
*Mar 1 03:10:07.619: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet1/0 from LOADING to FULL, Loading Done
ISP#
*Mar 1 03:10:09.115: %OSPF-5-ADJCHG: Process 200, Nbr 1.1.1.1 on FastEthernet2/0 from LOADING to FULL, Loading Done
ISP#
*Mar 1 03:10:28.771: %OSPF-5-ADJCHG: Process 100, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
ISP#

 

Looking good so far, all neighbors adjacencies came up with CA1, CA2, CB1 and CB2. Let’s examine the result in more detail beginning with ISP router.

ISP# sh ip int bri | e admin
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 172.31.100.2 YES manual up up 
FastEthernet1/0 172.31.200.2 YES manual up up 
FastEthernet2/0 172.31.100.2 YES manual up up 
FastEthernet3/0 172.31.200.2 YES manual up up 
ISP# sh interfaces description 
Interface Status Protocol Description
Fa0/0 up up VRF_CA_HQ
Fa1/0 up up VRF_CA_Branch
Fa2/0 up up VRF_CB_HQ
Fa3/0 up up VRF_CB_Branch
ISP#
ISP# sh ip vrf detail 
VRF CA; default RD <not set>; default VPNID <not set>
 Interfaces:
 Fa0/0 Fa1/0 
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
VRF CB; default RD <not set>; default VPNID <not set>
 Interfaces:
 Fa2/0 Fa3/0 
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
ISP#

From the output of the first verification commands we can see that we have overlapping segments on four interfaces but as we are using VRF they are completely separated as if it were two different routers.

The reason is that each VRF instance acts like a virtual router thus not using the global routing table. Each VRF instance, in this case VRF CA uses VRF CA routing table as I’ll demonstrate below with more verification commands, but now let’s look at the interfaces configuration. Using the interfaces description command is very helpful to keep a clean configuration, especially in complex scenarios like VRFs. interface f0/0 and f1/0 are configured in VRF CA instance and interfaces f2/0 and f3/0 in VRF CB respectively.

Using the show ip vrf detail command show us detail information about each VRF configured, including which interface is configured in each VRF so, helpful to have those interfaces description accordingly. Also, notice that it states that “connected addresses are not in global routing table”, this is because, again, each VRF uses a separate IP routing table, independant.

Let’s have a look at more verification commands. To view the contents of a specific
VRF’s IP routing table, you can use the show ip route vrf vrf-name command.

ISP# sh ip vrf
 Name Default RD Interfaces
 CA <not set> Fa0/0
              Fa1/0
 CB <not set> Fa2/0
              Fa3/0
ISP# sh ip route vrf CA | e c

Routing Table: CA
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 172.31.100.1, 03:27:48, FastEthernet0/0
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 172.31.200.3, 03:27:48, FastEthernet1/0
 172.31.0.0/24 is subnetted, 2 subnets
ISP# sh ip route vrf CB | e c

Routing Table: CB
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 172.31.100.1, 03:29:29, FastEthernet2/0
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 172.31.200.3, 03:29:29, FastEthernet3/0
 172.31.0.0/24 is subnetted, 2 subnets
ISP#

 

Each VRF instance is configured with an OSPF process, VRF CA process 100, VRF CB process 200. Now let’s analyze the client’s routers CA1, CA2, CB1, CB2.

CA1# sh ip route ospf
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/3] via 172.31.100.2, 03:34:25, FastEthernet0/0
 172.31.0.0/24 is subnetted, 2 subnets
O 172.31.200.0 [110/2] via 172.31.100.2, 03:34:25, FastEthernet0/0
CA1# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.31.100.2 1 FULL/DR 00:00:33 172.31.100.2 FastEthernet0/0
CA1# ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/21/24 ms
CA1# ping 172.31.200.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.200.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/25/40 ms
CA1#

CA2# sh ip route ospf
 1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/3] via 172.31.200.2, 03:37:33, FastEthernet0/0
 172.31.0.0/24 is subnetted, 2 subnets
O 172.31.100.0 [110/2] via 172.31.200.2, 03:37:33, FastEthernet0/0
CA2# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.31.100.2 1 FULL/DR 00:00:35 172.31.200.2 FastEthernet0/0
CA2# ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/28 ms
CA2# ping 172.31.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
CA2#

 

Over VRF CA, both routers CA1 and CA2 have full reachability to each other and to the ISP’s OSPF running interfaces and we can confirm from the output that we are peering with the ISP router (or else we wouldn’t have anything in the routing table). Let’s examine VRF CB now.

CB1# sh ip route ospf
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/3] via 172.31.100.2, 03:43:31, FastEthernet0/0
 172.31.0.0/24 is subnetted, 2 subnets
O 172.31.200.0 [110/2] via 172.31.100.2, 03:43:31, FastEthernet0/0
CB1# sh ip ospf neighbor 

Neighbor ID Pri State Dead Time Address Interface
172.31.200.2 1 FULL/DR 00:00:31 172.31.100.2 FastEthernet0/0
CB1# ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/24 ms
CB1# ping 172.31.200.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.200.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/32 ms
CB1#

CB2# sh ip route ospf
 1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/3] via 172.31.200.2, 03:52:59, FastEthernet0/0
 172.31.0.0/24 is subnetted, 2 subnets
O 172.31.100.0 [110/2] via 172.31.200.2, 03:52:59, FastEthernet0/0
CB2# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.31.200.2 1 FULL/DR 00:00:34 172.31.200.2 FastEthernet0/0
CB2# ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/29/52 ms
CB2# ping 172.31.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/28 ms
CB2#

 

Confirmed full reachability between all client routers, in each separate VRF, routing tables are properly populated and we are peering with ISP router, zuper!

With this command you have a clear look of which VRF instance is running in which interface.

ISP# sh ip vrf interfaces CA
Interface IP-Address VRF Protocol
Fa0/0 172.31.100.2 CA up 
Fa1/0 172.31.200.2 CA up 
ISP# sh ip vrf interfaces CB
Interface IP-Address VRF Protocol
Fa2/0 172.31.100.2 CB up 
Fa3/0 172.31.200.2 CB up 
ISP#

 

Even with overlapping segments, which is in itself confusing to look at, this command makes it easy to view the interfaces assigned to the different VRF instances. Each VRF instance, CA and CB, are completely unaware of each other, acting like L3 VPNs.

 

Next scenario, found it online which I’ve copied and made a few changes, with a somewhat more complex scenario. We’re separating two VRF’s with transit traffic coming from different VLANs, (10 and 20), classifying them in TRUSTED and UNTRUSTED traffic types, at the edge we have two possible gateways, TRUSTED and UNTRUSTED.

Trusted traffic belongs to VLAN 10 (PURPLE label), and Untrusted traffic belongs to VLAN 20 (RED label). OSPF will be running as the dynamic routing protocol used.

The switches configuration are pretty straight forward. The links connecting to the routers are dot1q trunk links, transporting tagged frames from the appropriate VLANs, and the links attached to the access layer computers are access ports configured in VLANs 10 and 20 respectively. Each SVI (VLAN 10 and VLAN 20), are forwarding traffic for each VRF and the switches are also running OSPF. The client computers are running a mixture of Windows 2012 Server and Windows 2008 Server.

R1, R2 and R3 are connected with trunk links on sub-interfaces, transporting those VLANs and forwarding them to the appropriate VRFs gateways. At the edge we have router’s ER09 which is the gateway to the UNTRUSTED traffic destination, and ETT as gateway for the TRUSTED traffic. Labs are done in GNS3 with the images below:

Routers are running:

R1# sh version 
Cisco IOS Software, 3600 Software (C3640-JK9S-M), Version 12.4(16), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Wed 20-Jun-07 11:43 by prod_rel_team

ROM: ROMMON Emulation Microcode
ROM: 3600 Software (C3640-JK9S-M), Version 12.4(16), RELEASE SOFTWARE (fc1)

 

Switches are running:

SW1# sh version 
Cisco IOS Software, Solaris Software (I86BI_LINUXL2-ADVENTERPRISEK9-M), Experimental Version 15.1(20140814:053243) [mmen 112]
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Thu 14-Aug-14 08:28 by mmen

 

Here is the topology for this lab.

VRF-Lite OSPF Scenario

Note: SRV1 is located on SW1 port e1/0, SRV2 is located on SW1 port e1/1 and SRV3 is located in SW3 port e1/2.

 

Router ER09 configuration.

ER09# en
ER09# conf t
Enter configuration commands, one per line. End with CNTL/Z.
ER09(config)# ip cef
ER09(config)# interface Loopback0
ER09(config-if)# description TO->CLOUD_UNTRUSTED
ER09(config-if)# ip vrf forwarding RED
ER09(config-if)# ip address 93.20.3.254 255.0.0.0
ER09(config)# ip vrf RED
ER09(config-vrf)# description UNTRUSTED_TRAFFIC
ER09(config-vrf)# interface FastEthernet0/0
ER09(config-if)# description TO->R1
ER09(config-if)# ip vrf forwarding RED
ER09(config-if)# ip address 192.168.0.1 255.255.255.252
ER09(config-if)# no shut
ER09(config-if)# router ospf 2 vrf RED
ER09(config-router)# network 192.168.0.0 0.0.255.255 area 0
ER09(config-router)# end
ER09#
*Mar 1 00:44:25.915: %SYS-5-CONFIG_I: Configured from console by console
ER09#
*Mar 1 00:44:27.291: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 1 00:44:28.291: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
ER09#

 

Configuration on edge router ETT.

ETT# conf t
Enter configuration commands, one per line. End with CNTL/Z.
ETT(config)# hostname ETT
ETT(config)# ip cef
ETT(config)# ip vrf PURPLE
ETT(config-vrf)# description TRUSTED_TRAFFIC
ETT(config-vrf)# interface FastEthernet0/0
ETT(config-if)# description TO->R1
ETT(config-if)# ip vrf forwarding PURPLE
ETT(config-if)# ip address 10.0.0.1 255.255.255.252
ETT(config-if)# no shut
ETT(config-if)# interface lo0
ETT(config-if)# ip vrf forwarding PURPLE
ETT(config-if)# description TO->CLOUD_TRUSTED
ETT(config-if)# ip add 148.0.0.1 255.0.0.0
ETT(config-if)# exit
ETT(config)# router ospf 1 vrf PURPLE
ETT(config-router)# router-id 0.0.1.254
ETT(config-router)# network 10.0.0.1 0.0.0.0 area 0
ETT(config-router)# end
*Mar 1 00:00:38.915: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
*Mar 1 00:00:39.191: %SYS-5-CONFIG_I: Configured from console by console
ETT#
*Mar 1 00:00:39.639: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 1 00:00:40.639: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
ETT#

 

Both edge routers are now configured with the VRF instances, interfaces configuration are also assigned to the correct VRFs. OSPF is also configured to run over the correct VRF instances. Now let’s continue with the rest of the configuration. Up next, router’s R2 and R3.

R2# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# hostname R2
R2(config)# ip vrf PURPLE
R2(config-vrf)# description TRUSTED_TRAFFIC
R2(config-vrf)# ip vrf RED
R2(config-vrf)# description UNTRUSTED_TRAFFIC
R2(config-vrf)# interface FastEthernet0/0
R2(config-if)# description TO->R1
R2(config-if)# no ip address
R2(config-if)# no shut
R2(config-if)# interface FastEthernet0/0.10
R2(config-subif)# encapsulation dot1Q 10
R2(config-subif)# ip vrf forwarding PURPLE
R2(config-subif)# ip address 10.0.12.2 255.255.255.252
R2(config-subif)# no shut
R2(config-subif)# interface FastEthernet0/0.20
R2(config-subif)# encapsulation dot1Q 20
R2(config-subif)# ip vrf forwarding RED
R2(config-subif)# ip address 192.168.12.2 255.255.255.252
R2(config-subif)# no shut
R2(config-subif)# interface FastEthernet1/0
R2(config-if)# description TO->R3
R2(config-if)# no ip address
R2(config-if)# no shut
R2(config-if)# interface FastEthernet1/0.10
R2(config-subif)# encapsulation dot1Q 10
R2(config-subif)# ip vrf forwarding PURPLE
R2(config-subif)# ip address 10.0.23.1 255.255.255.252
R2(config-subif)# no shut
R2(config-subif)# interface FastEthernet1/0.20
R2(config-subif)# encapsulation dot1Q 20
R2(config-subif)# ip vrf forwarding RED
R2(config-subif)# ip address 192.168.23.1 255.255.255.252
R2(config-subif)# no shut
R2(config-subif)# interface FastEthernet2/0
R2(config-if)# description TO-SW1
R2(config-if)# no ip address
R2(config-if)# no shut
R2(config-if)# interface FastEthernet2/0.10
R2(config-subif)# encapsulation dot1Q 10
R2(config-subif)# ip vrf forwarding PURPLE
R2(config-subif)# ip address 10.0.1.1 255.255.255.0
R2(config-subif)# no shut
R2(config-subif)# interface FastEthernet2/0.20
R2(config-subif)# encapsulation dot1Q 20
R2(config-subif)# ip vrf forwarding RED
R2(config-subif)# ip address 192.168.1.1 255.255.255.0
R2(config-subif)# no shut
R2(config-subif)# interface FastEthernet3/0
R2(config-if)# description TO->SW2
R2(config-if)# no ip address
R2(config-if)# no shut
R2(config-if)# interface FastEthernet3/0.10
R2(config-subif)# encapsulation dot1Q 10
R2(config-subif)# ip vrf forwarding PURPLE
R2(config-subif)# ip address 10.0.2.1 255.255.255.0
R2(config-subif)# no shut
R2(config-subif)# interface FastEthernet3/0.20
R2(config-subif)# encapsulation dot1Q 20
R2(config-subif)# ip vrf forwarding RED
R2(config-subif)# ip address 192.168.2.1 255.255.255.0
R2(config-subif)# no shut
R2(config-subif)# router ospf 1 vrf PURPLE
R2(config-router)# router-id 0.0.2.1
*Mar 1 00:01:58.747: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 1 00:01:58.999: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 00:01:59.215: %LINK-3-UPDOWN: Interface FastEthernet2/0, changed state to up
*Mar 1 00:01:59.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar 1 00:01:59.999: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
*Mar 1 00:02:00.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to up
R2(config-router)# network 10.0.0.0 0.0.255.255 area 0
R2(config-router)# router ospf 2 vrf RED
R2(config-router)# router-id 0.0.2.2
R2(config-router)# network 192.168.0.0 0.0.255.255 area 0
R2(config-router)# end
R2#
*Mar 1 00:02:01.023: %LINK-3-UPDOWN: Interface FastEthernet3/0, changed state to up
*Mar 1 00:02:02.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up
*Mar 1 00:02:02.239: %SYS-5-CONFIG_I: Configured from console by console
R2#

 

Configuration on R3

R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# hostname R3
R3(config)# ip cef
R3(config)# ip vrf PURPLE
R3(config-vrf)# description TRUSTED_TRAFFIC
R3(config-vrf)# ip vrf RED
R3(config-vrf)# description UNTRUSTED_TRAFFIC
R3(config-vrf)# interface FastEthernet0/0
R3(config-if)# description TO->R1
R3(config-if)# no ip address
R3(config-if)# no shut
R3(config-if)# interface FastEthernet0/0.10
R3(config-subif)# encapsulation dot1Q 10
R3(config-subif)# ip vrf forwarding PURPLE
R3(config-subif)# ip address 10.0.13.2 255.255.255.252
R3(config-subif)# no shut
R3(config-subif)# interface FastEthernet0/0.20
R3(config-subif)# encapsulation dot1Q 20
R3(config-subif)# ip vrf forwarding RED
R3(config-subif)# ip address 192.168.13.2 255.255.255.252
R3(config-subif)# no shut
R3(config-subif)# interface FastEthernet1/0
R3(config-if)# description TO->R2
R3(config-if)# no ip address
R3(config-if)# no shut
R3(config-if)# interface FastEthernet1/0.10
R3(config-subif)# encapsulation dot1Q 10
R3(config-subif)# ip vrf forwarding PURPLE
R3(config-subif)# ip address 10.0.23.2 255.255.255.252
R3(config-subif)# no shut
R3(config-subif)# interface FastEthernet1/0.20
R3(config-subif)# encapsulation dot1Q 20
R3(config-subif)# ip vrf forwarding RED
R3(config-subif)# ip address 192.168.23.2 255.255.255.252
R3(config-subif)# no shut
*Mar 1 00:02:14.055: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 1 00:02:15.055: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar 1 00:02:15.539: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 00:02:16.539: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
R3(config-subif)# interface FastEthernet2/0
R3(config-if)# description TO->SW3
R3(config-if)# no ip address
R3(config-if)# no shut
R3(config-if)# interface FastEthernet2/0.10
R3(config-subif)# encapsulation dot1Q 10
R3(config-subif)# ip vrf forwarding PURPLE
R3(config-subif)# ip address 10.0.3.1 255.255.255.0
R3(config-subif)# no shut
R3(config-subif)# interface FastEthernet2/0.20
R3(config-subif)# encapsulation dot1Q 20
R3(config-subif)# ip vrf forwarding RED
R3(config-subif)# ip address 192.168.3.1 255.255.255.0
R3(config-subif)# no shut
R3(config-subif)# router ospf 1 vrf PURPLE
R3(config-router)# router-id 0.0.3.1
R3(config-router)# network 10.0.0.0 0.0.255.255 area 0
R3(config-router)# router ospf 2 vrf RED
R3(config-router)# router-id 0.0.3.2
R3(config-router)# network 192.168.0.0 0.0.255.255 area 0
R3(config-router)# end
*Mar 1 00:02:23.667: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:02:25.367: %LINK-3-UPDOWN: Interface FastEthernet2/0, changed state to up
*Mar 1 00:02:26.367: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to up
R3#

 

So we have configured R2 and R3’s interfaces, VRF instances, associate the interfaces with the VRF’s instances, OSPF configuration in each VRF instance, trunking with each other, SW1, SW2 and SW3 and R1. Now let’s configure R1 and bring everything up…

 

Configuration on R1.

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# hostname R1
R1(config)# ip cef
R1(config)# ip vrf PURPLE
R1(config-vrf)# description TRUSTED_TRAFFIC
R1(config-vrf)# ip vrf RED
R1(config-vrf)# description UNTRUSTED_TRAFFIC
R1(config-vrf)# interface FastEthernet0/0
R1(config-if)# description TO->CLOUD->EDGE_UNTRUSTED_GUEST_TRAFFIC
R1(config-if)# ip vrf forwarding RED
R1(config-if)# ip address 192.168.0.2 255.255.255.252
R1(config-if)# no shut
R1(config-if)# interface FastEthernet1/0
R1(config-if)# description TO->EDGE_TRUSTED_TRAFFIC
R1(config-if)# ip vrf forwarding PURPLE
R1(config-if)# ip address 10.0.0.2 255.255.255.252
R1(config-if)# no shut
R1(config-if)# interface FastEthernet2/0
R1(config-if)# description TO->R2
R1(config-if)# no ip address
R1(config-if)# no shut
R1(config-if)# interface FastEthernet2/0.10
R1(config-subif)# encapsulation dot1Q 10
R1(config-subif)# ip vrf forwarding PURPLE
R1(config-subif)# ip address 10.0.12.1 255.255.255.252
R1(config-subif)# no shut
R1(config-subif)# interface FastEthernet2/0.20
R1(config-subif)# encapsulation dot1Q 20
R1(config-subif)# ip vrf forwarding RED
R1(config-subif)# ip address 192.168.12.1 255.255.255.252
R1(config-subif)# no shut
R1(config-subif)# interface FastEthernet3/0
R1(config-if)# description TO->R3
R1(config-if)# no ip address
R1(config-if)# no shut
R1(config-if)# interface FastEthernet3/0.10
R1(config-subif)# encapsulation dot1Q 10
R1(config-subif)# ip vrf forwarding PURPLE
*Mar 1 00:01:54.327: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 1 00:01:54.711: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 00:01:55.091: %LINK-3-UPDOWN: Interface FastEthernet2/0, changed state to up
*Mar 1 00:01:55.327: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar 1 00:01:55.711: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
*Mar 1 00:01:56.091: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to up
*Mar 1 00:01:56.571: %LINK-3-UPDOWN: Interface FastEthernet3/0, changed state to up
*Mar 1 00:01:57.571: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up
R1(config-subif)# ip address 10.0.13.1 255.255.255.252
R1(config-subif)# no shut
R1(config-subif)# interface FastEthernet3/0.20
R1(config-subif)# encapsulation dot1Q 20
R1(config-subif)# ip vrf forwarding RED
R1(config-subif)# ip address 192.168.13.1 255.255.255.252
R1(config-subif)# router ospf 1 vrf PURPLE
R1(config-router)# router-id 0.0.1.1
R1(config-router)# network 10.0.0.0 0.0.255.255 area 0
R1(config-router)# default-information originate
R1(config-router)# router ospf 2 vrf RED
R1(config-router)# router-id 0.0.1.2
R1(config-router)# redistribute static metric 10 subnets
R1(config-router)# network 192.168.0.0 0.0.255.255 area 0
R1(config-router)# default-information originate
R1(config-router)# ip route vrf PURPLE 0.0.0.0 0.0.0.0 10.0.0.1
R1(config)# ip route vrf RED 0.0.0.0 0.0.0.0 192.168.0.1
R1(config)# end
*Mar 1 00:01:59.627: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:02:04.703: %OSPF-5-ADJCHG: Process 2, Nbr 192.168.0.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Mar 1 00:02:39.667: %OSPF-5-ADJCHG: Process 1, Nbr 0.0.2.1 on FastEthernet2/0.10 from LOADING to FULL, Loading Done
*Mar 1 00:02:39.667: %OSPF-5-ADJCHG: Process 2, Nbr 0.0.2.2 on FastEthernet2/0.20 from LOADING to FULL, Loading Done
*Mar 1 00:03:19.679: %OSPF-5-ADJCHG: Process 1, Nbr 0.0.3.1 on FastEthernet3/0.10 from LOADING to FULL, Loading Done
*Mar 1 00:03:19.683: %OSPF-5-ADJCHG: Process 2, Nbr 0.0.3.2 on FastEthernet3/0.20 from LOADING to FULL, Loading Done
*Mar 1 00:08:49.671: %OSPF-5-ADJCHG: Process 1, Nbr 0.0.1.254 on FastEthernet1/0 from LOADING to FULL, Loading Done
R1#

 

And now for the switches configuration. I’ll show you how to configure SW1. SW2 and SW3 have similar configuration, obviously. Pretty straight forward!

SW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)# ip vrf PURPLE
SW1(config-vrf)# description TRUSTED_TRAFFIC
SW1(config-vrf)# ip vrf RED
SW1(config-vrf)# description UNTRUSTED_TRAFFIC
SW1(config-vrf)# ip cef
SW1(config)# interface Ethernet0/0
SW1(config-if)# description TO->R2
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# duplex full
SW1(config-if)# no shut
SW1(config-if)# interface Ethernet1/0
SW1(config-if)# switchport access vlan 10
SW1(config-if)# switchport mode access
SW1(config-if)# switchport port-security maximum 3
SW1(config-if)# switchport port-security violation restrict
SW1(config-if)# switchport port-security mac-address sticky
SW1(config-if)# duplex full
SW1(config-if)# spanning-tree portfast
SW1(config-if)# no shut
SW1(config-if)# interface Ethernet1/1
SW1(config-if)# switchport access vlan 10
SW1(config-if)# switchport mode access
SW1(config-if)# switchport port-security maximum 3
SW1(config-if)# switchport port-security violation restrict
SW1(config-if)# switchport port-security mac-address sticky
SW1(config-if)# duplex full
SW1(config-if)# spanning-tree portfast
SW1(config-if)# no shut
SW1(config-if)# interface Ethernet1/2
SW1(config-if)# switchport access vlan 20
SW1(config-if)# switchport mode access
SW1(config-if)# switchport port-security maximum 3
SW1(config-if)# switchport port-security violation restrict
SW1(config-if)# switchport port-security mac-address sticky
SW1(config-if)# duplex full
SW1(config-if)# spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION

%Portfast has been configured on Ethernet1/2 but will only
 have effect when the interface is in a non-trunking mode.
SW1(config-if)# no shut
SW1(config-if)# interface Vlan1
SW1(config-if)# no ip address
SW1(config-if)# shutdown
SW1(config-if)# interface Vlan10
SW1(config-if)# description TRUSTED_TRAFFIC
SW1(config-if)# ip vrf forwarding PURPLE
SW1(config-if)# ip address 10.0.1.10 255.255.255.0
SW1(config-if)# no shut
SW1(config-if)# interface Vlan20
SW1(config-if)# description UNTRUSTED_TRAFFIC
SW1(config-if)# ip vrf forwarding RED
SW1(config-if)# ip address 192.168.1.10 255.255.255.0
SW1(config-if)# no shut
*May 24 08:26:23.384: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Ethernet0/0 (not full duplex), with R2 FastEthernet2/0 (full duplex). 
SW1(config-if)# router ospf 1 vrf PURPLE
SW1(config-router)# router-id 0.0.1.10
SW1(config-router)# network 10.0.1.0 0.0.0.255 area 0
SW1(config-router)# router ospf 2 vrf RED
SW1(config-router)# router-id 0.0.1.20
SW1(config-router)# network 192.168.1.10 0.0.0.0 area 0
SW1(config-router)# end
SW1#
*May 24 08:18:04.429: %LINK-5-CHANGED: Interface Vlan1, changed state to administratively down
*May 24 08:18:04.492: %LINK-3-UPDOWN: Interface Vlan10, changed state to up
*May 24 08:18:05.497: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
SW1#
*May 24 08:26:26.193: %LINK-3-UPDOWN: Interface Ethernet1/1, changed state to up
*May 24 08:26:27.193: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/1, changed state to up
*May 24 08:18:37.433: %LINK-3-UPDOWN: Interface Vlan20, changed state to up
*May 24 08:18:38.434: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan20, changed state to up
SW1#
*May 24 08:18:41.451: %OSPF-5-ADJCHG: Process 2, Nbr 0.0.2.2 on Vlan20 from LOADING to FULL, Loading Done
SW1#
*May 24 08:18:49.151: %OSPF-5-ADJCHG: Process 1, Nbr 0.0.2.1 on Vlan10 from LOADING to FULL, Loading Done
SW1#

 

Now I’ll add one server’s network configuration. This server is attached to SW1 on access port e1/0 which belongs to VLAN 10 (TRUSTED traffic), so after configuration I’ll try to test reachability to the 148.0.0.0/8 segment which is simulating a internet network. We expect this traffic to flow through and only through VRF PURPLE.

Windows PowerShell
Copyright (C) 2013 Microsoft Corporation. All rights reserved.
PS C:\Users\Administrator> netsh interface ip set address "Ethernet" static 10.0.1.100 255.255.255.0 10.0.1.1
PS C:\Users\Administrator> ipconfig

Windows IP Configuration

Ethernet adapter Ethernet:

Connection-specific DNS Suffix . :
 IPv4 Address. . . . . . . . . . . : 10.0.1.100
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 10.0.1.1

Tunnel adapter isatap.{648B2449-4FCD-428E-9370-D56726EE2ED9}:

Media State . . . . . . . . . . . : Media disconnected
 Connection-specific DNS Suffix . :
PS C:\Users\Administrator> ping 148.0.0.1

Pinging 148.0.0.1 with 32 bytes of data:
Reply from 148.0.0.1: bytes=32 time=35ms TTL=253
Reply from 148.0.0.1: bytes=32 time=26ms TTL=253
Reply from 148.0.0.1: bytes=32 time=32ms TTL=253
Reply from 148.0.0.1: bytes=32 time=28ms TTL=253

Ping statistics for 148.0.0.1:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 26ms, Maximum = 35ms, Average = 30ms
PS C:\Users\Administrator> tracert -d 148.0.0.1

Tracing route to 148.0.0.1 over a maximum of 30 hops

1 9 ms 11 ms 9 ms 10.0.1.1
 2 24 ms 19 ms 19 ms 10.0.12.1
 3 27 ms 31 ms 28 ms 148.0.0.1

Trace complete.
PS C:\Users\Administrator> ping 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.

Ping statistics for 192.168.0.1:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
PS C:\Users\Administrator>

 

We have SW1 with full reachability throughout the network. I’ll go through some verification commands in a second but first let’s analyse the server here.

We added the server to the VLAN 10 segment with IP 10.0.1.100/24, after that we tried reaching the loopback interface of ETT router at 148.0.0.1 (PURPLE), which we did successfuly, I also issued a traceroute so we can clearly see the path to the destination network. We are routing through R2 which is directly attached to SW1 with IP 10.0.1.1, the following hop is R1’s fa2/0.10 interface with IP 10.0.12.1 and we finally reached 10.0.0.1 which is ETT’s f0/0 interface, but noticed how are not able to reach the (RED) 192.168.0.0/24 segment?

Yes, that’s because they are completely separated routing tables, just as if they are connected to different routers! We received a destination unreachable message from the gateway 10.0.0.1 which is the ETT router (PURPLE gateway), directly connected to R1 stating (there is no connection to that IP address your requesting). Zuper!

 

All routers are now configured and we can already observe the OSPF adjacencies coming up. Noticed that I have configured a default route and injected it into OSPF on each VRF instance? Yep, again, each VRF operates with it’s own IP routing table so as these are edge routers, you need to configure a default route on each VRF instance to forward traffic accordingly. Remember that each VRF instance acts as a virtual router/VPN with their own independent and separated IP routing table.

Let’s shoot some verification commands and check if everything is correct.

R1# sh ip vrf interfaces 
Interface IP-Address VRF Protocol
Fa1/0 10.0.0.2 PURPLE up 
Fa2/0.10 10.0.12.1 PURPLE up 
Fa3/0.10 10.0.13.1 PURPLE up 
Fa0/0 192.168.0.2 RED up 
Fa2/0.20 192.168.12.1 RED up 
Fa3/0.20 192.168.13.1 RED up 
R1# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
0.0.3.2 1 FULL/DR 00:00:31 192.168.13.2 FastEthernet3/0.20
0.0.2.2 1 FULL/DR 00:00:35 192.168.12.2 FastEthernet2/0.20
192.168.0.1 1 FULL/DR 00:00:30 192.168.0.1 FastEthernet0/0
0.0.3.1 1 FULL/DR 00:00:31 10.0.13.2 FastEthernet3/0.10
0.0.2.1 1 FULL/DR 00:00:35 10.0.12.2 FastEthernet2/0.10
0.0.1.254 1 FULL/DR 00:00:30 10.0.0.1 FastEthernet1/0
R1# sh ip route vrf PURPLE ospf

Routing Table: PURPLE

 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O 10.0.2.0/24 [110/2] via 10.0.12.2, 01:21:35, FastEthernet2/0.10
O 10.0.3.0/24 [110/2] via 10.0.13.2, 01:21:35, FastEthernet3/0.10
O 10.0.1.0/24 [110/2] via 10.0.12.2, 01:21:35, FastEthernet2/0.10
O 10.0.23.0/30 [110/2] via 10.0.13.2, 01:21:35, FastEthernet3/0.10
 [110/2] via 10.0.12.2, 01:21:35, FastEthernet2/0.10
 148.0.0.0/32 is subnetted, 1 subnets
O 148.0.0.1 [110/2] via 10.0.0.1, 01:21:35, FastEthernet1/0
R1#
R1# sh ip route vrf RED ospf 

Routing Table: RED

 192.168.23.0/30 is subnetted, 1 subnets
O 192.168.23.0 [110/2] via 192.168.13.2, 01:27:14, FastEthernet3/0.20
 [110/2] via 192.168.12.2, 01:27:14, FastEthernet2/0.20
O 192.168.1.0/24 [110/2] via 192.168.12.2, 01:27:14, FastEthernet2/0.20
O 192.168.2.0/24 [110/2] via 192.168.12.2, 01:27:14, FastEthernet2/0.20
O 192.168.3.0/24 [110/2] via 192.168.13.2, 01:27:14, FastEthernet3/0.20
R1#

R1# sh ip vrf detail 
VRF PURPLE; default RD <not set>; default VPNID <not set>
 Description: TRUSTED_TRAFFIC
 Interfaces:
 Fa1/0 Fa2/0.10 Fa3/0.10
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
VRF RED; default RD <not set>; default VPNID <not set>
 Description: UNTRUSTED_TRAFFIC
 Interfaces:
 Fa0/0 Fa2/0.20 Fa3/0.20
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
R1#

 

Verification commands on R2

R2# sh ip vrf interfaces 
Interface IP-Address VRF Protocol
Fa0/0.10 10.0.12.2 PURPLE up 
Fa1/0.10 10.0.23.1 PURPLE up 
Fa2/0.10 10.0.1.1 PURPLE up 
Fa3/0.10 10.0.2.1 PURPLE up 
Fa0/0.20 192.168.12.2 RED up 
Fa1/0.20 192.168.23.1 RED up 
Fa2/0.20 192.168.1.1 RED up 
Fa3/0.20 192.168.2.1 RED up 
R2# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
0.0.1.20 1 FULL/BDR 00:00:38 192.168.1.10 FastEthernet2/0.20
0.0.3.2 1 FULL/DR 00:00:33 192.168.23.2 FastEthernet1/0.20
0.0.1.2 1 FULL/BDR 00:00:37 192.168.12.1 FastEthernet0/0.20
0.0.1.10 1 FULL/BDR 00:00:31 10.0.1.10 FastEthernet2/0.10
0.0.3.1 1 FULL/DR 00:00:33 10.0.23.2 FastEthernet1/0.10
0.0.1.1 1 FULL/BDR 00:00:37 10.0.12.1 FastEthernet0/0.10
R2# sh ip route vrf PURPLE ospf

Routing Table: PURPLE

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O 10.0.13.0/30 [110/2] via 10.0.23.2, 02:31:53, FastEthernet1/0.10
 [110/2] via 10.0.12.1, 02:31:53, FastEthernet0/0.10
O 10.0.3.0/24 [110/2] via 10.0.23.2, 02:31:53, FastEthernet1/0.10
O 10.0.0.0/30 [110/2] via 10.0.12.1, 02:31:53, FastEthernet0/0.10
 148.0.0.0/32 is subnetted, 1 subnets
O 148.0.0.1 [110/3] via 10.0.12.1, 02:31:53, FastEthernet0/0.10
O*E2 0.0.0.0/0 [110/1] via 10.0.12.1, 02:31:53, FastEthernet0/0.10
R2# sh ip route vrf RED ospf

Routing Table: RED

192.168.13.0/30 is subnetted, 1 subnets
O 192.168.13.0 [110/2] via 192.168.23.2, 02:32:04, FastEthernet1/0.20
 [110/2] via 192.168.12.1, 02:32:04, FastEthernet0/0.20
 192.168.0.0/30 is subnetted, 1 subnets
O 192.168.0.0 [110/2] via 192.168.12.1, 02:32:04, FastEthernet0/0.20
O 192.168.3.0/24 [110/2] via 192.168.23.2, 02:32:04, FastEthernet1/0.20
O*E2 0.0.0.0/0 [110/1] via 192.168.12.1, 02:32:04, FastEthernet0/0.20
R2# sh ip vrf detail
VRF PURPLE; default RD <not set>; default VPNID <not set>
 Description: TRUSTED_TRAFFIC
 Interfaces:
 Fa0/0.10 Fa1/0.10 Fa2/0.10
 Fa3/0.10 
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
VRF RED; default RD <not set>; default VPNID <not set>
 Description: UNTRUSTED_TRAFFIC
 Interfaces:
 Fa0/0.20 Fa1/0.20 Fa2/0.20
 Fa3/0.20 
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
R2#

 

Verification commands on R3

R3# sh ip vrf interfaces 
Interface IP-Address VRF Protocol
Fa0/0.10 10.0.13.2 PURPLE up 
Fa1/0.10 10.0.23.2 PURPLE up 
Fa2/0.10 10.0.3.1 PURPLE up 
Fa0/0.20 192.168.13.2 RED up 
Fa1/0.20 192.168.23.2 RED up 
Fa2/0.20 192.168.3.1 RED up 
R3# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
0.0.2.2 1 FULL/BDR 00:00:33 192.168.23.1 FastEthernet1/0.20
0.0.1.2 1 FULL/BDR 00:00:33 192.168.13.1 FastEthernet0/0.20
0.0.2.1 1 FULL/BDR 00:00:33 10.0.23.1 FastEthernet1/0.10
0.0.1.1 1 FULL/BDR 00:00:33 10.0.13.1 FastEthernet0/0.10
R3# sh ip route vrf RED ospf

Routing Table: RED

192.168.12.0/30 is subnetted, 1 subnets
O 192.168.12.0 [110/2] via 192.168.23.1, 02:39:56, FastEthernet1/0.20
 [110/2] via 192.168.13.1, 02:39:56, FastEthernet0/0.20
 192.168.0.0/30 is subnetted, 1 subnets
O 192.168.0.0 [110/2] via 192.168.13.1, 02:39:56, FastEthernet0/0.20
O 192.168.1.0/24 [110/2] via 192.168.23.1, 02:39:56, FastEthernet1/0.20
O 192.168.2.0/24 [110/2] via 192.168.23.1, 02:39:56, FastEthernet1/0.20
O*E2 0.0.0.0/0 [110/1] via 192.168.13.1, 02:39:56, FastEthernet0/0.20
R3# sh ip route vrf PURPLE ospf

Routing Table: PURPLE

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O 10.0.12.0/30 [110/2] via 10.0.23.1, 02:39:54, FastEthernet1/0.10
 [110/2] via 10.0.13.1, 02:39:54, FastEthernet0/0.10
O 10.0.2.0/24 [110/2] via 10.0.23.1, 02:39:54, FastEthernet1/0.10
O 10.0.0.0/30 [110/2] via 10.0.13.1, 02:39:54, FastEthernet0/0.10
O 10.0.1.0/24 [110/2] via 10.0.23.1, 02:39:54, FastEthernet1/0.10
 148.0.0.0/32 is subnetted, 1 subnets
O 148.0.0.1 [110/3] via 10.0.13.1, 02:39:54, FastEthernet0/0.10
O*E2 0.0.0.0/0 [110/1] via 10.0.13.1, 02:39:54, FastEthernet0/0.10
R3# sh ip vrf detail 
VRF PURPLE; default RD <not set>; default VPNID <not set>
 Description: TRUSTED_TRAFFIC
 Interfaces:
 Fa0/0.10 Fa1/0.10 Fa2/0.10
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
VRF RED; default RD <not set>; default VPNID <not set>
 Description: UNTRUSTED_TRAFFIC
 Interfaces:
 Fa0/0.20 Fa1/0.20 Fa2/0.20
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
R3#

 

Verification commands on edge router ER09. Obviously there is only one VRF configured for this router as it is purposely used for UNTRUSTED (RED) traffic flows.

ER09# sh ip vrf interfaces 
Interface IP-Address VRF Protocol
Fa0/0 192.168.0.1 RED up 
ER09# sh ip route vrf RED ospf

Routing Table: RED

192.168.12.0/30 is subnetted, 1 subnets
O 192.168.12.0 [110/2] via 192.168.0.2, 02:46:06, FastEthernet0/0
 192.168.13.0/30 is subnetted, 1 subnets
O 192.168.13.0 [110/2] via 192.168.0.2, 02:46:06, FastEthernet0/0
 192.168.23.0/30 is subnetted, 1 subnets
O 192.168.23.0 [110/3] via 192.168.0.2, 02:46:06, FastEthernet0/0
O 192.168.1.0/24 [110/3] via 192.168.0.2, 02:46:06, FastEthernet0/0
O 192.168.2.0/24 [110/3] via 192.168.0.2, 02:46:06, FastEthernet0/0
O 192.168.3.0/24 [110/3] via 192.168.0.2, 02:46:06, FastEthernet0/0
ER09# sh ip vrf detail 
VRF RED; default RD <not set>; default VPNID <not set>
 Description: UNTRUSTED_TRAFFIC
 Interfaces:
 Fa0/0 
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
ER09# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
0.0.1.2 1 FULL/BDR 00:00:33 192.168.0.2 FastEthernet0/0
ER09#

 

Verification commands on edge router ETT and again, as this is the router purposely configured for TRUSTED (PURPLE) traffic flows, it only has one VRF configured.

ETT# sh ip vrf interfaces 
Interface IP-Address VRF Protocol
Lo0 148.0.0.1 PURPLE up 
Fa0/0 10.0.0.1 PURPLE up 
ETT# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
0.0.1.1 1 FULL/BDR 00:00:39 10.0.0.2 FastEthernet0/0
ETT# sh ip route vrf PURPLE ospf

Routing Table: PURPLE

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O 10.0.12.0/30 [110/2] via 10.0.0.2, 02:51:00, FastEthernet0/0
O 10.0.13.0/30 [110/2] via 10.0.0.2, 02:51:00, FastEthernet0/0
O 10.0.2.0/24 [110/3] via 10.0.0.2, 02:51:00, FastEthernet0/0
O 10.0.3.0/24 [110/3] via 10.0.0.2, 02:51:00, FastEthernet0/0
O 10.0.1.0/24 [110/3] via 10.0.0.2, 02:51:00, FastEthernet0/0
O 10.0.23.0/30 [110/3] via 10.0.0.2, 02:51:00, FastEthernet0/0
ETT# sh ip vrf detail
VRF PURPLE; default RD <not set>; default VPNID <not set>
 Description: TRUSTED_TRAFFIC
 Interfaces:
 Lo0 Fa0/0 
 Connected addresses are not in global routing table
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No export route-map
 VRF label distribution protocol: not configured
ETT#

 

Verification commands on SW1. Notice that all switches have the same basic configuration. Two switchports accessing VLAN 10, and one switchports accessing VLAN 20 and one uplink trunk carrying traffic from those VLANs, RED and PURPLE.

SW1# sh ip vrf interfaces 
Interface IP-Address VRF Protocol
Vl10 10.0.1.10 PURPLE up 
Vl20 192.168.1.10 RED up 
SW1# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
0.0.2.2 1 FULL/DR 00:00:36 192.168.1.1 Vlan20
0.0.2.1 1 FULL/DR 00:00:36 10.0.1.1 Vlan10
SW1# sh ip route vrf RED ospf

Routing Table: RED
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

O*E2 0.0.0.0/0 [110/1] via 192.168.1.1, 02:56:52, Vlan20
 192.168.0.0/30 is subnetted, 1 subnets
O 192.168.0.0 [110/3] via 192.168.1.1, 02:56:52, Vlan20
O 192.168.2.0/24 [110/2] via 192.168.1.1, 02:56:52, Vlan20
O 192.168.3.0/24 [110/3] via 192.168.1.1, 02:56:52, Vlan20
 192.168.12.0/30 is subnetted, 1 subnets
O 192.168.12.0 [110/2] via 192.168.1.1, 02:56:52, Vlan20
 192.168.13.0/30 is subnetted, 1 subnets
O 192.168.13.0 [110/3] via 192.168.1.1, 02:56:52, Vlan20
 192.168.23.0/30 is subnetted, 1 subnets
O 192.168.23.0 [110/2] via 192.168.1.1, 02:56:52, Vlan20
SW1# sh ip route vrf PURPLE ospf

Routing Table: PURPLE
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override

Gateway of last resort is 10.0.1.1 to network 0.0.0.0

O*E2 0.0.0.0/0 [110/1] via 10.0.1.1, 02:56:48, Vlan10
 10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks
O 10.0.0.0/30 [110/3] via 10.0.1.1, 02:56:48, Vlan10
O 10.0.2.0/24 [110/2] via 10.0.1.1, 02:56:48, Vlan10
O 10.0.3.0/24 [110/3] via 10.0.1.1, 02:56:48, Vlan10
O 10.0.12.0/30 [110/2] via 10.0.1.1, 02:56:48, Vlan10
O 10.0.13.0/30 [110/3] via 10.0.1.1, 02:56:48, Vlan10
O 10.0.23.0/30 [110/2] via 10.0.1.1, 02:56:48, Vlan10
 148.0.0.0/32 is subnetted, 1 subnets
O 148.0.0.1 [110/4] via 10.0.1.1, 02:56:48, Vlan10
SW1# sh ip vrf detail
VRF PURPLE (VRF Id = 1); default RD <not set>; default VPNID <not set>
 Description: TRUSTED_TRAFFIC
 Interfaces:
 Vl10 
VRF Table ID = 1
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No global export route-map
 No export route-map
 VRF label distribution protocol: not configured
 VRF label allocation mode: per-prefix

VRF RED (VRF Id = 2); default RD <not set>; default VPNID <not set>
 Description: UNTRUSTED_TRAFFIC
 Interfaces:
 Vl20 
VRF Table ID = 2
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No global export route-map
 No export route-map
 VRF label distribution protocol: not configured
 VRF label allocation mode: per-prefix

SW1# sh interfaces trunk 

Port Mode Encapsulation Status Native vlan
Et0/0 on 802.1q trunking 1

Port Vlans allowed on trunk
Et0/0 1-4094

Port Vlans allowed and active in management domain
Et0/0 1,10,20

Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20
SW1# sh interfaces e1/0 switchport 
Name: Et1/0
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 (VRF_PURPLE_TRUSTED_TRAFFIC)
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 associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Appliance trust: none
SW1# sh interfaces e1/2 switchport 
Name: Et1/2
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: 20 (VRF_RED_UNTRUSTED_TRAFFIC)
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 associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Appliance trust: none
SW1#

 

For the sake of the example, I’ll configure SW3 and Server3. Then go through the same verification commands and test reachability!

SW3# conf t
SW3(config)# hostname SW3
SW3(config)# ip vrf PURPLE
SW3(config-vrf)# description TRUSTED_TRAFFIC
SW3(config-vrf)# ip vrf RED
SW3(config-vrf)# description UNTRUSTED_TRAFFIC
SW3(config-vrf)# ip cef
SW3(config)# interface Ethernet0/0
SW3(config-if)# description TO->R3
SW3(config-if)# switchport trunk encapsulation dot1q
SW3(config-if)# switchport mode trunk
SW3(config-if)# no shut
SW3(config-if)# interface Ethernet1/0
SW3(config-if)# switchport access vlan 10
SW3(config-if)# switchport mode access
SW3(config-if)# switchport port-security maximum 3
SW3(config-if)# switchport port-security violation restrict
SW3(config-if)# switchport port-security mac-address sticky
SW3(config-if)# spanning-tree portfast
SW3(config-if)# no shut
SW3(config-if)# interface Ethernet1/1
SW3(config-if)# switchport access vlan 10
SW3(config-if)# switchport mode access
SW3(config-if)# switchport port-security maximum 3
SW3(config-if)# switchport port-security violation restrict
SW3(config-if)# switchport port-security mac-address sticky
SW3(config-if)# spanning-tree portfast
SW3(config-if)# no shut
SW3(config-if)# interface Ethernet1/2
SW3(config-if)# description TO->VLAN20_SRV3
SW3(config-if)# switchport access vlan 20
SW3(config-if)# switchport mode access
SW3(config-if)# switchport port-security maximum 3
SW3(config-if)# switchport port-security violation restrict
SW3(config-if)# switchport port-security mac-address sticky
SW3(config-if)# spanning-tree portfast
SW3(config-if)# no shut
SW3(config-if)# interface Vlan1
SW3(config-if)# no ip address
SW3(config-if)# shutdown
SW3(config-if)# interface Vlan10
SW3(config-if)# description TRUSTED_TRAFFIC
SW3(config-if)# ip vrf forwarding PURPLE
SW3(config-if)# ip address 10.0.3.10 255.255.255.0
SW3(config-if)# no shut
SW3(config-if)# interface Vlan20
SW3(config-if)# description UNTRUSTED_TRAFFIC
SW3(config-if)# ip vrf forwarding RED
SW3(config-if)# ip address 192.168.3.10 255.255.255.0
SW3(config-if)# no shut
SW3(config-if)# router ospf 1 vrf PURPLE
SW3(config-router)# router-id 0.0.3.10
SW3(config-router)# network 10.0.3.0 0.0.0.255 area 0
SW3(config-router)# router ospf 2 vrf RED
SW3(config-router)# router-id 0.0.3.20
SW3(config-router)# network 192.168.3.10 0.0.0.0 area 0
SW3(config-router)# end
SW3# sh ip vrf interfaces 
Interface IP-Address VRF Protocol
Vl10 10.0.3.10 PURPLE up 
Vl20 192.168.3.10 RED up 
SW3# sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
0.0.3.2 1 FULL/DR 00:00:38 192.168.3.1 Vlan20
0.0.3.1 1 FULL/DR 00:00:38 10.0.3.1 Vlan10
SW3# sh ip route vrf RED ospf

Routing Table: RED
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override

Gateway of last resort is 192.168.3.1 to network 0.0.0.0

O*E2 0.0.0.0/0 [110/1] via 192.168.3.1, 00:53:13, Vlan20
 192.168.0.0/30 is subnetted, 1 subnets
O 192.168.0.0 [110/3] via 192.168.3.1, 00:53:13, Vlan20
O 192.168.1.0/24 [110/3] via 192.168.3.1, 00:53:13, Vlan20
O 192.168.2.0/24 [110/3] via 192.168.3.1, 00:53:13, Vlan20
 192.168.12.0/30 is subnetted, 1 subnets
O 192.168.12.0 [110/3] via 192.168.3.1, 00:53:13, Vlan20
 192.168.13.0/30 is subnetted, 1 subnets
O 192.168.13.0 [110/2] via 192.168.3.1, 00:53:13, Vlan20
 192.168.23.0/30 is subnetted, 1 subnets
O 192.168.23.0 [110/2] via 192.168.3.1, 00:53:13, Vlan20
SW3# sh ip route vrf PURPLE ospf

Routing Table: PURPLE
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override

Gateway of last resort is 10.0.3.1 to network 0.0.0.0

O*E2 0.0.0.0/0 [110/1] via 10.0.3.1, 00:53:17, Vlan10
 10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks
O 10.0.0.0/30 [110/3] via 10.0.3.1, 00:32:17, Vlan10
O 10.0.1.0/24 [110/3] via 10.0.3.1, 00:53:17, Vlan10
O 10.0.2.0/24 [110/3] via 10.0.3.1, 00:53:17, Vlan10
O 10.0.12.0/30 [110/3] via 10.0.3.1, 00:53:17, Vlan10
O 10.0.13.0/30 [110/2] via 10.0.3.1, 00:53:17, Vlan10
O 10.0.23.0/30 [110/2] via 10.0.3.1, 00:53:17, Vlan10
SW3# sh ip vrf detail
VRF PURPLE (VRF Id = 1); default RD <not set>; default VPNID <not set>
 Description: TRUSTED_TRAFFIC
 Interfaces:
 Vl10 
VRF Table ID = 1
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No global export route-map
 No export route-map
 VRF label distribution protocol: not configured
 VRF label allocation mode: per-prefix

VRF RED (VRF Id = 2); default RD <not set>; default VPNID <not set>
 Description: UNTRUSTED_TRAFFIC
 Interfaces:
 Vl20 
VRF Table ID = 2
 No Export VPN route-target communities
 No Import VPN route-target communities
 No import route-map
 No global export route-map
 No export route-map
 VRF label distribution protocol: not configured
 VRF label allocation mode: per-prefix

SW3# sh interfaces trunk 

Port Mode Encapsulation Status Native vlan
Et0/0 on 802.1q trunking 1

Port Vlans allowed on trunk
Et0/0 1-4094

Port Vlans allowed and active in management domain
Et0/0 1,10,20

Port Vlans in spanning tree forwarding state and not pruned
Et0/0 1,10,20
SW3# sh interfaces e1/2 switchport
Name: Et1/2
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: 20 (VRF_RED_UNTRUSTED_TRAFFIC)
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 associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Appliance trust: none
SW3#

 

Configuration of SRV3 network interface.

Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator> netsh interface ip set address "LAN" static 192.168.3.130 255.255.255.0 192.168.3.1

PS C:\Users\Administrator> ipconfig

Windows IP Configuration

Ethernet adapter LAN:

 Connection-specific DNS Suffix . :
 IPv4 Address. . . . . . . . . . . : 192.168.3.130
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 192.168.3.1

Tunnel adapter isatap.{CD0694F2-207E-4BA4-ABF0-03E073597FAD}:

 Media State . . . . . . . . . . . : Media disconnected
 Connection-specific DNS Suffix . :
PS C:\Users\Administrator> ping 93.20.3.254

Pinging 93.20.3.254 with 32 bytes of data:
Reply from 93.20.3.254: bytes=32 time=55ms TTL=253
Reply from 93.20.3.254: bytes=32 time=43ms TTL=253
Reply from 93.20.3.254: bytes=32 time=44ms TTL=253
Reply from 93.20.3.254: bytes=32 time=38ms TTL=253

Ping statistics for 93.20.3.254:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 38ms, Maximum = 55ms, Average = 45ms
PS C:\Users\Administrator> tracert -d 93.20.3.254

Tracing route to 93.20.3.254 over a maximum of 30 hops

 1 3 ms 10 ms 10 ms 192.168.3.1
 2 26 ms 20 ms 21 ms 192.168.13.1
 3 43 ms 42 ms 41 ms 93.20.3.254

Trace complete.
PS C:\Users\Administrator> ping 148.0.0.1

Pinging 148.0.0.1 with 32 bytes of data:
Reply from 192.168.0.1: Destination host unreachable.
Reply from 192.168.0.1: Destination host unreachable.
Reply from 192.168.0.1: Destination host unreachable.
Reply from 192.168.0.1: Destination host unreachable.

Ping statistics for 148.0.0.1:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
PS C:\Users\Administrator>

 

So let’s sum it up, I’ve configured SW3 in the network with the same VLANs and appropriate VRFs (RED and PURPLE). SW3’s e1/2 switchport is configured to accept traffic from SRV3 only on VLAN 20 (VRF RED – UNTRUSTED traffic), and flow throughout the network on VRF RED UNTRUSTED Traffic only! We can confirm this with the traceroute command. SRV3 is flowing out of VLAN 20 through R3 VRF RED f2/0.20 interface with IP 192.168.3.1, it exits R3 to R1’s f3/0.20 with IP 192.168.13.1 and R1 uses the static default route from VRF RED IP routing table to flow the packets to the destination address 93.20.3.254, in this case router ER09 loopback 0.

When we try reachability to the 148.0.0.1 network, which is the loopback inerface configured on router ETT, (the default gateway to VRF PURPLE), the traffic is just dropped and we get the message from ER09 router, the gateway from VRF RED.

 

Looks like we have exactly what we wanted. Complete segmentation of the different types of traffic patterns. This is the very basic of VRF Lite. I’ll get back with more labs on VRFs later on another post.

Hope this helps someone else.

Advertisements

CCNP ROUTE 300-101 Part 1.0 – Network Principles

In its basic essence, Cisco Express Forwarding (CEF), is a feature that allows a router
to quickly and efficiently make a route lookup.

 

Cisco Express Forwarding

CEF is an optimized Layer 3 forwarding path through a router or switch. CEF optimizes routing table lookup by creating a special, easily searched tree structure based on the IP routing table. The forwarding information is called the Forwarding Information Base (FIB), and the cached adjacency information is called the Adjacency Table.

 

A lot of sources on router architecture divides router functions into three operational planes:

  • Management plane: is concerned with the management of the device. For example, an administrator connecting to a router through a Secure Shell (SSH) connection through one of the router’s VTY lines would be a management plane operation.
  • Control plane: is concerned with making packet-forwarding decisions. For example, routing protocol operation would be a control plane function. (the brain of the network)
  • Data plane: is concerned with the forwarding of data through a router (ASIC). For example, end-user traffic traveling from a user’s PC to a web server on a different network would go across the data plane. (means the hardware itself)

 

Data plane and control plane are the two planes that most directly impact how quickly packets can flow through a router. We will consider these two planes of operation and examine three different approaches that Cisco routers can take to forward packets arriving on an ingress interface and being sent out an appropriate egress interface – Packet Switching.

 

Note: Many people have a challenge with the term packet switching, because they think of Layer 2 operation, while routing being a Layer 3 operation. The key to understanding this term is to think of “Frame Switching” being Layer 2, while “Packet Switching” (routing) Layer 3 operation.

 

Cisco routers support the following three primary modes of packet switching:

  • Process switching
  • Fast switching
  • Cisco Express Forwarding (CEF)

 

Process Switching

When a router routes a packet (that is, performs packet switching), the router removes the packet’s Layer 2 header, examines the Layer 3 addressing, and decides how to forward the packet. The Layer 2 header is then rewritten (changing the source and destination MAC addresses and computing a new CRC), and the packet is forwarded out an appropriate interface. With process switching, as shown below, a router’s CPU becomes directly involved with packet-switching decisions. As a result, the performance of a router configured for process switching can suffer significantly.

packet switching

Note:  An interface can be configured for process switching by disabling fast switching on that interface. The command used to disable fast switching is:

R1(config)# no ip route-cache

 

Fast Switching

Fast switching uses a fast cache maintained in a router’s data plane (hardware). The fast cache contains information about how traffic from different data flows should be forwarded. As seen below, the first packet in a data flow is process switched by a router’s CPU.

After the router determines how to forward the first frame of a data flow, the forwarding information is stored in the fast cache. Subsequent packets in that same data flow are
forwarded based on information in the fast cache, as opposed to being process switched.
As a result, fast switching dramatically reduces a router’s CPU utilization, as compared to
process switching.

fast switching

Fast switching can be configured in interface configuration mode with the command:

R1(config-if)# ip route-cache

 

Cisco Express Forwarding

CEF maintains two tables in the data plane (forwarding plane). The Forwarding Information Base (FIB) maintains Layer 3 forwarding information, whereas the Adjacency table maintains Layer 2 information for next hops listed in the FIB.

Using these tables, populated from a router’s IP routing table and ARP cache, CEF can efficiently make forwarding decisions. CEF does not require the first packet of a data flow to be process switched, like fast switching. Rather, an entire data flow can be forwarded at the data plane, as seen below.

CEF

On many platforms, CEF is enabled by default. If it is not, you can globally enable
it with the following command:

R1(config)# ip cef

Alternately, if CEF is enabled globally but is not enabled on a specific interface, you can enable it on that interface with interface configuration command

R1(config-if)# ip route-cache cef

 

CEF Configuration and Verification

Enable CEF globaly

R1(config)# ip cef

 

Enable CEF on an interface (if CEF is globally enabled), in interface mode

R1(config-if)# ip route-cache cef

 

Verify multiple interface statistics, including information about an interface’s packet-switching mode.

R1# show ip interface fa0/0

 

Verify the contents of a router’s FIB.

R1# show ip cef

 

Verify information contained in the adjacency table of a router, including protocol and timer information.

R1# show adjacency detail

 

Next example illustrates the configuration and verification of CEF operation.  The routers in this topology have already been configured to exchange routes through EIGRP.

cef operation

R1 has CEF enabled globally but CEF is not enabled on interface Fa0/0. Next example shows how to enable CEF on an interface if CEF is already enabled globally.

R1# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 172.16.1.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is disabled
... OUTPUT OMITTED ...

 

Configure CEF on the same interface

R1# conf term
R1(config)# int fa 0/0
R1(config-if)# ip route-cache cef
R1(config-if)# end

 

Verify CEF configuration on the interface

R1# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 172.16.1.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
... OUTPUT OMITTED ...

 

On R2 CEF is disabled globally so we need to configure CEF on R2

 R2# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 192.168.1.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is disabled
IP Flow switching is disabled
IP CEF switching is disabled
... OUTPUT OMITTED ...

R2# conf t
R2(config)# ip cef
R2(config)# end
R2# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 192.168.1.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
... OUTPUT OMITTED ...

 

Verifying CEF operation on R1

R1# show ip cef
Prefix Next Hop Interface
0.0.0.0/0 no route
0.0.0.0/8 drop
0.0.0.0/32 receive
1.1.1.1/32 receive Loopback0
2.2.2.2/32 10.1.1.2 Serial1/0
10.1.1.0/30 attached Serial1/0
10.1.1.0/32 receive Serial1/0
10.1.1.1/32 receive Serial1/0
10.1.1.3/32 receive Serial1/0
127.0.0.0/8 drop
172.16.1.0/24 attached FastEthernet0/0
172.16.1.0/32 receive FastEthernet0/0
172.16.1.1/32 receive FastEthernet0/0
172.16.1.255/32 receive FastEthernet0/0
192.168.1.0/24 10.1.1.2 Serial1/0
224.0.0.0/4 drop
224.0.0.0/24 receive
240.0.0.0/4 drop
255.255.255.255/32 receive

R1# show adjacency detail
Protocol Interface Address
IP Serial1/0 point2point(11)
0 packets, 0 bytes
epoch 0
sourced in sev-epoch 1
Encap length 4
0F000800
P2P-ADJ

 

The show ip cef command, shows the contents of the FIB for Router R1. Note that if the next hop of a network prefix is set to attached, the entry represents a network to which the router is directly attached. If the next hop of a network prefix is set to receive, the entry represents an IP address on one of the router’s interfaces.

For example, the network prefix 10.1.1.0/30, with a next hop of attached, is a network
(30-bit mask) directly attached to Router R1’s Serial 1/0 interface. However, the network prefix of 10.1.1.1/32 with a next hop of receive is a specific IP address (32-bit mask). Note that the all-0’s host addresses for directly attached networks (for ex, 10.1.1.0/30) and the all-1’s host addresses for directly attached networks (for ex, 172.16.1.255/32) also show up as receive entries.

Output from the show adjacency detail command displays information about how to
reach a specific adjacency shown in the FIB. Indicates that network 192.168.1.0 /24 is reachable by going out of interface Serial 1/0. The adjacency table also shows interface Serial 1/0 uses a point-to-point connection. Therefore, the adjacent router is on the other side of the point-to-point link. If an interface in the adjacency table is an Ethernet interface, source and destination MAC address information is contained in the entry for the interface.

 

 

Hope this helps someone else!

CCNP SWITCH 300-115 – Part 3 Infrastructure Services – FHRP

Background

Multilayer switches can act as IP gateways for connected hosts by providing gateway addresses at VLAN SVIs and Layer 3 physical interfaces. These switches can also participate in routing protocols, just as traditional routers do. For high availability, multilayer switches should offer a means of preventing one switch (gateway) failure from isolating an entire VLAN. Now we will focus on several approaches to providing router redundancy, including the following:

  • Hot Standby Router Protocol (HSRP)
  • Virtual Router Redundancy Protocol (VRRP)
  • Gateway Load Balancing Protocol (GLBP)

These are also commonly called first-hop redundancy protocols (FHRP) because the first router hop is given high availability.

 

Packet-Forwarding Review

When a host must communicate with a device on its local subnet, it can generate an ARP request, wait for the ARP reply, and exchange packets directly. However, if the far end is located on a different subnet, the host must rely on an intermediate system (a router, for example) to relay packets to and from that subnet.

A host identifies its nearest router, aka default gateway or next hop, by its IP address. If the host understands something about routing, it recognizes that all packets destined off-net must be sent to the gateway’s MAC address rather than the far end’s MAC address. The host first sends an ARP request to find the gateway’s MAC address. Then packets can be relayed to the gateway directly without having to look for ARP entries for individual destinations.

If the host is not so savvy about routing, it might still generate ARP requests for every off-net destination, hoping that someone will answer. Obviously, the off-net destinations cannot answer because they never receive the ARP request broadcasts, these requests are not forwarded across subnets (blocked by routers, firewalls, or even switches). Instead, you can configure the gateway to provide a proxy ARP function so that it will reply to ARP requests with its own MAC address, as if the destination itself had responded.

The issue of gateway availability becomes important. If the gateway router for a subnet or VLAN goes down, packets have no way of being forwarded out the local subnet. Several protocols are available that allow multiple routing devices to share a common gateway address so that if one goes down, another automatically can pick up the active gateway role.

 

Note: IPv6 offers some inherent gateway redundancy because every router connected to a subnet advertises its presence. Hosts overhear the advertisements and use the first router received. If that router fails, hosts have to wait up to 40 seconds to discover a replacement router—an inefficient process.

 

Hot Standby Router Protocol

HSRP is a Cisco proprietary protocol developed to allow several routers (or multilayer switches) to appear as a single gateway IP address. RFC 2281 describes this protocol in more detail.

HSRP runs on top of UDP port 1985. Packets are sent to multicast 224.0.0.2 with TTL 1. Routers (or MLSs) use their actual IP address as the source address for protocol packets, not the virtual IP address. This is necessary so that the HSRP routers can identify each other.

The format of the data portion of the UDP datagram is:

                          1                   2                   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |   Op Code     |     State     |   Hellotime   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Holdtime    |   Priority    |     Group     |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Authentication  Data                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Authentication  Data                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Virtual IP Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

As a brief explanation, each of the routers that provides redundancy for a given gateway address is assigned to a common HSRP group. One router is elected as the primary, or active, HSRP router, another is elected as the standby HSRP router and all the others remain in the listen HSRP state. The routers exchange HSRP hello messages at regular intervals so that they can remain aware of each other’s existence and that of the active router.

Below shows a simple network in which two multilayer switches use HSRP Group 1 to provide the redundant gateway address 192.168.1.1. Switch A is the active router, with priority 200, and answers the ARP request for the gateway address. Because Switch B is in the Standby state, it never is used for traffic sent to 192.168.1.1. Instead, only Switch A performs the gateway routing function, and only its uplink to the access layer is utilized.

 

 

 

 

 

 

 

 

 

 

Note: HSRP sends its hello messages to the multicast destination 224.0.0.2 (“all routers”) using UDP port 1985.

An HSRP group can be assigned an arbitrary group number, from 0 to 255. If you configure HSRP groups on several VLAN interfaces, it can be handy to make the group number the same as the VLAN number. However, most Catalyst switches support only up to 16 unique HSRP group numbers. If you have more than 16 VLANs, you will quickly run out of group numbers. An alternative is to make the group number the same (that is, 1) for every VLAN interface. This is perfectly valid because the HSRP groups are locally significant only on an interface. HSRP Group 1 on interface VLAN 10 is unique and independent from HSRP Group 1 on interface VLAN 11.

 

HSRP Router Election

HSRP election is based on a priority value (0 to 255) that is configured on each router/MLS in the group. By default, the priority is 100.

The router with the highest priority value (255 is highest) becomes the active router for the group. If all router priorities are equal or set to the default value, the router with the highest IP address on the HSRP interface becomes the active router. To set the priority, use the following interface configuration command syntax:

Switch(config-if)# standby group priority priority

 

Suppose that one switch is left at its default priority of 100, while the local switch is intended to win the active role election. You can use the following command to set the HSRP priority to 200:

Switch(config-if)# standby 1 priority 200

 

States

When HSRP is configured on an interface, the router progresses through a series of states before becoming active. This forces a router to listen for others in a group and see where it fits into the pecking order. Devices participating in HSRP must progress their interfaces through the following state sequence:

1. Disabled
2. Init
3. Listen
4. Speak
5. Standby
6. Active

 

Only the Standby (second-highest priority) monitors the hello messages from the Active router. By default, hellos are sent every 3 seconds. If hellos are missed for the duration of the Hold-Time timer (default 10 seconds, 3x the Hello timer), the active router is presumed to be down. The standby router is then clear to assume the active role.

At that point, if other routers are sitting in the Listen state, the next-highest priority router is allowed to become the new standby router.

If you need to change the timer values, use the following interface configuration command. If you decide to change the timers, you should change them identically on all routers in the HSRP group.

Switch(config-if)# standby group timers [msec] hello [msec] holdtime

 

The hello and holdtime values can be given in seconds or in milliseconds, if the msec keyword precedes a value. The hello time can range from 1 to 254 seconds or from 15 to 999 milliseconds. The holdtime always should be at least three times the Hello timer and can range from 1 to 255 seconds or 50 to 3000 milliseconds.

 

Set the hello time at 100 milliseconds and the hold time to 300 milliseconds:

Switch(config-if)# standby 1 timers msec 100 msec 300

 

After the active router fails and the standby becomes active, the original active router cannot immediately become active when it is restored. In other words, if a router is not already active, it cannot become active again until the current active router fail, even if its priority is higher than that of the active router. An interesting case arises when routers are just being powered up or added to a network. The first router to bring up its interface becomes the HSRP active router, even if it has the lowest priority of all.

Configure a router to preempt or immediately take over the active role if its priority is the highest at any time:

Switch(config-if)# standby group preempt [delay [minimum seconds] [reload seconds]]

 

By default, the local router immediately can preempt another router that has the active role. To delay the preemption, use the delay keyword followed by one or both of the following parameters:

  • minimum – Add this keyword to force the router to wait for seconds (0 to 3600 seconds) before attempting to overthrow an active router with a lower priority. This delay time begins as soon as the router is capable of assuming the active role, such as after an interface comes up or after HSRP is configured.
  • reload – Add this keyword to force the router to wait for seconds (0 to 3600 seconds) after it has been reloaded or restarted. This is handy if there are routing protocols that need time to converge. The local router should not become the active gateway before its routing table is fully populated or it might not be capable of routing traffic properly.
  • HSRP also can use an authentication method to prevent unexpected devices from spoofing or participating in HSRP. All routers in the same standby group must have an identical authentication method and key. You can use either plain-text or MD5 authentication.

 

Plain-Text HSRP Authentication

HSRP messages are sent with a plain-text key string (up to eight characters) as a simple method to authenticate HSRP peers. If the key string in a message matches the key configured on an HSRP peer, the message is accepted. When keys are sent in the clear, they can be easily intercepted and used to impersonate legitimate peers. Plain-text authentication is intended only to prevent peers with a default configuration from participating in HSRP. Cisco devices use cisco as the default key string. This is useful only in a point-to-point interfaces or lab environments.

You can configure a plain-text authentication key for an HSRP group with the following interface configuration command:

Switch(config-if)# standby group authentication string

 

MD5 Authentication

MD5 authentication hash is computed on a portion of each HSRP message and a secret key known only to legitimate HSRP group peers. The MD5 hash value is sent along with HSRP messages. As a message is received, the peer recomputes the hash of the expected message contents and its own secret key, if the hash values are identical, the message is accepted.

MD5 authentication “secure” because the hash value contained in the HSRP messages is extremely difficult (if not impossible as off now) to reverse. The hash value itself is not used as a key, instead, the hash is used to validate the message contents.

You can configure MD5 authentication by associating a key string with an interface, using the following interface configuration command:

Switch(config-if)# standby group authentication md5 key-string [0 | 7] string

 

Note: By default, the key string (up to 64 characters) is given as plain text. This is the same as specifying the 0 keyword. After the key string is entered, it is shown as an encrypted value in the switch configuration. You also can copy and paste an encrypted key string value into this command by preceding the string with the 7 keyword.

 

Alternatively, you can define an MD5 key string as a key on a chain. This method is more flexible, enabling you to define more than one key on the switch. Any of the keys then can be associated with HSRP on any interface. If a key needs to be changed, you simply add a new key to the key chain and retire (delete) an old key.

First define the key chain globally, then add one key at a time. The key-number index is arbitrary, but keys are tried in sequential order. Finally, associate the key chain with HSRP on an interface by referencing its chain-name. You can use the following commands to configure HSRP MD5 authentication:

Switch(config)# key chain chain-name
Switch(config-keychain)# key key-number
Switch(config-keychain-key)# key-string [0 | 7] string
Switch(config)# interface type mod/num
Switch(config-if)# standby group authentication md5 key-chain chain-name

 

Conceding the Election

Consider an active router in an HSRP group: A group of clients sends packets to it for forwarding, and it has one or more links to the rest of the world. If one of those links fails, the router remains active. If all of those links fail, the router still remains active. But sooner or later, the path to the rest of the world is either crippled or removed, and packets from the clients no longer can be forwarded.

HSRP has a mechanism for detecting link failures and swaying the election, giving another router an opportunity to take over the active role. When a specific interface is tracked, HSRP reduces the router’s priority by a configurable amount as soon as the interface goes down. If more than one interface is tracked, the priority is reduced even more with each failed interface. The priority is incremented by the same amount as interfaces come back up.

Particularly useful when a switch has several paths out of a VLAN/segment, as more interfaces fail and remove the possible paths, other HSRP peers should appear to be more desirable and take over the active role. To configure interface tracking, use the following interface configuration command:

Switch(config-if)# standby group track type mod/num [decrementvalue]

 

Default decrement value for an interface is 10. Interface tracking does not involve the state of the HSRP interface itself. Instead, the state of other specific interfaces affects the usefulness of the local router/MLS as a gateway. The only way another router/switch can take over the active role after interface tracking reduces the priority is if the following two conditions are met:

  • Another router/switch now has a higher HSRP priority.
  • That same router/switch is using preempt in its HSRP configuration.

 

HSRP Gateway Addressing

Each router/switch in an HSRP group has its own unique IP address assigned to an interface. This address is used for all routing protocol and management traffic initiated by or destined to the router. In addition, each router has a common gateway IP address, the virtual router address, which is kept alive by HSRP. This address aka the HSRP address or the standby address. Clients can point to that virtual gateway address as their default gateway, knowing that a router/switch always keeps that address active. Keep in mind that the actual interface address and the virtual (standby) address must be configured to be in the same IP subnet.

You can assign the HSRP address with the following interface command:

Switch(config-if)# standby group ip ip-address [secondary]

 

When HSRP is used on an interface that has secondary IP addresses, you can add the secondary keyword so that HSRP can provide a redundant secondary gateway address.

 

Note: To use HSRP with IPv6, use the following commands to enable HSRP Version 2 and set the HSRP address:

Switch(config-if)# standby version 2
Switch(config-if)# standby ipv6 autoconfig

 

Each router/switch keeps a unique MAC address for its interface. This MAC address is always associated with the unique IP address configured on the interface.

For Virtual router address, HSRP defines a special MAC address of the form:

0000.0c07.acxx

Where xx represents the HSRP group number as a two-digit hex value. For example, HSRP Group 1 appears as:

0000.0c07.ac01

HSRP Group 16 appears as below (and so on):

0000.0c07.ac10

 

Configuration commands you can use to configure switches A and B

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address 192.168.1.10 255.255.255.0
Switch-A(config-if)# standby 1 priority 200
Switch-A(config-if)# standby 1 preempt
Switch-A(config-if)# standby 1 ip 192.168.1.1
Switch-A(config-if)# no shutdown
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address 192.168.1.11 255.255.255.0
Switch-B(config-if)# standby 1 priority 100
Switch-B(config-if)# standby 1 preempt
Switch-B(config-if)# standby 1 ip 192.168.1.1
Switch-B(config-if)# no shutdown

 

Load Balancing with HSRP

Consider a network in which HSRP is used on two distribution switches to provide a redundant gateway address for access layer users. Only one of the two becomes the active HSRP router. the other remains in standby. All the users send their traffic to the active router over the uplink to the active router. The standby router and its uplink essentially sit idle until a router failure occurs.

Load balancing traffic across two uplinks to two HSRP switch with a single HSRP group is not possible. Then how is it possible to load balance with HSRP? The trick is to use two HSRP groups:

  • One group assigns an Active router to one switch.
  • The other group assigns another Active router to the other switch

 

Two different virtual router or gateway addresses can be used simultaneously. The rest of the trick is to make each switch function as the standby router for its partner’s HSRP group. In other words, each router is active for one group and standby for the other group. The clients or end users also must have their default gateway addresses configured as one of the two virtual HSRP group addresses.

Below presents this scenario. Now, Switch A is not only the active router for HSRP Group 1 (192.168.1.1), but it is also the standby router for HSRP Group 2 (192.168.1.2). Switch B is configured with its roles reversed. The remaining step is to configure half of the client PCs with the HSRP Group 1 virtual router address and the other half with the Group 2 address. This makes load balancing possible and effective. Each half of the hosts uses one switch as its gateway over one uplink.

Two HSRP Groups

 

 

 

 

 

 

 

Configuring Load Balancing Between HSRP Groups (for the above scenario):

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address 192.168.1.10 255.255.255.0
Switch-A(config-if)# standby 1 priority 200
Switch-A(config-if)# standby 1 preempt
Switch-A(config-if)# standby 1 ip 192.168.1.1
Switch-A(config-if)# standby 1 authentication MyKey
Switch-A(config-if)# standby 2 priority 100
Switch-A(config-if)# standby 2 ip 192.168.1.2
Switch-A(config-if)# standby 2 authentication MyKey
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address 192.168.1.11 255.255.255.0
Switch-B(config-if)# standby 1 priority 100
Switch-B(config-if)# standby 1 ip 192.168.1.1
Switch-B(config-if)# standby 1 authentication MyKey
Switch-B(config-if)# standby 2 priority 200
Switch-B(config-if)# standby 2 preempt
Switch-B(config-if)# standby 2 ip 192.168.1.2
Switch-B(config-if)# standby 2 authentication MyKey

 

Use the following command syntax to verify information about the status of one or more HSRP groups and interfaces:

Router# show standby [brief] [vlan vlan-id | type mod/num]

 

Based on the configuration above, the output in below shows that Switch A is the active router for HSRP Group 1 and the standby router for HSRP Group 2 on interface VLAN 50.

Verify the HSRP Router Role of a Switch: Switch A

Switch-A# show standby vlan 50 brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vl50 1 200 P Active local 192.168.1.11 192.168.1.1
Vl50 2 100 Standby 192.168.1.11 local 192.168.1.2
Switch-A#
Switch-A# show standby vlan 50
Vlan50 - Group 1

Local state is Active, priority 200, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.248
 Virtual IP address is 192.168.1.1 configured
Active router is local
Standby router is 192.168.1.11 expires in 9.860
Virtual mac address is 0000.0c07.ac01
Authentication text "MyKey"
2 state changes, last state change 00:11:58
IP redundancy name is "hsrp-Vl50-1" (default)

Vlan50 - Group 2
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 1.302
Virtual IP address is 192.168.1.2 configured
Active router is 192.168.1.11, priority 200 expires in 7.812
Standby router is local
Authentication text "MyKey"
4 state changes, last state change 00:10:04
IP redundancy name is "hsrp-Vl50-2" (default)
Switch-A#

 

The output from Switch B below, shows that it has inverted roles from Switch A for HSRP Groups 1 and 2.

Switch-B# show standby vlan 50 brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vl50 1 100 Standby 192.168.1.10 local 192.168.1.1
Vl50 2 200 P Active local 192.168.1.10 192.168.1.2
Switch-B#
Switch-B# show standby vlan 50

Vlan50 - Group 1
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.980
Virtual IP address is 192.168.1.1 configured
Active router is 192.168.1.10, priority 200 expires in 8.128
Standby router is local
Authentication text "MyKey"
1 state changes, last state change 00:01:12
IP redundancy name is "hsrp-Vl50-1" (default)

Vlan50 - Group 2
Local state is Active, priority 200, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.888
Virtual IP address is 192.168.1.2 configured
Active router is local
Standby router is 192.168.1.10 expires in 8.500
Virtual mac address is 0000.0c07.ac02
Authentication text "MyKey"
1 state changes, last state change 00:01:16
Switch-B#

 

Virtual Router Redundancy Protocol

VRRP is a standards-based alternative to HSRP, defined in IETF standard RFC 2338 (latest revision is RFC5798. VRRP is so similar to HSRP that you need to learn only slightly different terminology and a couple of slight functional differences. When you understand HSRP operation and configuration, you will also understand VRRP. I’m highlighting only the differences between HSRP and VRRP. VRRP provides one redundant gateway address from a group of routers. The active router is called the master router, whereas all others are in the backup state. The master router is the one with the highest router priority in the VRRP group.

VRRP group numbers range from 0 to 255, router priorities range from 1 to 254. (254 is the highest, 100 is the default.) The virtual router MAC address is of the form 0000.5e00.01xx, where xx is a two-digit hex VRRP group number.

VRRP advertisements are sent at 1-second intervals. Backup routers optionally can learn the advertisement interval from the master router. By default, all VRRP routers are configured to preempt the current master router if their priorities are greater.

VRRP sends its advertisements to the multicast destination address 224.0.0.18 (VRRP), using IP protocol 112. VRRP was introduced in Cisco IOS Software Release 12.0(18)ST for routers, but is not supported consistently across all switching platforms.

 

VRRP Configuration Commands

Assign a VRRP router priority (default 100).

Switch(config-if)# vrrp group priority level

 

Alter the advertisement timer (default 1 second).

Switch(config-if)# vrrp group timers advertise [msec] interval

 

Learn the advertisement interval from the master router.

Switch(config-if)# vrrp group timers learn

 

Disable preempting (default is to preempt).

Switch(config-if)# no vrrp group preempt

 

Change the preempt delay (default 0 seconds).

Switch(config-if)# vrrp group preempt [delay seconds]

 

Use authentication for advertisements.

Switch(config-if)# vrrp group authentication string

 

Assign a virtual IP address.

Switch(config-if)# vrrp group ip ip-address [secondary]

 

Track an object.

Switch(config-if)# vrrp group track objectnumber [decrement priority]

 

As an example, the load-balancing scenario shown below is implemented using VRRP. You would use the configuration commands on the two Catalyst switches.

Configuring Load Balancing with VRRP

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address 192.168.1.10 255.255.255.0
Switch-A(config-if)# vrrp 1 priority 200
Switch-A(config-if)# vrrp 1 ip 192.168.1.1
Switch-A(config-if)# vrrp 2 priority 100
Switch-A(config-if)# no vrrp 2 preempt
Switch-A(config-if)# vrrp 2 ip 192.168.1.2
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address 192.168.1.11 255.255.255.0
Switch-B(config-if)# vrrp 1 priority 100
Switch-B(config-if)# no vrrp 1 preempt
Switch-B(config-if)# vrrp 1 ip 192.168.1.1
Switch-B(config-if)# vrrp 2 priority 200
Switch-B(config-if)# vrrp 2 ip 192.168.1.2

 

Verify information about VRRP status on one or more interfaces:

Switch# show vrrp [brief]

 

Verify Switch Roles for VRRP Load Balancing

Switch-A# show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Vlan50 1 200 3218 Y Master 192.168.1.10 192.168.1.1
Vlan50 2 100 3609 Backup 192.168.1.11 192.168.1.2

Switch-A#
Switch-B# show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Vlan50 1 100 3609 Backup 192.168.1.10 192.168.1.1
Vlan50 2 200 3218 Y Master 192.168.1.11 192.168.1.2
Switch-B#

 

Verifying VRRP Status for multiple VRRP Groups

Switch-A# show vrrp
Vlan50 - Group 1
State is Master
Virtual IP address is 192.168.1.1
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption is enabled
min delay is 0.000 sec
Priority is 200
Authentication is enabled
Master Router is 192.168.1.10 (local),
priority is 200
Master Advertisement interval is 1.000
sec
Master Down interval is 3.218 sec

Vlan50 - Group 2
State is Backup
Virtual IP address is 192.168.1.2
Virtual MAC address is 0000.5e00.0102
Advertisement interval is 1.000 sec
Preemption is disabled
Priority is 100
Authentication is enabled
Master Router is 192.168.1.11, priority
is 200
Master Advertisement interval is 1.000
sec
Master Down interval is 3.609 sec
(expires in 2.977 sec)
Switch-A#

Switch-B# show vrrp
Vlan50 - Group 1
State is Backup
Virtual IP address is 192.168.1.1
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption is disabled
Priority is 100
Authentication is enabled
Master Router is 192.168.1.10, priority
is 200
Master Advertisement interval is 1.000
sec
Master Down interval is 3.609 sec
(expires in 2.833 sec)

Vlan50 - Group 2
State is Master
Virtual IP address is 192.168.1.2
Virtual MAC address is 0000.5e00.0102
Advertisement interval is 1.000 sec
Preemption is enabled
min delay is 0.000 sec
Priority is 200
Authentication is enabled
Master Router is 192.168.1.11 (local),
priority is 200
Master Advertisement interval is 1.000
sec
Master Down interval is 3.218 sec
Switch-B#

 

Gateway Load Balancing Protocol

GLBP is a Cisco proprietary protocol designed to overcome the limitations of existing redundant router protocols. Some of the concepts are the same as with HSRP/VRRP, but the terminology is different, and the behavior is much more dynamic and robust.

Note: GLBP was introduced in Cisco IOS Software Release 12.2(14)S for routers, but is not consistently supported across all switching platforms.

 

To provide a virtual router, multiple switches (routers) are assigned to a common GLBP group. Instead of having just one active router performing forwarding for the virtual router address, all routers in the group can participate and offer load balancing by forwarding a portion of the overall traffic.

The advantage is that none of the clients has to be pointed toward a specific gateway address, they can all have the same default gateway set to the virtual router IP address. The load balancing is provided completely through the use of virtual router MAC addresses in ARP replies returned to the clients.

As a client sends an ARP request looking for the virtual router address, GLBP sends back an ARP reply with the virtual MAC address of a selected router in the group. The result is that all clients use the same gateway address but have differing MAC addresses for it.

 

Active Virtual Gateway

The trick behind this load balancing lies in the GLBP group. One router is elected the Active Virtual Gateway (AVG). This router has the highest priority value, or the highest IP address in the group, if there is no highest priority. The AVG answers all ARP requests for the virtual router address. Which MAC address it returns depends on which load-balancing algorithm it is configured to use. In any event, the virtual MAC address supported by one of the routers in the group is returned.

The AVG also assigns the necessary virtual MAC addresses to each of the routers participating in the GLBP group. Up to four virtual MAC addresses can be used in any group. Each of these routers is referred to as an Active Virtual Forwarder (AVF), forwarding traffic received on its virtual MAC address. Other routers in the group serve as backup or secondary virtual forwarders, in case the AVF fails. The AVG also assigns secondary roles.

 

Assign the GLBP priority to a router with the following interface configuration command:

Switch(config-if)# glbp group priority level

 

Note: GLBP group numbers range from 0 to 1023. The router priority can be 1 to 255 (255 is the highest priority), default 100.

 

As with HSRP, another router cannot take over an active role until the current active router fails. GLBP does allow a router to preempt and become the AVG if it has a higher priority than the current AVG. Use the following command to enable preempting and to set a time delay before preempting begins:

Switch(config-if)# glbp group preempt [delay minimum seconds]

 

Routers participating in GLBP must monitor each other’s presence so that another router can assume the role of a failed router. To do this, the AVG sends periodic hello messages to each of the other GLBP peers. In addition, it expects to receive hello messages from each of them. Hello messages are sent at hellotime intervals, with a default of 3 seconds. If hellos are not received from a peer within a holdtime, defaulting to 10 seconds, that peer is presumed to have failed.

Adjust the GLBP timers with the following interface configuration command syntax:

Switch(config-if)# glbp group timers [msec] hellotime [msec] holdtime

 

hellotime – from 1 to 60 seconds or from 50 to 60,000 milliseconds.

holdtime – must be greater than the hellotime and can go up to 180 seconds or 180,000 milliseconds.

Note: Always make the holdtime at least three times greater than the hellotime to give some tolerance to missed or delayed hellos from a functional peer.

Note:  just configure the timers on the router you have identified as the AVG. The AVG will advertise the timer values it is using, and every other
peer will learn those values if they have not already been explicitly set.

 

Active Virtual Forwarder

Each router participating in the GLBP group can become an AVF, if the AVG assigns it that role, along with a Virtual MAC Address. The virtual MAC addresses always have the form 0007.b4xx.xxyy. The 16-bit value denoted by xx.xx represents six 0 bits followed by a 10-bit GLBP group number.

The 8-bit yy value is the virtual forwarder number.

GLBP uses the periodic hello messages to detect AVF failures, too. Each router within a GLBP group must send hellos to every other GLBP peer. Hellos also are  expected from every other peer. If hellos from the AVF are not received by the AVG before its Hold-Time timer expires, the AVG assumes that the current AVF has failed. The AVG then assigns the AVF role to another router.
The router that is given the new AVF role might already be an AVF for a different virtual MAC address. Although a router can masquerade as two different virtual MAC addresses to support the two AVF functions, it does not make much sense to continue doing that for a long period of time. The AVG maintains two timers that help resolve this condition.

redirect timer – Determines when the AVG will stop using the old virtual MAC address in ARP replies. The AVF corresponding to the old address continues to act as a gateway for any clients that try to use it.

timeout timer – defaults to 14,400 seconds (4 hours) and can range from 700 to 64,800 seconds (18 hours). When expires, the old MAC address and the virtual forwarder using it are flushed from all the GLBP peers. The AVG assumes that the previously failed AVF will not return to service, so the resources assigned to it must be reclaimed. At this point, clients still using the old MAC address in their ARP caches must refresh the entry to obtain the new virtual MAC address.

redirect timer – defaults to 600 seconds (10 minutes) and can range from 0 to 3600 seconds (1 hour).

 

You can adjust these timers with the following interface configuration command:

Switch(config-if)# glbp group timers redirect redirect timeout

 

GLBP Weighting function to determine which router becomes the AVF for a virtual MAC address in a group. Each router begins with a maximum weight value (1 to 254).

As specific interfaces go down, the weight is decreased by a configured amount. GLBP uses thresholds to determine when a router can and cannot be the AVF. If the weight falls below the lower threshold, the router must give up its AVF role. When the weight rises above the upper threshold, the router can resume its AVF role.

 

A router receives a maximum weight of 100. If you want to make a Dynamic Weighting Adjustment, GLBP must know which interfaces to track and how to adjust the weight. You must first define an interface as a tracked object with the following global command:

Switch(config)# track object-number interface type member/module/number {lineprotocol | ip routing}

 

object-number – An arbitrary index (1 to 500) that is used for weight adjustment. The condition that triggers an adjustment can be line-protocol (the interface line protocol is up) or ip routing. (IP routing is enabled, the interface has an IP address, and the interface is up.)

 

Next, you must define the weighting thresholds for the interface with the following interface configuration command:

Switch(config-if)# glbp group weighting maximum [lower lower] [upper upper]

 

Maximum Weight – 1 to 254 (default 100).

Upper (default Maximum) and Lower (default 1) thresholds – define when the router can and cannot be the AVF, respectively.

 

Finally, you must configure GLBP to know which objects to track so that the weighting can be adjusted with the following interface configuration command:

Switch(config-if)# glbp group weighting track object-number [decrement value]

 

When the tracked object fails, the weighting is decremented by value (1 to 254, default 10). Likewise, a router that might serve as an AVF cannot preempt another when it has a higher weight value.

 

 GLBP Load Balancing

The AVG establishes load balancing by handing out virtual router MAC addresses to clients in a deterministic fashion. The AVG first must inform the AVFs in the group of the virtual MAC address that each should use. Up to four virtual MAC addresses, assigned in sequential order, can be used in a group.

You can use one of the following load-balancing methods in a GLBP group:

  • Round Robin: Each new ARP request for the virtual router address receives the next available virtual MAC address in reply. Traffic load is distributed evenly across all routers participating as AVFs in the group, assuming that each of the clients sends and receives the same amount of traffic. Default method used by GLBP.
  • Weighted: The GLBP group interface’s weighting value determines the proportion of traffic that should be sent to that AVF. A higher weighting results in more frequent ARP replies containing the virtual MAC address of that router. If interface tracking is not configured, the maximum weighting value configured is used to set the relative proportions among AVFs.
  • Host Dependent: Each client that generates an ARP request for the virtual router address always receives the same virtual MAC address in reply. This method is used if the clients have a need for a consistent gateway MAC address. (Otherwise, a client could receive replies with different MAC addresses for the router over time, depending on the load-balancing method in use.)

 

On the AVG router (or its successors), use the following configuration to define the method:

Switch(config-if)# glbp group load-balancing [round-robin | weighted | host-dependent]

 

Enabling GLBP

To enable GLBP, you must assign a virtual IP address to the group by using the following interface configuration command:

Switch(config-if)# glbp group ip [ip-address [secondary]]

 

If the ip-address is not given in the command, it is learned from another router in the group. However, if this router is to be the AVG, you must explicitly configure the IP address; otherwise, no other router knows what the value should be.

 

GLBP can also be used with IPv6. Use the following command to autoconfigure the address:

Switch(config-if)# glbp group ipv6 autoconfigure

 

Below shows a typical network in which three multilayer switches are participating in a common GLBP group. Switch A is elected the AVG, so it coordinates the entire GLBP process. The AVG answers all ARP requests for the virtual router 192.168.1.1. It has identified itself, Switch B, and Switch C as AVFs for the group.

Round-Robin Load Balancing is being used. Each of the client PCs sends an ARP request to look for the virtual router address (192.168.1.1) in turn, from left to right. Each time the AVG replies, the next sequential virtual MAC address is sent back to a client. After the fourth PC sends a request, all three virtual MAC addresses (and AVF routers) have been used, so the AVG cycles back to the first virtual MAC address.

Only one GLBP group has been configured, and all clients know of only one gateway IP address: 192.168.1.1. However, all uplinks are being used, and all routers are proportionately forwarding traffic.

MLS-GLBP Group

 

 

 

 

 

 

 

 

Redundancy is also inherent in the GLBP group: Switch A is the AVG, but the next-highest priority router can take over if the AVG fails. All routers have been given an AVF role for a unique virtual MAC address in the group. If one AVF fails, some clients remember the last-known virtual MAC address that was handed out. Therefore, another of the routers also takes over the AVF role for the failed router, causing the virtual MAC address to
remain alive at all times.

Below shows how these redundancy features react when the current active AVG fails. Before its failure, Switch A was the AVG because of its higher GLBP priority. After it failed, Switch B became the AVG, answering ARP requests with the appropriate virtual MAC address for gateway 192.168.1.1. Switch A also had been acting as an AVF, participating in the gateway load balancing. Switch B also picks up this responsibility, using its virtual MAC address 0007.b400.0102 along with the one Switch A had been using, 0007.b400.0101. Therefore, any hosts that know the gateway by any of its virtual MAC addresses still can reach a live gateway or AVF.

GLBP Component Failure

 

 

 

 

 

 

 

 

Configuring GLBP Load Balancing

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address 192.168.1.10 255.255.255.0
Switch-A(config-if)# glbp 1 priority 200
Switch-A(config-if)# glbp 1 preempt
Switch-A(config-if)# glbp 1 ip 192.168.1.1
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address 192.168.1.11 255.255.255.0
Switch-B(config-if)# glbp 1 priority 150
Switch-B(config-if)# glbp 1 preempt
Switch-B(config-if)# glbp 1 ip 192.168.1.1
Switch-C(config)# interface vlan 50
Switch-C(config-if)# ip address 192.168.1.12 255.255.255.0
Switch-C(config-if)# glbp 1 priority 100
Switch-C(config-if)# glbp 1 ip 192.168.1.1

 

You can verify GLBP operation with the show glbp [brief] command, as demonstrated below. With the brief keyword, the GLBP roles are summarized showing the interface, GLBP group number (Grp), Virtual Forwarder Number (Fwd), GLBP Priority (Pri), State, and Addresses.

 

Verifying GLBP Operation

Switch-A# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 200 Active 192.168.1.1 local 192.168.1.11
Vl50 1 1 7 Active 0007.b400.0101 local -
Vl50 1 2 7 Listen 0007.b400.0102 192.168.1.11 -
Vl50 1 3 7 Listen 0007.b400.0103 192.168.1.12 -
Switch-A#

Switch-B# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 150 Standby 192.168.1.1 192.168.1.10 local
Vl50 1 1 7 Listen 0007.b400.0101 192.168.1.10 -
Vl50 1 2 7 Active 0007.b400.0102 local -
Vl50 1 3 7 Listen 0007.b400.0103 192.168.1.12 -
Switch-B#

Switch-C# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 100 Listen 192.168.1.1 192.168.1.10 192.168.1.11
Vl50 1 1 7 Listen 0007.b400.0101 192.168.1.10 -
Vl50 1 2 7 Listen 0007.b400.0102 192.168.1.11 -
Vl50 1 3 7 Active 0007.b400.0103 local -
Switch-C#

 

Notice that Switch A is shown to be the AVG because it has a dash in the Fwd column and is in the Active state. It also is acting as AVF for virtual forwarder number 1. Because the GLBP group has three routers, there are three virtual forwarders and virtual MAC addresses. Switch A is in the Listen state for forwarders number 2 and 3, waiting to be given an active role in case one of those AVFs fails.

Switch B is shown to have the Standby role, waiting to take over in case the AVG fails. It is the AVF for virtual forwarder number 2.

Finally, Switch C has the lowest GLBP priority, so it stays in the Listen state, waiting for the active or standby AVG to fail. It is also the AVF for virtual forwarder number 3. You also can display more detailed information about the GLBP configuration and status by omitting the brief keyword.

Below shows this output on the AVG router. Because this is the AVG, the virtual forwarder roles it has assigned to each of the routers in the GLBP group also are shown.

 

Verify Detailed GLBP Configuration and Status Information

Switch-A# show glbp
Vlan50 - Group 1
State is Active
7 state changes, last state change 03:28:05
Virtual IP address is 192.168.1.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.672 secs
Redirect time 600 sec, forwarder time-out 14400 sec
Preemption enabled, min delay 0 sec
Active is local
Standby is 192.168.1.11, priority 150 (expires in 9.632 sec)
Priority 200 (configured)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
There are 3 forwarders (1 active)
Forwarder 1
State is Active
3 state changes, last state change 03:27:37
MAC address is 0007.b400.0101 (default)
Owner ID is 00d0.0229.b80a
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
 MAC address is 0007.b400.0102 (learnt)
Owner ID is 0007.b372.dc4a
Redirection enabled, 598.308 sec remaining (maximum 600 sec)
Time to live: 14398.308 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.11 (primary), weighting 100 (expires in 8.308 sec)
Forwarder 3
State is Listen
MAC address is 0007.b400.0103 (learnt)
Owner ID is 00d0.ff8a.2c0a
Redirection enabled, 599.892 sec remaining (maximum 600 sec)
Time to live: 14399.892 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.12 (primary), weighting 100 (expires in 9.892 sec)
Switch-A#

 

Verifying Gateway Redundancy (HSRP & GLBP)

Display HSRP status.

Switch# show standby brief

 

Display HSRP on an interface.

Switch# show standby type member/module/number

 

Display VRRP status.

Switch# show vrrp brief all

 

Display VRRP on an interface.

Switch# show vrrp interface type member/module/number

 

Display status of a GLBP group.

Switch# show glbp [group] [brief]

 

 

Hope this helps someone else!

CCNP SWITCH 300-115 – Part 2.2 Security With Cisco IOS AAA TACACS+ & RADIUS

Authentication Authorization and Accounting

You can manage user activity to and through a switch with authentication, authorization, and accounting (AAA) features. AAA uses standardized methods to challenge users for their credentials before access is allowed or authorized. Accounting protocols also can record user activity on a switch.

Simply put, think of AAA in the following manner:

  • Authentication: Who is the user?
  • Authorization: What is the user allowed to do?
  • Accounting: What did the user do?

 

Background

You have several methods to manage users who might try to log in to one of your switches to perform some operation. At the most basic level, you could avoid any authentication other than simple passwords configured on the switch console/vty lines. Authorization can be equally simple: When users successfully log in, they are authorized for EXEC level privileges. By entering the correct enable secret password, users can be authorized for a higher privilege level.

Under the simple scenario, if a user knows the correct password, he can connect to the switch. But who is that user? You might never know who actually logged in and changed the configuration or rebooted the switch! Instead, you could use the username command to configure individual usernames and passwords on the switch. That would solve the user anonymity problem, but your network might consist of many administrative users
and many switches, requiring quite a bit of username configuration and maintenance.

A more scalable solution is to leverage AAA functions that are centralized, standardized, resilient, and flexible. A centralized authentication server can contain a database of all possible users and their passwords, as well as policies to authorize user activities. As users come and go, their accounts can be easily updated in one place. All switches and routers query the AAA server to get up-to-date information about a user.

 

Cisco switches can use the following two protocols to communicate with AAA servers:

  • TACACS+: A Cisco proprietary protocol that separates each of the AAA functions, communication is secure and encrypted over TCP port 49.
  • RADIUS: A standards-based protocol that combines authentication and authorization into a single resource; communication uses UDP ports 1812 and 1813 (accounting), but is not completely encrypted.

 

Both TACACS+ and RADIUS are arranged as a client/server setup, where a switch acts as a client talking to a AAA server. Below shows a simplified view of the process. In the AAA client role, a switch is often called a Network Access Device (NAD) or Network Access Server (NAS). When a user tries to connect to a switch, the switch challenges the user for credentials, then passes the credentials along to the AAA server. In simple terms, if the user passes authentication, the AAA server returns an “accept” message to the switch. Otherwise, a “reject” message is returned.

Simple AAA View

 

 

 

 

Note: Cisco implements AAA services in its Identity Services Engine (ISE) and Cisco Secure Access Control Server (ACS).

 

Configuring Authentication

Switch access can be granted only after a user’s identity has been validated. User authentication is commonly used on switches and routers to permit remote access to the network administration staff only. In this case, when someone uses Telnet or SSH to log in to a switch, that individual is challenged to provide a username and password. The individual’s credentials are then submitted to a device that can grant the user access.

 

TACACS+, administered through the AAA security services, can provide these services:

Authentication—Provides complete control of authentication through login and password dialog, challenge and response, and messaging support.

The authentication facility can conduct a dialog with the user (for example, after a username and password are provided, to challenge a user with several questions, such as home address, mother’s maiden name, service type, and social security number). The TACACS+ authentication service can also send messages to user screens. For example, a message could notify users that their passwords must be changed because of the company’s password aging policy.

Authorization—Provides fine-grained control over user capabilities for the duration of the user’s session, including but not limited to setting autocommands, access control, session duration, or protocol support. You can also enforce restrictions on what commands a user can execute with the TACACS+ authorization feature.

Accounting—Collects and sends information used for billing, auditing, and reporting to the TACACS+ daemon. Network managers can use the accounting facility to track user activity for a security audit or to provide information for user billing. Accounting records include user identities, start and stop times, executed commands (such as PPP), number of packets, and number of bytes.

The TACACS+ protocol provides authentication between the switch and the TACACS+ daemon, and it ensures confidentiality because all protocol exchanges between the switch and the TACACS+ daemon are encrypted.

You need a system running the TACACS+ daemon software to use TACACS+ on your switch.

 

User authentication can be handled by several methods:

-Usernames and passwords configured locally on the switch
-One or more external Remote Authentication Dial-In User Service (RADIUS) servers
-One or more external Terminal Access Controller Access Control System + (TACACS+) servers

 

Any combination of these methods can be used. In fact, authentication must be defined by grouping the desired methods into a method list. The list contains the types or protocols that will be used, in the sequential order that they will be tried.

 

To use authentication on a Catalyst switch, you must configure several things in the following order:

1. Enable AAA on the switch. All user authentication is handled locally by configuring usernames and passwords on the switch itself:

Switch(config)# aaa new-model

The new-model refers to the use of method lists, by which authentication methods and sources can be grouped or organized. The new model is much  more scalable than the “old model,” in which the authentication source was explicitly configured.

 

2. Define the source of authentication. You can compare user credentials against locally configured usernames and passwords, or against a database managed by external RADIUS or TACACS+ servers. Use locally configured usernames and passwords as a last resort, when no other authentication servers are reachable or in use on the network.

Switch(config)# username username password password

 

RADIUS or TACACS+ servers are defined in groups. First, define each server along with its secret shared password. This string is known only to the switch and the server, and provides a key for encrypting the authentication session. Use one of the following global configuration commands:

Switch(config)# radius-server host {hostname | ip-address} [key string]
Switch(config)# tacacs-server host {hostname | ip-address} [key string]

 

Define a group name that will contain a list of servers, using the following global configuration command:

Switch(config)# aaa group server {radius | tacacs+} group-name

 

Define each server of the group type with the following server-group configuration command:

Switch(config-sg)# server ip-address

You can define multiple RADIUS or TACACS+ servers by repeating the commands in this step.

 

3. Define a list of authentication methods to try. You can list switch login authentication methods by giving the method a descriptive name or using the unnamed “default” method. List each method or protocol type in the order that it should be tried. If none of the servers for the first method responds, the switch will try the servers in the next method listed.

Define a method list:

Switch(config)# aaa authentication login {default | list-namemethod1 [method2 ...]

 

Here the methods refer to the following keywords:

  • tacacs+: Each of the TACACS+ servers configured on the switch is tried, in the order that it was configured.
  • radius: Each of the RADIUS servers configured on the switch is tried, in the order that it was configured.
  • local: The user’s credentials are compared against all the username commands configured on the local switch.
  • line: The line passwords authenticate any connected user. No usernames can be used.

 

Note:  Add the local or line methods at the end of the list, as a last resort. This way, if all the RADIUS or TACACS+ servers are unavailable or the switch is completely isolated from the rest of the network, a locally configured authentication method will eventually be used. Otherwise, you will never be able to access the switch until at least one of the servers comes back online.

 

4. Apply a method list to a switch line.

First, select a line (console or vty for Telnet/SSH access) using the line line command. Then trigger the user authentication on that line to use an AAA
method list:

Switch(config-line)# login authentication {default | list-name}

You can use the default method list only if one list is sufficient for all circumstances on the switch. Otherwise, if you have configured named method lists, you can reference one of them here.

 

5. After authentication is configured on a switch, stay logged in on one session so that the authentication can be tested. If you exit the configuration session, you will not be able to log in again if the authentication is misconfigured. While you stay logged in on the original session, bring up a new Telnet session to the switch. If you can authenticate successfully, everything is configured properly.

Below example lists the commands necessary to configure a switch to use two TACACS+ servers to authenticate management users. The servers are 192.168.10.10 and 192.168.10.11, also known as the AAA group named myauthservers.

AAA authentication group myauth is configured to try the TACACS+ server group. If none of the servers is available, local authentication will be used instead. Notice that a username lastresort is configured for that case. Finally, the myauth method is used to authenticate users on lines vty 0 through 15 for Telnet or SSH access.

Switch(config)# aaa new-model
Switch(config)# username lastresort password MySecretP@ssw0rd
Switch(config)# tacacs-server host 192.168.10.10 key t@c@csk3y
Switch(config)# tacacs-server host 192.168.10.11 key t@c@csk3y
Switch(config)# aaa group server tacacs+ myauthservers
Switch(config-sg)# server 192.168.10.10
Switch(config-sg)# server 192.168.10.11
Switch(config-sg)# exit
Switch(config)# aaa authentication login myauth group myauthservers local
Switch(config)# line vty 0 15
Switch(config-line)# login authentication myauth

 

Configuring Authorization

After a user is authenticated, the switch allows access to certain services or switch commands based on the user’s privilege level. Authenticated users are put at the EXEC level by default. Certain commands, such as show interface, are available at the EXEC level. Other commands, such as configure terminal, are accessible only if the user is able to move into the privileged EXEC or enable mode.

Authorization provides a means of granting specific users the ability to perform certain tasks. As with authentication, authorization is performed by querying external RADIUS or TACACS+ servers. If the authorization server has an entry for a user and a service or command, the switch allows the user to perform that task.

Configure authorization by first defining any RADIUS or TACACS+ servers that will be used. These normally are defined as part of the authentication configuration and do not need to be redefined for authorization.

Next, define a method list of authorization methods that will be tried in sequence using the following global configuration command:

Switch(config)# aaa authorization {commands | config-commands | configuration | exec | network | reverse-access} {default | list-name} method1 [method2 ...]

 

Here you specify the function or service needing authorization with one of the following keywords:

  • commands: The server must return permission to use any switch command at any privilege level.
  • config-commands: The server must return permission to use any switch configuration command
  • configuration: The server must return permission to enter the switch configuration mode.
  • exec: The server must return permission for the user to run a switch EXEC session. The server also can return the privilege level for the user so that the user immediately can be put into privileged EXEC (enable) mode without having to type in the enable command.
  • network: The server must return permission to use network-related services.
  • reverse-access: The server must return permission for the user to access a reverse Telnet session on the switch.

 

You can identify the method with a descriptive name (list-name) if you are configuring more than one list. Otherwise, a single unnamed list is called the default list. Each authorization method then is listed in the order it will be tried. The methods can be any of the following values:

  • group group-name: Requests are sent to the servers in a specific group.
  • group {radius | tacacs+}: Requests are sent to all servers of this type.
  • if-authenticated: Requests are granted if the user already is authenticated.
  • none: No external authorization is used; every user is authorized successfully.

 

Note: Only TACACS+ servers can authorize users with permission to use specific commands. RADIUS servers offer more of an all-or-nothing approach.

 

Next, you can apply an authorization method list to a specific line on the switch. Users accessing the switch through that line will be subject to authorization. Use the following line configuration command syntax:

Switch(config-line)# authorization {commands level | exec | reverse-access} {default | list-name}

 

If you do not use this command, the default group is used for all lines. To configure a switch to use AAA authorization for all lines, you enter the following:

Switch(config)# aaa authorization exec default group myauthservers none

 

The AAA servers contained in the group myauthservers are used as a default method to allow authenticated users into the EXEC mode or any other privilege level granted.

 

Verify TACACS+ Configuration

To verify TACACS+ statistics, use:

Switch# show tacacs

 

Configuring Accounting

The AAA accounting feature tracks the services that users are accessing and the amount of network resources that they are consuming. When AAA accounting is enabled, the switch reports user activity to the TACACS+ security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can then be analyzed for network management, client billing, or auditing.

This accounting information can be collected by RADIUS and  TACACS+ servers. Again, the RADIUS and TACACS+ servers must already be configured and grouped as part of the authentication configuration.

As usual, you must define a method list giving a sequence of accounting methods by using the following global configuration command syntax:

Switch(config)# aaa accounting {system | exec | commands level} {default | list-name} {start-stop | stop-only | wait-start | none} method1 [method2...]

 

The function triggering the accounting can be one of the following keywords:

  • system: Major switch events such as a reload are recorded.
  • exec: User authentication into an EXEC session is recorded, along with information about the user’s address and the time and duration of the session.
  • commands level: Information about any command running at a specific privilege level is recorded, along with the user who issued the command. You can specify that certain types of accounting records be sent to the accounting server using the following keywords:
    start-stop: Events are recorded when they start and stop.
    stop-only: Events are recorded only when they stop.
    none: No events are recorded.

 

Next, you can apply an accounting method list to a specific line on the switch. Users accessing the switch through that line will have their activity recorded. Use the following line-configuration command to accomplish this:

Switch(config-line)# accounting {commands level | connection | exec} {default | list-name}

 

If you do not use this command, the default group will be used for all lines. Below, AAA accounting is configured for all lines on the switch, using the AAA servers contained in the myauthservers group (in previous example). User EXEC sessions will be recorded as they start and stop, along with user information. Any commands that are entered while a user is in privilege level 15 (enable mode) will be recorded, too.

Switch(config)# aaa accounting exec default start-stop group myauthservers
Switch(config)# aaa accounting commands 15 default start-stop group myauthservers

 

Local privilege authorization fallback

The following examples show how to use a TACACS+ server to authorize the use of network services, including PPP and ARA. If the TACACS+ server is not available or an error occurs during the authorization process, the fallback method (none) is to grant all authorization requests:

Switch# aaa authorization network default group tacacs+ none

 

 

Hope this helps someone else!

CCNP SWITCH 300-115 – Part 2.0 – Infrastructure Security

Background

Malicious users can send spoofed information to trick switches or other hosts into using a rogue machine as a gateway. The attacker’s goal is to become the Man-In-The-Middle, with a naive user sending packets to the attacker as if it were a router. The attacker can glean information from the packets sent to it before it forwards them normally. In this post I’ll describe three Cisco Catalyst features—DHCP Snooping, IP Source Guard, and Dynamic ARP Inspection—that prevent certain types of spoofing attacks.

 

DHCP Server

The DHCP server assigns IP addresses from specified address pools on a switch or router to DHCP clients and manages them. If the DHCP server cannot give the DHCP client the requested configuration parameters from its database, it forwards the request to one or more secondary DHCP servers defined by the network administrator.

 

DHCP Relay Agent

A DHCP relay agent is a Layer 3 device that forwards DHCP packets between clients and servers. Relay agents forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is different from the normal Layer 2 forwarding, in which IP datagrams are switched transparently between networks. Relay agents receive DHCP messages and generate new DHCP messages to send on output interfaces.

 

DHCP Snooping

DHCP snooping is a DHCP security feature that provides network security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding database, also referred to as a DHCP snooping binding table.

DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. You use DHCP snooping to differentiate between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch.

 

DHCP Information Option (Option 82) 

Commonly used in metro or large enterprise deployments to provide additional information on “physical attachment” of the client. Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays insert additional information to identify the client’s point of attachment.

Note: The DHCP option-82 feature is supported only when DHCP snooping is globally enabled and on the VLANs to which subscriber devices using this feature are assigned.

DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero. Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!)

 

DHCP Snooping

A DHCP server normally provides all the basic information a client PC needs to operate on a network. The client might receive an IP address, a subnet mask, a default gateway address, DNS addresses, Default gateway, and so on.

Suppose that an attacker could bring up a rogue DHCP server on a machine in the same subnet as that same client PC. Now when the client broadcasts its DHCP request, the rogue server could send a carefully crafted DHCP reply with its own IP address substituted as the default gateway (man in the middle attack).

When the client receives the reply, it begins using the spoofed gateway address. Packets destined for addresses outside the local subnet then go to the attacker’s machine first. The attacker can forward the packets to the correct destination, but in the meantime, it can examine every packet that it intercepts. In effect, this becomes a type of man-in-the-middle attack, the attacker is wedged into the path and the client does not realize it (its transparent for clients).

Cisco switches can use the DHCP Snooping feature to help mitigate this type of attack. When DHCP Snooping is enabled, switch ports are categorized as trusted or untrusted. Legitimate DHCP servers can be found on trusted ports, whereas all other hosts sit behind untrusted ports.

A switch intercepts all DHCP requests coming from untrusted ports before flooding them throughout the VLAN. Any DHCP replies coming from an untrusted port are discarded because they must have come from a rogue DHCP server. In addition, the offending switch port automatically is shut down in the errdisable state.

 

DHCP Snooping Binding Database

DHCP snooping also keeps track of the completed DHCP bindings as clients receive legitimate replies. This database contains the client MAC address, IP address offered, lease time, and so on.

When DHCP snooping is enabled, the switch uses the DHCP snooping binding database to store information about untrusted interfaces. The database can have up to 8192 bindings.

Configure DHCP snooping first by enabling it globally on a switch with the following configuration command:

Switch(config)# ip dhcp snooping

 

Identify the VLANs where DHCP snooping should be implemented with the following command:

Switch(config)# ip dhcp snooping vlan 10,20

Note:  You can give a single VLAN number as vlan-id or a range of VLAN numbers by giving the start and end VLAN IDs of the range.

 

By default, all switch ports are assumed to be untrusted so that DHCP replies are not expected or permitted. Only trusted ports are allowed to send DHCP replies. You should identify only the ports where known, trusted DHCP servers are located. You can do this with the following interface command:

Switch(config)# interface gi0/0/1
Switch(config-if)# ip dhcp snooping trust

 

For untrusted ports, an unlimited rate of DHCP requests is accepted. If you want to ratelimit DHCP traffic on an untrusted port, use the following interface command:

Switch(config)# interface gi0/0/10
Switch(config-if)# ip dhcp snooping limit rate 20

 

The rate can be 1 to 2048 DHCP packets per second. You also can configure the switch to use DHCP option-82, the DHCP Relay Agent
Information option, which is described in RFCs 3046 and 6607. When a DHCP request is intercepted on an untrusted port, the switch adds its own MAC address and the switch port identifier into the option-82 field of the request. The request then is forwarded normally so that it can reach a trusted DHCP server.

Adding option-82 provides more information about the actual client that generated the DHCP request. In addition, the DHCP reply (if any) echoes back the option-82 information. The switch intercepts the reply and compares the option-82 data to confirm that the request came from a valid port on itself. This feature is enabled by default. You can enable or disable option-82 globally with the following configuration command:

Switch(config)# [no] ip dhcp snooping information option

 

Display its status with the following command:

Switch# show ip dhcp snooping [binding]

 

Note: You can use the binding keyword to display all the known DHCP bindings that have been overheard. The switch maintains these in its own database. Otherwise, only the switch ports that are trusted or that have rate limiting applied are listed. All other ports are considered to be untrusted with an unlimited DHCP request rate.

 

Example, interfaces Gigabit Ethernet 1/0/35 and 1/0/36 use access VLAN 104, are considered untrusted, and have DHCP rate limiting applied at three per second. A known  DHCP server is located on the Gigabit Ethernet 1/1/1 uplink. Bellow shows the configuration for this scenario.

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 104
Switch(config)# interface range gigabitethernet 1/0/35 – 36
Switch(config-if)# ip dhcp snooping limit rate 3
Switch(config-if)# interface gigabitethernet 1/1/1
Switch(config-if)# ip dhcp snooping trust

 

Display DHCP Snooping Status

Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
104
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
GigabitEthernet1/0/35 no 3
GigabitEthernet1/0/36 no 3
GigabitEthernet1/1/1 yes unlimited
Switch#

 

Displays the DHCP snooping configuration for a switch

Switch# show ip dhcp snooping

Displays only the dynamically configured bindings in the DHCP snooping binding database, also referred to as a binding table.

Switch# show ip dhcp snooping binding

 

Displays the DHCP snooping binding database status and statistics.

Switch# show ip dhcp snooping database

 

Displays the DHCP snooping statistics in summary or detail form.

Switch# show ip dhcp snooping statistics

 

Display the dynamically and statically configured bindings.

Switch# show ip source binding

 

IP Source Guard

Address spoofing is one type of attack that can be difficult to mitigate. Normally, a host is assigned an IP address and is expected to use that address in all the traffic it sends out. IP addresses are effectively used on the honor system, where hosts are trusted to behave themselves and use their own legitimate source addresses.

A compromised PC does not necessarily play by those rules. It can use its legitimate address, or it can begin to use spoofed addresses—borrowed from other hosts or used at random. Spoofed addresses are often used to disguise the origin of DoS attacks. If the source address does not really exist, no return traffic will find its way back to the originator.

Routers or Layer 3 devices can perform some simple tests to detect spoofed source addresses in packets passing through. For example, if the 10.10.0.0 network is known to exist on VLAN 10, packets entering from VLAN 20 should never have source addresses in that subnet.

It’s difficult to detect spoofed addresses when they are used inside the VLAN or subnet where they should already exist. For example, within the 10.10.0.0 network on  VLAN 10, as shown bellow, a rogue host begins to send packets with a spoofed source address of 10.10.10.10. The 10.10.10.10 address is certainly within the 10.10.0.0/16 subnet, so it does not stand out as an obvious spoof. Therefore, the rogue host might be very successful in attacking other hosts in its own subnet or VLAN.

Cisco switches can use the IP Source Guard feature to detect and suppress address spoofing attacks, even if they occur within the same subnet. A Layer 2 switch, and a Layer 2 port in turn, normally learns and stores MAC addresses. The switch must have a way to look up MAC addresses and find out what IP address are associated with them.

Spoofed Source Address

 

 

 

 

 

IP Source Guard does this by making use of the DHCP snooping database and static IP source binding entries. If DHCP snooping is configured and enabled, the switch learns the MAC and IP addresses of hosts that use DHCP.

Packets arriving on a switch port can be tested for one of the following conditions:

  • The source IP address must be identical to the IP address learned by DHCP snooping or a static entry. A dynamic port access control list (ACL) is used to filter traffic. The switch automatically creates this ACL, adds the learned source IP address to the ACL, and applies the ACL to the interface where the address is learned.
  • The source MAC address must be identical to the MAC address learned on the switch port and by DHCP snooping. Port security is used to filter traffic.

 

 

If the address is something other than the one learned or statically configured, the switch drops the packet. To configure IP Source Guard, first configure and enable DHCP snooping. If you want IP Source Guard to detect spoofed MAC addresses, you also need to configure and enable port security.

For the hosts that do not use DHCP, you can configure a static IP source binding with the following command:

Switch(config)# ip source binding mac-address vlan 10 ip-address interface gi0/0/10

Here, the host’s MAC address is bound to a specific VLAN and IP address, and is expected to be found on a specific switch interface.

Next, enable IP source guard on one or more switch interfaces with the following commands:

Switch(config)# interface gi0/0/5
Switch(config-if)# ip verify source [port-security]

 

To summ it up, IP source guard is a security feature that restricts IP traffic on nonrouted, Layer 2 interfaces by filtering traffic based on the DHCP snooping binding database and on manually configured IP source bindings. You can use IP source guard to prevent traffic attacks caused when a host tries to use the IP address of its neighbor.

You can enable IP source guard when DHCP snooping is enabled on an untrusted interface. After IP source guard is enabled on an interface, the switch blocks all IP traffic received on the interface, except for DHCP packets allowed by DHCP snooping. A port access control list (ACL) is applied to the interface. The port ACL allows only IP traffic with a source IP address in the IP source binding table and denies all other traffic.

Note: As with all port ACLs, this port ACL takes precedence over any router ACLs or VLAN maps that affect the same interface.

The IP source binding table has bindings that are learned by DHCP snooping or are manually configured (static IP source bindings). An entry in this table has an IP address, its associated MAC address, and its associated VLAN number. The switch uses the IP source binding table only when IP source guard is enabled.

IP source guard is supported only on Layer 2 ports, including access and trunk ports. You can configure IP source guard with source IP address filtering or with source IP and MAC address filtering.

 

Source IP Address Filtering

When IP source guard is enabled with this option, IP traffic is filtered based on the source IP address. The switch forwards IP traffic when the source IP address matches an entry in the DHCP snooping binding database or a binding in the IP source binding table.

When a DHCP snooping binding or static IP source binding is added, changed, or deleted on an interface, the switch modifies the port ACL using the IP source binding changes, and re-applies the port ACL to the interface.

If you enable IP source guard on an interface on which IP source bindings (dynamically learned by DHCP snooping or manually configured) are not configured, the switch creates and applies a port ACL that denies all IP traffic on the interface. If you disable IP source guard, the switch removes the port ACL from the interface.

 

Source IP and MAC Address Filtering

When IP source guard is enabled with this option, IP traffic is filtered based on the source IP and MAC addresses. The switch forwards traffic only when the source IP and MAC addresses match an entry in the IP source binding table.

When IP source guard with source IP and MAC address filtering is enabled, the switch filters IP and non-IP traffic. If the source MAC address of an IP or non-IP packet matches a valid IP source binding, the switch forwards the packet. The switch drops all other types of packets except DHCP packets.

The switch uses port security to filter source MAC addresses. The interface can shut down when a port-security violation occurs.

 

Configure IP Source Guard

Enable IP source guard with source IP and MAC filtering on VLANs 10  and 11:

Switch# config t
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# ip verify source port-security
Switch(config-if)# exit
Switch(config)# ip source binding 0100.0022.0010 vlan 10 10.0.0.2 interface gigabitethernet1/0/1
Switch(config)# ip source binding 0100.0230.0002 vlan 11 10.0.0.4 interface  gigabitethernet1/0/1
Switch(config)# end

Note: The ip verify source command inspects the source IP address only. You can add the port-security keyword to inspect the source MAC address, too. Remember, port-security must be enabled.

 

Verification Commands

Display the IP source bindings on a switch.

Switch# show ip source binding

Display the IP source guard configuration on the switch.

Switch# show ip verify source
Switch# show ip verify source gi0/0/10

 

 

Dynamic ARP Inspection

Hosts normally use the Address Resolution Protocol (ARP) to resolve an unknown MAC address when the IP address is known. If a MAC address is needed so that a packet can be forwarded at Layer 2, a host broadcasts an ARP request that contains the IP address of the target in question. If any other host is using that IP address, it responds with an ARP reply containing its MAC address.

The ARP process works well among trusted and well-behaved users. However, suppose that an attacker could send its own crafted ARP reply when it overhears an ARP request being broadcast. The reply could contain its own MAC address, causing the original requester to think that it is bound to the IP address in question. The requester would add the bogus ARP entry into its own ARP cache, only to begin forwarding packets to the spoofed MAC address.

In effect, this scheme places the attacker’s machine right in the middle of an otherwise legitimate path. Packets will be sent to the attacker instead of another host or the default gateway. The attacker can intercept packets and (perhaps) forward them on only after examining the packets’ contents.

This attack is known as ARP poisoning or ARP spoofing, and it is considered to be a type of man-in-the-middle attack. The attacker wedges into the normal forwarding path, transparent to the end users. Cisco switches can use the dynamic ARP inspection (DAI) feature to help mitigate this type of attack. DAI works much like DHCP snooping. All switch ports are classified as trusted or untrusted. The switch intercepts and inspects all ARP packets that arrive on an untrusted port, no inspection is done on trusted ports.

 

Interface Trust States and Network Security

Dynamic ARP inspection associates a trust state with each interface on the switch. Packets arriving on trusted interfaces bypass all dynamic ARP inspection validation checks, and those arriving on untrusted interfaces undergo the dynamic ARP inspection validation process.

In a typical network configuration, you configure all switch ports connected to host ports as untrusted and configure all switch ports connected to switches as trusted. With this configuration, all ARP packets entering the network from a given switch bypass the security check. No other validation is needed at any other place in the VLAN or in the network. You configure the trust setting by using the ip arp inspection trust interface command.

Note: Use the trust state configuration carefully. Configuring interfaces as untrusted when they should be trusted can result in a loss of connectivity.

 

Rate Limiting of ARP Packets

The switch CPU performs dynamic ARP inspection validation checks; therefore, the number of incoming ARP packets is rate-limited to prevent a denial-of-service attack. By default, the rate for untrusted interfaces is 15 packets per second (pps). Trusted interfaces are not rate-limited. You can change this setting by using the ip arp inspection limit interface command.

When the rate of incoming ARP packets exceeds the configured limit, the switch places the port in the error-disabled state. The port remains in that state until you intervene. You can use the errdisable recovery global command to enable error disable recovery so that ports automatically emerge from this state after a specified timeout period.

 

Relative Priority of ARP ACLs and DHCP Snooping Entries

Dynamic ARP inspection uses the DHCP snooping binding database for the list of valid IP-to-MAC address bindings.

ARP ACLs take precedence over entries in the DHCP snooping binding database. The switch uses ACLs only if you configure them by using the ip arp inspection filter vlan global command. The switch first compares ARP packets to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, the switch also denies the packet even if a valid binding exists in the database populated by DHCP snooping.

 

Logging of Dropped Packets

When the switch drops a packet, it places an entry in the log buffer and then generates system messages on a rate-controlled basis. After the message is generated, the switch clears the entry from the log buffer. Each log entry contains flow information, such as the receiving VLAN, the port number, the source and destination IP addresses, and the source and destination MAC addresses.

You use the ip arp inspection log-buffer global command to configure the number of entries in the buffer and the number of entries needed in the specified interval to generate system messages. You specify the type of packets that are logged by using the ip arp inspection vlan logging global command.

 

Dynamic ARP Inspection Configuration Guidelines

These are the dynamic ARP inspection configuration guidelines:

  • Dynamic ARP inspection is an ingress security feature; it does not perform any egress checking.
  • Dynamic ARP inspection is not effective for hosts connected to switches that do not support dynamic ARP inspection or that do not have this feature enabled. Because man-in-the-middle attacks are limited to a single Layer 2 broadcast domain, separate the domain with dynamic ARP inspection checks from the one with no checking. This action secures the ARP caches of hosts in the domain enabled for dynamic ARP inspection.
  • Dynamic ARP inspection depends on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings in incoming ARP requests and ARP responses. Make sure to enable DHCP snooping to permit ARP packets that have dynamically assigned IP addresses.
  • When DHCP snooping is disabled or in non-DHCP environments, use ARP ACLs to permit or to deny packets.
  • Dynamic ARP inspection is supported on access ports, trunk ports, EtherChannel ports, and private VLAN ports.

 

When an ARP reply is received on an untrusted port, the switch checks the MAC and IP addresses reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured entries or from dynamic entries in the DHCP snooping database. In the latter case, DHCP snooping must be enabled in addition to DAI.

If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log message is generated. This action prevents invalid or spoofed ARP entries from being sent and added to other machines’ ARP caches.

You can configure DAI by first enabling it on one or more client VLANs with the following command:

Switch(config)# ip arp inspection vlan vlan-range

The VLAN range can be a single VLAN ID, a range of VLAN IDs separated by a hyphen, or a list of VLAN IDs separated by commas.

By default, all switch ports associated with the VLAN range are considered to be untrusted. You should identify trusted ports as those that connect to other switches. In other words, the local switch will not inspect ARP packets arriving on trusted ports, it will assume that the neighboring switch also is performing DAI on all of its ports in that VLAN. Configure a trusted port with the following interface command:

Switch(config)# interface type member/module/number
Switch(config-if)# ip arp inspection trust

 

If you have hosts with statically configured IP address information, there will be no DHCP message exchange that can be inspected. Instead, you can configure an ARP access list that defines static MAC-IP address bindings that are permitted. Use the following commands to define the ARP access list and one or more static entries:

Switch(config)# arp access-list acl-name
Switch(config-acl)# permit ip host sender-ip mac host sender-mac [log] [Repeat the previous command as needed]
Switch(config-acl)# exit

 

Now the ARP access list must be applied to DAI with the following command:

Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]

 

When ARP replies are intercepted, their contents are matched against the access list entries first. If no match is found, the DHCP snooping bindings database is checked next. You can give the static keyword to prevent the DHCP bindings database from being checked at all. In effect, this creates an implicit deny statement at the end of the ARP access list, if no match is found in the access list, the ARP reply is considered invalid.

Finally, you can specify further validations on the contents of ARP reply packets. By default, only the MAC and IP addresses contained within the ARP reply are validated. This does not take the actual MAC addresses contained in the Ethernet header of the ARP reply.

To validate that an ARP reply packet is really coming from the address listed inside it, you can enable DAI validation with the following command:

Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}

 

Be sure to specify at least one of the options:

  • src-mac: Check the source MAC address in the Ethernet header against the sender MAC address in the ARP reply.
  • dst-mac: Check the destination MAC address in the Ethernet header against the target MAC address in the ARP reply.
  • IP: Check the sender’s IP address in all ARP requests; check the sender’s IP address against the target IP address in all ARP replies.

 

Below demonstrates where DAI is enabled for all switch ports associated with VLAN 104 on an access layer switch. The uplink to a distribution switch (Gigabit Ethernet 1/0/49) is considered to be trusted.

Configuring DAI to Validate ARP Replies

Switch(config)# ip arp inspection vlan 104
Switch(config)# arp access-list StaticARP
Switch(config-acl)# permit ip host 192.168.1.10 mac host 0006.5b02.a841
Switch(config-acl)# exit
Switch(config)# ip arp inspection filter StaticARP vlan 104
Switch(config)# interface gigabitethernet 1/0/49
Switch(config-if)# ip arp inspection trust

 

Verify Dynamic Arp Inspection

Verify detailed information about ARP ACLs.

Switch# show arp access-list[acl-name]

 

Verify the trust state and the rate limit of ARP packets for the specified interface or all interfaces.

Switch# show ip arp inspection interfaces [interface-id]

 

Verify the configuration and the operating state of dynamic ARP inspection for the specified VLAN. If no VLANs are specified or if a range is specified, displays information only for VLANs with dynamic ARP inspection enabled (active).

Switch# show ip arp inspection vlan vlan-range

 

Clears dynamic ARP inspection statistics.

Switch# clear ip arp inspection statistics

 

Displays statistics for forwarded, dropped, MAC validation failure, IP validation failure, ACL permitted and denied, and DHCP permitted and denied packets for the specified VLAN. If no VLANs are specified or if a range is specified, displays information only for VLANs with dynamic ARP inspection enabled (active).

Switch# show ip arp inspection statistics [vlanvlan-range]

 

Clears the dynamic ARP inspection log buffer.

Switch# clear ip arp inspection log

 

Displays the configuration and contents of the dynamic ARP inspection log buffer.

Switch# show ip arp inspection log

 

Switch Port Security

A network must be secured by controlling what stations can gain access to the network itself. Where user workstations are stationary, their MAC addresses always can be expected to connect to the same access layer switch ports. If stations are mobile, their MAC addresses can be learned dynamically or added to a list of addresses to expect on a switch port.

Catalyst switches offer the port security feature to control port access based on MAC addresses. To configure port security on an access layer switch port, begin by enabling it on a per-interface basis with the following interface-configuration command:

Switch(config-if)# switchport port-security

 

Next, you must identify a set of allowed MAC addresses so that the port can grant them access. You can explicitly configure addresses or they can be learned dynamically from port traffic. On each interface that uses port security, specify the maximum number of MAC addresses that will be allowed access using the following interface command:

Switch(config-if)# switchport port-security maximum max-addr

 

By default, port security will make sure that only one MAC address will be allowed access on each switch port. You can set the maximum number of addresses in the range of 1 to 1024.

Each interface using port security dynamically learns MAC addresses by default and expects those addresses to appear on that interface in the future. MAC addresses are learned as hosts transmit frames on an interface. The interface learns up to the maximum number of addresses allowed. Learned addresses also can be aged out of the table if those hosts are silent for a period of time. By default, no aging occurs.
To set the maximum number of MAC addresses that can be active on a switch port at any time to two, you could use the following command:

Switch(config-if)# switchport port-security maximum 2

 

By default, port security learns MAC addresses dynamically and stores them in the CAM table and also in the running configuration. If the switch reboots for some reason, port security will have to relearn a new set of MAC addresses. To make the learned addresses persistent across a switch reboot, you can enable “sticky” MAC address learning with the following command:

Switch(config-if)# switchport port-security mac-address sticky

 

You can also statically define one or more MAC addresses on an interface. Any of these addresses are allowed to access the network through the port. Use the following interface command to define a static address:

Switch(config-if)# switchport port-security mac-address mac-addr

 

If the number of static addresses configured is less than the maximum number of addresses secured on a port, the remaining addresses are learned dynamically. Be sure to set the maximum number appropriately.

Use the following command to configure a static address entry on an interface, so that 0006.5b02.a841 will be expected:

Switch(config-if)# switchport port-security mac-address 0006.5b02.a841

 

Define how each interface using port security should react if a MAC address is in violation by using the following interface-configuration command:

Switch(config-if)# switchport port-security violation {shutdown | restrict |protect}

 

A violation occurs if more than the maximum number of MAC addresses are learned or if an unknown (not statically defined) MAC address attempts to transmit on the port. The switch port takes one of the following configured actions when a violation is detected:

  • Shutdown: The port immediately is put into the errdisable state, which effectively shuts it down. It must be reenabled manually or through errdisable recovery to be used again.
  • Restrict: The port is allowed to stay up, but all packets from violating MAC addresses are dropped. The switch keeps a running count of the number of violating packets and can send an SNMP trap and a syslog message as an alert of the violation.
  • Protect: The port is allowed to stay up, as in the restrict mode. Although packets from violating addresses are dropped, no record of the violation is kept.

 

As an example of the restrict mode, a switch interface has received the following configuration commands:

interface GigabitEthernet1/0/11
switchport access vlan 991
switchport mode access
switchport port-security
switchport port-security violation restrict
spanning-tree portfast

 

When the default maximum of one MAC address is exceeded on this interface, the condition is logged but the interface stays up. This is shown by the following syslog message:

Jun 3 17:18:41.888 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0000.5e00.0101 on port GigabitEthernet1/0/11.

 

Note: If an interface is undergoing the restrict or protect condition, you might need to clear the learned MAC addresses so that a specific host can use the switch port. You can clear a MAC address or the complete port cache with the following command:

Switch# clear port-security {all | configured | dynamic | sticky} [address mac-addr | interface type member/mod/num]

 

In the shutdown mode, the port security action is much more drastic. When the maximum number of MAC addresses is exceeded, the following syslog messages indicate that the port has been shut down in the errdisable state:

Jun 3 17:14:19.018 EDT: %PM-4-ERR_DISABLE: psecure-violation error detected on
Gi1/0/11, putting Gi1/0/11 in err-disable state
Jun 3 17:14:19.022 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation
occurred, caused by MAC address 0003.a089.efc5 on port GigabitEthernet1/0/11.
Jun 3 17:14:20.022 EDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet1/0/11, changed state to down
Jun 3 17:14:21.023 EDT: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/11, changed
state to down

 

Verify Port Security Port Status

Switch# show port-security interface gigabitethernet 1/0/11
Port Security : Enabled
Port Status : Secure-shutdown
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 0
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address : 0003.a089.efc5
Security Violation Count : 1
Switch#

 

Verify Summary Information for Ports in the Errdisable State

Switch# show interfaces status err-disabled
Port Name Status Reason
Gi1/0/11 Test port err-disabled psecure-violation
Switch#

 

When a port is moved to the errdisable state, you must either manually cycle it or configure the switch to automatically re-enable ports after a prescribed delay. To manually cycle a port and return it to service, use the following commands:

Switch(config)# interface type member/mod/num
Switch(config-if)# shutdown
Switch(config-if)# no shutdown

 

Verify Port Security Status Summary Information

Switch# show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
---------------------------------------------------------------------------
Gi1/0/11 5 1 0 Restrict
Gi1/0/12 1 0 0 Shutdown
---------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port) : 0
Max Addresses limit in System (excluding one mac per port) : 6176
Switch#

 

Private VLANs

Normally, traffic is allowed to move unrestricted within a VLAN. Packets sent from one host to another normally are heard only by the destination host because of the nature of Layer 2 switching.

However, if one host broadcasts a packet, all hosts on the VLAN must listen. You can use a VACL to filter packets between a source and destination in a VLAN if both connect to the local switch.

Sometimes it would be nice to have the capability to segment traffic within a single VLAN, without having to use multiple VLANs and a router. For example, in a singleVLAN server farm, all servers should be capable of communicating with the router or  gateway, but the servers should not have to listen to each other’s broadcast traffic. Taking this a step further, suppose that each server belongs to a separate organization. Now each server should be isolated from the others but still be capable of reaching the gateway to find clients not on the local network.

Another application is a service provider network. Here, the provider might want to use a single VLAN to connect to several customer networks. Each customer needs to be able to contact the provider’s gateway on the VLAN. Clearly, the customer sites do not need to interact with each other.

Private VLANs (PVLANs) solve this problem on Catalyst switches. In a nutshell, a normal, or primary, VLAN can be logically associated with special unidirectional, or secondary, VLANs. Hosts associated with a secondary VLAN can communicate with ports on the primary VLAN (a router, for example), but not with another secondary VLAN. A secondary VLAN is configured as one of the following types:

  • Isolated: Any switch ports associated with an isolated VLAN can reach the primary VLAN but not any other secondary VLAN. In addition, hosts associated with the same isolated VLAN cannot reach each other. They are, in effect, isolated from everything except the primary VLAN.
  • Community: Any switch ports associated with a common community VLAN can communicate with each other and with the primary VLAN but not with any other secondary VLAN. This provides the basis for server farms and workgroups within an organization, while giving isolation between organizations.

 

All secondary VLANs must be associated with one primary VLAN to set up the unidirectional relationship. Private VLANs are configured using special cases of regular VLANs. However, the VLAN Trunking Protocol (VTP) does not pass any information about the private VLAN configuration. Therefore, private VLANs are only locally significant to a switch. Each of the private VLANs must be configured locally on each switch that interconnects them.

You must configure each physical switch port that uses a private VLAN with a VLAN association. You also must define the port with one of the following modes:

  • Promiscuous: The switch port connects to a router, firewall, or other common gateway device. This port can communicate with anything else connected to the primary or any secondary VLAN. In other words, the port is in promiscuous mode, in which the rules of private VLANs are ignored.
  • Host: The switch port connects to a regular host that resides on an isolated or community VLAN. The port communicates only with a promiscuous port or ports on the same community VLAN.

 

Below shows the basic private VLAN operation. Some host PCs connect to a secondary community VLAN. The two community VLANs associate with a primary VLAN, where the router connects. The router connects to a promiscuous port on the primary VLAN. A single host PC connects to a secondary isolated VLAN, so it can communicate only with the router’s promiscuous port.

Private VLAN Functionality

 

 

 

 

 

 

 

 

 

 

 

Private VLAN Configuration

Defining a private VLAN involves several configuration steps.

Begin by defining any secondary VLANs that are needed for isolation using the following commands:

Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan {isolated | community}

 

The secondary VLAN can be an isolated VLAN (no connectivity between isolated ports) or a community VLAN (connectivity between member ports).

Define the primary VLAN that will provide the underlying private VLAN connectivity using the following commands:

Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association {secondary-vlan-list | add secondary-vlan-list | remove secondary-vlan-list}

 

Be sure to associate the primary VLAN with all its component secondary VLANs using the association keyword. If the primary VLAN already has been configured, you can add (add) or remove (remove) secondary VLAN associations individually. These VLAN configuration commands set up only the mechanisms for unidirectional connectivity from the secondary VLANs to the primary VLAN. You also must associate the individual switch ports with their respective private VLANs.

 

Associate Ports with Private VLANs

Define the function of the port that will participate on a private VLAN using the following command:

Switch(config-if)# switchport mode private-vlan {host | promiscuous}

 

If the host connected to this port is a router, firewall, or common gateway for the VLAN, use the promiscuous keyword. This allows the host to reach all other promiscuous, isolated, or community ports associated with the primary VLAN. Otherwise, any isolated or community port must receive the host keyword.

For a non-promiscuous port (using the switchport mode private-vlan host command), you must associate the switch port with the appropriate primary and secondary VLANs. Only the private VLANs themselves have been configured until now. The switch port must know how to interact with the various VLANs using the following interface command:

Switch(config-if)# switchport private-vlan host-association primary-vlan-id secondary-vlan-id

 

Note: When a switch port is associated with private VLANs, you do not have to configure a static access VLAN. Instead, the port takes on membership in the primary and secondary VLANs simultaneously. This does not mean that the port has a fully functional assignment to multiple VLANs. Instead, it takes on only the unidirectional behavior between the secondary and primary VLANs.

 

For a promiscuous port (using the switchport mode private-vlan promiscuous command), you must map the port to primary and secondary VLANs. Notice that promiscuous mode ports, or ports that can communicate with any other private VLAN device, are mapped, whereas other secondary VLAN ports are associated. One (promiscuous mode port) exhibits bidirectional behavior, whereas the other (secondary VLAN ports) exhibits unidirectional or logical behavior.

 

Map promiscuous mode ports to primary and secondary VLANs:

Switch(config-if)# switchport private-vlan mapping primary-vlan-id secondary-vlanlist | {add secondary-vlan-list} | {remove secondary-vlan-list}

 

Assume, that the switch below is configured as the next config example. Host PCs on ports Gigabit Ethernet 1/0/1 and 1/0/2 are in community VLAN 10, hosts on ports Gigabit Ethernet 1/0/4 and 1/0/5 are in community VLAN 20, and the host on port Gigabit Ethernet 1/0/3 is in isolated VLAN 30. The router on port Gigabit Ethernet 1/0/48 is in promiscuous mode on primary VLAN 100. Each VLAN is assigned a role, and the primary VLAN is associated with its secondary VLANs. Then each interface is associated with a primary and secondary VLAN (if a host is attached) or mapped to the primary and secondary VLANs (if a promiscuous host is attached).

Switch(config)# vlan 10
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 20
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 30
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# vlan 100
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 10,20,30
Switch(config-vlan)# exit
Switch(config)# interface range gigabitethernet 1/0/1 - 1/0/2
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 10
Switch(config-if)# exit
Switch(config)# interface range gigabitethernet 1/0/4 - 1/0/5
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 20
Switch(config-if)# exit
Switch(config)# interface gigabitethernet 1/0/3
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 30
Switch(config-if)# exit
Switch(config)# interface gigabitethernet 1/0/48
Switch(config-if)# switchport mode private-vlan promiscuous
Switch(config-if)# switchport private-vlan mapping 100 10,20,30

Private VLAN Functionality

 

 

 

 

 

 

 

 

 

 

Associate Secondary VLANs to a Primary VLAN SVI

On SVI’s configured with Layer 3 addresses, you must configure some additional private VLAN mapping. Example, where the SVI for the primary VLAN, VLAN 200, has an IP address and participates in routing traffic. Secondary VLANs 40 (an isolated VLAN) and 50 (a community VLAN) are associated at Layer 2 with primary VLAN 200 using the configuration below.

Switch(config)# vlan 40
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# vlan 50
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 200
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 40,50
Switch(config-vlan)# exit
Switch(config)# interface vlan 200
Switch(config-if)# ip address 192.168.199.1 255.255.255.0

 

Primary VLAN 200 can forward traffic at Layer 3, but the secondary VLAN associations with it are good at only Layer 2. To allow Layer 3 traffic switching coming from the secondary VLANs as well, you must add a private VLAN mapping to the primary VLAN SVI interface, using the following interface command syntax:

Switch(config-if)# private-vlan mapping {secondary-vlan-list | add secondary-vlanlist | remove secondary-vlan-list}

 

The primary VLAN SVI function is extended to the secondary VLANs instead of requiring SVIs for each of them. If some mapping already has been configured for the primary VLAN SVI, you can add or remove secondary VLAN mappings individually.

Continuing with the example configuration above , you would map the private VLAN by adding the following commands:

Switch(config)# interface vlan 200
Switch(config-if)# private-vlan mapping 40,50

 

Securing VLAN Trunks

Because trunk links usually are bounded between two switches, you might think that they are more or less secure. Each end of the trunk is connected to a device that is under your control, VLANs carried over the trunk remain isolated, and so on.

Some exploits can be leveraged to gain access to a trunk or to the VLANs carried over a trunk. Therefore, you should become familiar with how the attacks work and what steps you can take to prevent them in the first place.

 

Switch Spoofing

With the post “VLANs and Trunks,” two switches can be connected by a common trunk link that can carry traffic from multiple VLANs. The trunk does not have to exist all the time. The switches dynamically can negotiate its use and its encapsulation mode by exchanging DTP messages.

Although DTP can make switch administration easier, it also can expose switch ports to be compromised. Suppose that a switch port is left to its default configuration, in which the trunking mode is auto. Normally, the switch port would wait to be asked by another switch in the auto or on mode to become a trunk.

Now suppose that an end user’s PC is connected to that port. A well-behaved end user would not use DTP at all, so the port would come up in access mode with a single-access VLAN. A malicious user in turn, might exploit the use of DTP and attempt to negotiate a trunk with the switch port. This makes the PC appear to be another switch, thus the PC is spoofing a switch.

After the trunk is negotiated, the attacker has access to any VLAN that is permitted to pass over the trunk. If the switch port has been left to its default configuration, all VLANs configured on the switch are allowed onto the trunk. Below shows this scenario in which the attacker can receive any traffic being sent over the trunk on any VLAN. In addition, he can send traffic into any VLAN of his choice.

Switch Spoofing

 

 

 

 

 

 

 

To demonstrate this further, consider the next output, which shows the default access switch port configuration. Notice that trunking is possible because the port is set to dynamic auto mode, awaiting DTP negotiation from a connected device. If a trunk is negotiated, all VLANs are permitted to be carried over it.

Switch# show interfaces gigabitethernet 1/0/46 switchport
Name: Gi1/0/46
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
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
Switch#

 

The solution is to configure every switch port to have an expected and controlled behavior, instead of leaving an end-user switch port set to use DTP in auto mode, configure it to static access mode with the following commands:

Switch(config)# interface gi1/0/46
Switch(config-if)# switchport access vlan vlan-id
Switch(config-if)# switchport mode access

 

An end user will never be able to send any type of spoofed traffic that will make the switch port begin trunking. In addition, you need to disable any unused switch ports to prevent someone from discovering a live port that might be exploited.

 

VLAN Hopping

When securing VLAN trunks, also consider the potential for an exploit called VLAN hopping. Here, an attacker positioned on one access VLAN can craft and send frames with spoofed 802.1Q tags so that the packet payloads ultimately appear on a totally different VLAN, all without the use of a router. For this exploit to work, the following conditions must exist in the network configuration:

  • The attacker is connected to an access switch port.
  • The same switch must have an 802.1Q trunk.
  • The trunk must have the attacker’s access VLAN as its native VLAN.

 

The next scenario shows how VLAN hopping works. The attacker, situated on VLAN 10, sends frames that are doubly tagged as if an 802.1Q trunk were being used. The attacker is not connected to a trunk, he is spoofing the trunk encapsulation to trick the switch into making the frames hop over to another VLAN.

VLAN Hopping Attack Process

 

 

 

 

The regular frame (or malicious payload), in this case, is initially given an 802.1Q tag with the VLAN ID of the target VLAN. Then a second bogus 802.1Q tag is added with the attacker’s access VLAN ID.

When the local switch Switch A receives a doubly tagged frame, it decides to forward it out the trunk interface. Because the first tag has the same VLAN ID as the trunk’s native VLAN, that tag is removed as the frame is sent on the trunk. The switch believes that the native VLAN should be untagged, as it should. Now the second (innermost) tag is exposed on the trunk.

When Switch B receives the frame, it examines any 802.1Q tag it finds. The spoofed tag for VLAN 20 is found, so the tag is removed and the frame is forwarded onto VLAN 20. Now the attacker successfully has sent a frame on VLAN 10 and gotten the frame injected onto VLAN 20, all through Layer 2 switching!

The key to this type of attack revolves around the use of untagged native VLANs. You always should carefully configure trunk links with the following steps:

Step 1. Set the native VLAN of a trunk to a bogus or unused VLAN ID.
Step 2. Prune the native VLAN off both ends of the trunk.

 

Suppose that an 802.1Q trunk should carry only VLANs 10 and 20. You should set the native VLAN to an unused value, such as 800. Then you should remove VLAN 800 from the trunk so that it is confined to the trunk link itself. Below example demonstrates how to accomplish this.

Switch(config)# vlan 800
Switch(config-vlan)# name bogus_native
Switch(config-vlan)# exit
Switch(config)# interface gigabitethernet 1/0/1
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk native vlan 800
Switch(config-if)# switchport trunk allowed vlan remove 800
Switch(config-if)# switchport mode trunk

 

Note: Tip Although maintenance protocols such as CDP, PAgP, and DTP normally are carried over the native VLAN of a trunk, they will not be affected if the native VLAN is removed or manually pruned from the trunk. They still will be sent and received on the native VLAN as a special case even if the native VLAN ID is not in the list of allowed VLANs.

 

An alternative is to force all 802.1Q trunks to add tags to frames for the native VLAN, too. The double-tagged VLAN hopping attack will not work because the switch will not remove the first tag with the native VLAN ID (VLAN 10 in the example). Instead, that tag will remain on the spoofed frame as it enters the trunk. At the far end of the trunk, the same tag will be examined, and the frame will stay on the original access VLAN (VLAN 10).

To force a switch to tag the native VLAN on all its 802.1Q trunks, you can use the following command:

Switch(config)# vlan dot1q tag native

 

Storm control

Storm control prevents traffic on a LAN from being disrupted by a broadcast, multicast, or unicast storm on one of the physical interfaces. A LAN storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. Errors in the protocol-stack implementation, mistakes in network configurations, or users issuing a DoS attack can cause a storm.

Storm control (or traffic suppression) monitors packets passing from an interface to the switching bus and determines if the packet is unicast, multicast, or broadcast. The switch counts the number of packets of a specified type received within the 1-second time interval and compares the measurement with a predefined suppression-level threshold.

Storm control uses one of these methods to measure traffic activity:

• Bandwidth as a percentage of the total available bandwidth of the port that can be used by the broadcast, multicast, or unicast traffic

• Traffic rate in packets per second at which broadcast, multicast, or unicast packets are received

• Traffic rate in bits per second at which broadcast, multicast, or unicast packets are received

With each method, the port blocks traffic when the rising threshold is reached. The port remains blocked until the traffic rate drops below the falling threshold (if one is specified) and then resumes normal forwarding. If the falling suppression level is not specified, the switch blocks all traffic until the traffic rate drops below the rising suppression level. In general, the higher the level, the less effective the protection against broadcast storms.

Note: When the storm control threshold for multicast traffic is reached, all multicast traffic except control traffic, (BDPU and CDP) frames, are blocked. However, the switch does not differentiate between routing updates, such as OSPF, and regular multicast data traffic, so both types of traffic are blocked.

Storm Control is configured on a per-interface basis to monitor traffic that is arriving or being received at the interface. The idea is to take action on frames as they enter the switch and arrive at the internal switching bus, before they are flooded to multiple switch ports. You can configure thresholds for the amount of broadcast, multicast, or unknown unicast traffic and an action to be taken when the thresholds are exceeded.

Note: You configure storm control on a port and enter the threshold level that you want to be used for a particular type of traffic. Because of hardware limitations and the way in which packets of different sizes are counted, threshold percentages are approximations. Depending on the sizes of the packets making up the incoming traffic, the actual enforced threshold might differ from the configured level by several percentage points.

 

First, select an interface where frames might be received and flooded. Then configure a threshold using the following interface configuration command syntax:

Switch(config-if)# storm-control {broadcast | multicast | unicast} level {level [level-low] | bps bps [bps-low] | pps pps [pps-low]}

 

Select the type of threshold with the broadcast, multicast, or unicast keyword. Keep in mind that “unicast” actually means unknown unicast; otherwise, the threshold would limit the volume of normal unicast frames passing through the interface.

You can set the traffic threshold with the level keyword and one of the following keywords and values:

level [level-low]: The threshold is set to a percentage of the interface bandwidth. The level and level-low percentages can be a value with two decimal places from 0.00 to 100.00.

bps bps [bps-low]: The threshold is set to a specific bits per second rate. The bps and bps-low values can range from 0.0 to 10000000000.0 (10 Gbps), with one decimal place.

pps pps [pps-low]: The threshold is set to a specific packets per second rate. The pps and pps-low values can range from 0.0 to 10000000000.0 (10 Gbps), with one decimal place.

 

Storm Control will take action when the flooded traffic rises to the first value, then will stop the action when the traffic falls below that value. You can set a different falling threshold by specifying the second – low value.

 

Note: Rather than counting zeroes for large bps and pps values, you can use k, m, and g to designate kilo-, mega-, and giga- units.

 

You can repeat the storm control command to define separate thresholds for broadcast, multicast, and unknown unicast traffic.
Next, specify the action to be taken when the threshold is exceeded. By default, the excessive frames are simply dropped as they are received. In addition, you can use the following interface configuration command to shut down the interface in errdisable mode or to send an SNMP trap as an alert of a storm condition in progress:

Switch(config-if)# storm-control action {shutdown | trap}

 

Storm Control is enabled for traffic received on interface Gigabit Ethernet 1/0/1. Because there is no storm control action command entered, the default action to drop excessive frames will be taken. When broadcast frames exceed 50 percent of the interface bandwidth, they will be dropped. When the rate of multicast frames exceeds 50,000 packets per second, they will be dropped. Finally, when the volume of unknown unicast frames rises above 20 percent and then stays above 10 percent of the interface bandwidth, they will be dropped, example below.

Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# storm control broadcast level 50
Switch(config-if)# storm control multicast level pps 50k
Switch(config-if)# storm control unicast level 20 10

 

Storm Control Configuration Example

Enable unicast storm control on a port with an 87-percent rising suppression level and a 65-percent falling suppression level:

Switch# configure terminal
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# storm-control unicast level 87 65

 

Enable broadcast address storm control on a port to a level of 20 percent. When the broadcast traffic exceeds the configured level of 20 percent of the total available bandwidth of the port within the traffic-storm-control interval, the switch drops all broadcast traffic until the end of the traffic-storm-control interval:

Switch# configure terminal
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# storm-control broadcast level 20

 

Verify storm control suppression levels set on the interface for the specified traffic type. If you do not enter a traffic type, broadcast storm control settings are displayed.

Switch# show storm-control gigabitethernet1/0/1  [broadcast |multicast | unicast]

 

Hope this helps someone else!

 

CCNP SWITCH 300-115 – Part 1.8 – Chassis Virtualization and Aggregation Technologies

Understanding Switch Stacks

A switch stack is a set of up to nine stacking-capable switches connected through their StackWise Plus or StackWise ports. You can connect only Catalyst 3750-E switches in a stack, or you can connect both Catalyst 3750-E and Catalyst 3750 switches in the stack. Catalyst 3750-E stack members have StackWise Plus ports, and Catalyst 3750 members have StackWise ports. The stack can have one of these configurations:

  • Homogeneous stack— A Catalyst 3750-E-only stack with only Catalyst 3750-E switches as stack members.
  • Mixed stack –A mixed hardware stack with Catalyst 3750-E and 3750 switches as stack members.

As an example, a stack with Catalyst 3750-E and 3750 switches supporting the advanced IP services features.

–A mixed software stack with only Catalyst 3750-E switches supporting different features or only Catalyst 3750 switches supporting different features as stack members.

For example, a Catalyst 3750-E-only stack with some members running the IP base feature set, other members running the IP services feature set, and the remaining members running the advanced IP services feature set.

–A mixed hardware and software stack with the Catalyst 3750-E and 3750 switches supporting different features as stack members.

For example, a stack with the Catalyst 3750-E members running the advanced IP services feature set and the Catalyst 3750 members running the IP services software image.

One of the switches controls the operation of the stack and is called the Stack Master.

The Stack Master and the other switches in the stack are all stack members. The Catalyst 3750-E stack members use the Cisco StackWise Plus technology to work together as a unified system. Layer 2 and Layer 3 protocols present the entire switch stack as a single entity to the network.

The stack master is the single point of stack-wide management. From the stack master, you configure:

  • System-level (global) features that apply to all stack members
  • Interface-level features for each stack member

 

A switch stack is identified in the network by its bridge ID and, if it is operating as a Layer 3 device, its router MAC address. The bridge ID and router MAC address are determined by the MAC address of the stack master. Every stack member is identified by its own stack member number.

All stack members are eligible to be stack masters. If the stack master becomes unavailable, the remaining stack members elect a new stack master from among themselves. The switch with the highest stack member priority value becomes the new stack master.

The system-level features supported on the stack master are supported on the entire switch stack. If a switch in the stack is running the IP base or IP services feature set and the cryptographic (supporting encryption) universal software image, we recommend that this switch be the stack master. Encryption features are unavailable if the stack master is running the IP base or IP services feature set and the noncryptographic software image.

The stack master contains the saved and running configuration files for the switch stack. The configuration files include the system-level settings for the switch stack and the interface-level settings for each stack member. Each stack member has a current copy of these files for back-up purposes.

You manage the switch stack through a single IP address. The IP address is a system-level setting and is not specific to the stack master or to any other stack member. You can manage the stack through the same IP address even if you remove the stack master or any other stack member from the stack.

 

You can use these methods to manage switch stacks:

  • Network Assistant
  • Command-line over a serial connection to the console port of any stack member or the Ethernet management port of a stack member
  • A network management application through SNMP

Use SNMP to manage network features across the switch stack that are defined by supported MIBs. The switch does not support MIBs to manage stacking-specific features such as stack membership and election.

  • CiscoWorks network management software

 

Note: A switch stack is different from a switch cluster. A switch cluster is a set of switches connected through their LAN ports, such as the 10/100/1000 ports.

 

Switch Stack Membership

Each switch supports two stack ports, switches are connected in a daisy-chain fashion, one switch to the next, and one final connection connects the chain into a closed loop. You can think of the stacking cables as an extension of the switching fabric. When frames need to be moved from one physical
switch to another, they are sent across the bidirectional stacking cable loop to get there.

A switch stack has up to nine stack members connected through their StackWise Plus ports. A switch stack always has one stack master.

A standalone switch is a switch stack with one stack member that also operates as the stack master. You can connect one standalone switch to another  to create a switch stack containing two stack members, with one of them as the stack master.

Note Make sure that you power off the switches that you add to or remove from the switch stack.

StackWise

 

 

 

You can connect standalone switches to an existing switch stack to increase the stack membership.

StackWise2

 

 

 

 

If you replace a stack member with an identical model, the new switch functions with exactly the same configuration as the replaced switch, assuming that the new switch is using the same member number as the replaced switch.

The operation of the switch stack continues uninterrupted during membership changes unless you remove the stack master or you add powered-on standalone switches or switch stacks.

Note: After adding or removing stack members, make sure that the switch stack is operating at full bandwidth (64 Gb/s). Press the Mode button on a stack member until the Stack mode LED is on. The last two right port LEDs on all switches in the stack should be green. Depending on the switch model, the last two right ports are 10-Gigabit Ethernet ports or small form-factor pluggable (SFP) module ports (10/100/1000 ports). If one or both of these LEDs are not green on any of the switches, the stack is not operating at full bandwidth.

Adding powered-on switches (merging) causes the stack masters of the merging switch stacks to elect a stack master from among themselves. The re-elected stack master retains its role and configuration and so do its stack members. All remaining switches, including the former stack masters, reload and join the switch stack as stack members. They change their stack member numbers to the lowest available numbers and use the stack configuration of the re-elected stack master.

Removing powered-on stack members causes the switch stack to divide (partition) into two or more switch stacks, each with the same configuration. This can cause an IP address configuration conflict in your network. If you want the switch stacks to remain separate, change the IP address or addresses of the newly created switch stacks. If you did not intend to partition the switch stack:

a. Power off the switches in the newly created switch stacks.

b. Reconnect them to the original switch stack through their StackWise Plus ports.

c. Power on the switches.

 

One advantage of the closed stacking loop is that individual switches can be inserted or removed without breaking the path between switches completely. The ring can be broken to add or remove a switch, but the remaining switches stay connected over the rest of the ring, thus you can make changes to the stack without interrupting its operation.

When switches are connected as a stack, each one still maintains switching functionality, but only one switch becomes the stack master and performs
all of the management functions. In fact, the whole stack is managed through a single IP address. If the master switch fails, other member switches can take over the role.

 

Virtual Switching System (Vss)

Cisco also offers switches that are based on a chassis with slots that can contain multiple switching modules. The chassis must contain a supervisor module that handles all the switch management functions, including things like routing updates and forwarding tables. A chassis can also contain a redundant supervisor module, which can take over in case the current supervisor fails. With platforms like the Cisco Catalyst 4500R, 6500, and 8500, you can configure two identical chassis to work as one logical switch. This is known as a Virtual Switching System (VSS), aka VSS pair.

One supervisor in one of the chassis controls the operation of the logical switch. If it fails, a supervisor in the other chassis can take over. To build the logical switch, the two chassis must be linked together by multiple interfaces that have been configured as a Virtual Switch Link (VSL). Bellow shows two switch chassis operating as a VSS pair.

VSS

 

 

 

 

 

 

Supervisor and Route Processor Redundancy

HSRP, VRRP, and GLBP router or gateway redundancy protocols can provide high availability only for the default gateway addresses. If one of the redundant gateway routers fails, another can pick up the pieces and appear to be the same gateway address. But what happens to the devices that are connected directly to the router that fails? If the switching or routing engine fails, packets probably will not get routed and interfaces will go down.

Some Cisco switches have the capability to provide redundancy for the supervisor engine itself. This is accomplished by having redundant hardware in place within a switch chassis, ready to take over during a failure. You also should consider switch power as a vital part of achieving high availability.

If a switch has a single power supply and a single power cord, the whole switch will fail if the power supply fails or if the power cord is accidentally unplugged. Some switch platforms can have multiple power supplies; if one power supply fails, another immediately takes over the load.

 

Redundant Switch Supervisors

Platforms such as the Catalyst 4500R, 6500, and 6800 can accept two supervisor modules installed in a single chassis. The first supervisor module to successfully boot becomes the active supervisor for the chassis. The other supervisor remains in a standby role, waiting for the active supervisor to fail.

The active supervisor always is allowed to boot and become fully initialized and operational. All switching functions are provided by the active supervisor. The standby supervisor, however, is allowed to boot and initialize only to a certain level. When the active module fails, the standby module can proceed to initialize any remaining functions and take over the active role.

Redundant supervisor modules can be configured in several modes. The redundancy mode affects how the two supervisors handshake and synchronize information. In addition, the mode limits the standby supervisor’s state of readiness. The more ready the standby module is allowed to become, the less initialization and failover time will be required.

You can use the following redundancy modes on Catalyst switches:

  • Route processor redundancy (RPR): The redundant supervisor is only partially booted and initialized. When the active module fails, the standby module must reload every other module in the switch and then initialize all the supervisor functions.
  • Route processor redundancy plus (RPR+): The redundant supervisor is booted, allowing the supervisor and route engine to initialize. No Layer 2 or Layer 3 functions are started, however. When the active module fails, the standby module finishes initializing without reloading other switch modules. This allows switch ports to retain their state.
  • Stateful switchover (SSO): The redundant supervisor is fully booted and initialized. Both the startup and running configuration contents are synchronized between the supervisor modules. Layer 2 information is maintained on both supervisors so that hardware switching can continue during a failover. The state of the switch interfaces is also maintained on both supervisors so that links do not flap during a failover.

 

Note:  Tip Sometimes the redundancy mode terminology can be confusing. In addition to the RPR, RPR+, and SSO terms, you might see single-router mode (SRM) and dual-router mode (DRM). SRM simply means that two route processors (integrated into the supervisors) are being used, but only one of them is active at any time. In DRM, two route processors are active at all times. HSRP usually is used to provide redundancy in DRM.
Although RPR and RPR+ have only one active supervisor, the route processor portion is not initialized on the standby unit. Therefore, SRM is not compatible with RPR or RPR+. SRM is inherent with SSO, which brings up the standby route

 

Configuring the Redundancy Mode

Redundancy modes supported on switch platforms.

RMFT

 

 

 

 

Bellow shows how the supervisor redundancy modes compare with respect to the functions they perform. The shaded functions are performed as the standby supervisor initializes and then waits for the active supervisor to fail. When a failure is detected, the remaining functions must be performed in sequence before the standby supervisor can become fully active. Notice how the redundancy modes get progressively more initialized and ready to become active.

NSF

 

 

 

 

 

You can configure the supervisor redundancy mode by entering the redundancy configuration mode:

Switch(config)# redundancy

 

Next, select the redundancy mode with the following commands syntax:

Switch(config-red)# mode {rpr | rpr-plus | sso}

 

Note:  Upon initial configuration, you must enter the previous commands on both supervisor modules. When the redundancy mode is enabled, you will make all configuration changes on the active supervisor only. The running configuration is synchronized automatically from the active to the standby module.

If you configure RPR+ with the rpr-plus keyword, the supervisor attempts to bring up RPR+ with its peer module. The IOS images must be of exactly the same release before RPR+ will work. If the images differ, the supervisor automatically falls back to RPR mode instead.

Verifying Supervisor Module Redundancy Mode and State:

Switch# show redundancy states

my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary

Unit ID = 2

Redundancy Mode (Operational) = Route Processor Redundancy Plus
Redundancy Mode (Configured) = Route Processor Redundancy Plus
Split Mode = Disabled
Manual Swact = Enabled
Communications = Up

client count = 11
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0
Switch#

The output shows that the switch is using RPR+ and that the second supervisor module (unit ID 2 and “my state”) holds the active role. The other supervisor module is in the standby state and is HOT, meaning that it has initialized as far as the redundancy mode will allow.

 

Configuring Supervisor Synchronization

By default, the active supervisor synchronizes its startup configuration and configuration register values with the standby supervisor. You also can specify other information that should be synchronized.

First, use the following commands to enter the main-cpu configuration mode:

Switch(config)# redundancy
Switch(config-red)# main-cpu

 

Then use the following command to specify the information that will be synchronized:

Switch(config-r-mc)# auto-sync {startup-config | config-register | bootvar}

Note:  You can repeat the command if you need to use more than one of the keywords. To return to the default, use the auto-sync standard command.

 

Nonstop Forwarding

Nonstop forwarding (NSF) is an interactive method that focuses on quickly rebuilding the Routing Information Base (RIB) table after a supervisor switchover. The RIB is used to generate the FIB table for CEF, which is downloaded to any switch modules or hardware that can perform Cisco Express Forwarding (CEF).

Instead of waiting on any configured Layer 3 routing protocols to converge and rebuild the FIB, a router can use NSF to get assistance from other NSF-aware neighbors. The neighbors then can provide routing information to the standby supervisor, allowing the routing tables to be assembled quickly. In short, the Cisco proprietary NSF functions must be built in to the routing protocols on both the router that will need assistance and
the router that will provide assistance.

NSF is supported by the BGP, EIGRP, OSPF, and IS-IS routing protocols. To configure NSF, you must add the following commands to any routing protocol configuration on the switch.

BGP

Switch(config)# router bgp as-number
Switch(config-router)# bgp graceful-restart

 

OSPF

Switch(config)# router ospf process-id
Switch(config-router)# nsf

 

EIGRP

Switch(config)# router eigrp as-number
Switch(config-router)# nsf

 

IS-IS

Switch(config)# router isis [tag]
Switch(config-router)# nsf [cisco | ietf]
Switch(config-router)# nsf interval [minutes]
Switch(config-router)# nsf t3 {manual [seconds] | adjacency}
Switch(config-router)# nsf interface wait seconds

 

Hope this helps someone else!

CCNP SWITCH 300-115 – Part 1.7 – Traffic Mirroring with SPAN & RSPAN

Switched Port Analyzer (SPAN)

Suppose that a problem exists on your network and you want to use a network analyzer/Sniffer to gather data. Of interest is a conversation between two hosts connected to a switch, one on interface Gigabit Ethernet 1/0/1 and the other on Gigabit Ethernet 1/0/47. Both ports are assigned to VLAN 100. Because other devices are already connected there, you must connect your analyzer to a different switch port. If you connect your analyzer to another port on VLAN 100, what will your packet capture show?

Recall that, by definition, switches learn where MAC addresses are located and forward packets directly to those ports. The only time a packet is flooded to ports other than the specific destination is when the destination MAC address has not already been located or when the packet is destined for a broadcast or multicast address. Your packet capture will show only the broadcast and multicast packets that are being flooded to the
analyzer’s switch port. None of the conversation between the two hosts of interest will be overheard.

Catalyst switches can use the Switched Port Analyzer (SPAN) feature to mirror traffic from one source switch port or VLAN to a destination port. This allows a monitoring device, such as a network analyzer/sniffer, to be attached to the destination port for capturing traffic.

When packets arrive on the source port or VLAN, they are specially marked so that they can be copied to the SPAN destination port as they are delivered to the normal destination port. In this way, the packet capture receives an exact copy of the packets that are being forwarded to and from the SPAN source.

 

Understanding SPAN & RSPAN

You can analyze network traffic passing through ports or VLANs by using SPAN or RSPAN to send a copy of the traffic to another port on the switch or on another switch that has been connected to a network analyzer or other monitoring or security device. SPAN copies/mirrors traffic received or sent (or both) on source ports or source VLANs to a destination port for analysis. SPAN does not affect the switching of network traffic on the source ports or VLANs. You must dedicate the destination port for SPAN use. Except for traffic that is required for the SPAN or RSPAN session, destination ports do not receive or forward traffic.

Only traffic that enters or leaves source ports or traffic that enters or leaves source VLANs can be monitored by using SPAN, traffic routed to a source VLAN cannot be monitored. If incoming traffic is being monitored, traffic that gets routed from another VLAN to the source VLAN cannot be monitored, but traffic that is received on the source VLAN and routed to another VLAN can be monitored.

You can use the SPAN or RSPAN destination port to inject traffic from a network security device. If you connect an IDS sensor appliance to a destination port, the IDS device can send TCP reset packets to close down the TCP session of a suspected attacker.

 

There are two types of Switch Port Analyzer

Local SPAN: Both the SPAN source and destination are located on the local switch. The source is one or more switch ports.

Remote SPAN (RSPAN): The SPAN source and destination are located on different switches. Mirrored traffic is copied over a special-purpose VLAN across trunks between switches from the source to the destination.

 

Local SPAN

A local SPAN session exists on only one switch or switch stack. You must identify one or more source interfaces and a destination interface where monitored traffic will be copied or mirrored. Bellow illustrates the basic local SPAN operation where the goal is to monitor all traffic coming from Server1. Interface 5, where Server1 is connected, is the SPAN source. A network analyzer is connected to interface 23, which is the SPAN destination. As Ethernet frames arrive from Server1 on interface 5, the switch makes copies of them and forwards them to the network analyzer.

Local SPAN

 

 

 

 

 

 

Next picture shows how SPAN works with traffic in the opposite direction. In this case, the SPAN session is monitoring traffic going toward Server1. As Ethernet frames exit the switch going toward the SPAN source Server1, they are copied to the SPAN Traffic analyzer. When you configure a SPAN session, you can specify the direction of traffic that will be mirrored, as either received, transmitted, or both.

Local SPAN2

 

 

 

 

 

 

The SPAN source can be identified as one or more physical switch ports on the switch. The ports can belong to the same VLAN or different VLANs. In addition, a trunk port can be used as a SPAN source, causing traffic from all VLANs that are active on the trunk to be copied to the SPAN destination.

You can apply a VLAN filter to the SPAN source to limit which VLANs will be monitored on the trunk. A SPAN source can also be a switch port that is a member of an EtherChannel. In this case, only traffic passing over that physical port in the EtherChannel will be copied to the SPAN destination, allowing you to monitor a single link in the channel. To monitor all traffic passing across an entire EtherChannel, you can identify a port-channel interface as the SPAN source.

To monitor traffic passing within one or more VLANs on the switch, you can identify the VLANs as the SPAN source. This is essentially the same as local SPAN, but is often called VLAN-based SPAN or VSPAN. All switch ports that are active on a source VLAN become sources themselves.
The destination is identified as a physical interface located on the same switch as the source. Frames that are copied or mirrored from the SPAN source are copied into the SPAN destination port’s egress queue. Because the frames are merely copied within the switch, the original data is not affected and is still forwarded normally.
What happens if the SPAN source and destination ports are operating at different speeds? This easily could happen if the source is a VLAN with many hosts, or if the source is a 10-Gigabit Ethernet port and the destination is a Gigabit Ethernet port. Mirrored frames are copied into the destination port’s egress queue, as if normal Layer 2 switching had decided to forward them there. If the destination port becomes congested, the mirrored frames might be dropped from the queue and not transmitted out the destination port, so,  if the bandwidth of SPAN source traffic exceeds that of the SPAN destination port, some mirrored traffic might not be seen at the destination port.

 

Configure Local SPAN

Command syntax and logic is as follows.

Start by defining the source of the SPAN session data, using the following :

Switch(config)# monitor session session-number source {interface type member/mod/num | vlan vlan-id}[rx | tx | both]

 

SPAN sessions must be numbered uniquely using the session-number parameter. If multiple SPAN sources are needed, you can repeat this command. The SPAN source must be a physical switch interface or a Layer 2 VLAN, not a logical VLAN interface or SVI. However, you cannot mix both interfaces and VLANs in the same SPAN session. Instead, you can create separate sessions to monitor each type of source. Traffic can be selected for mirroring based on the direction it is traveling through the SPAN source. For example, you can select only traffic received on the source (rx), only

traffic transmitted from the source (tx), or traffic in both directions (both). By default, both directions are used.

Next, identify the SPAN destination by using the bellow command. Be sure to enter the same session number so that the destination gets bound to the corresponding source:

Switch(config)# monitor session session-number destination interface type member/mod/num [encapsulation replicate]

 

Note: the SPAN destination interface can only transmit mirrored traffic by default. Any frames that are sent into the destination interface are simply dropped. In most cases, the one-way traffic is sufficient because network analyzers only receive frames to be captured and analyzed. If you connect a device that also needs to transmit data back into the network, you can override the default SPAN behavior.

Add the following command syntax to the monitor session destination command to allow ingress traffic:

ingress {dot1q vlan vlan-id | isl | untagged vlan vlan-id

 

Because the SPAN destination interface is not bound to any specific interface or trunking encapsulation, you must specify how the ingress traffic should be handled. If the ingress traffic uses 802.1Q encapsulation, use the dot1q keyword and identify the default VLAN number. If the ingress traffic uses Inter-Switch Link (ISL) encapsulation, enter the isl keyword. Otherwise, if the ingress traffic is not encapsulated, use the untagged keyword
and identify to which VLAN the traffic should be sent.

If the SPAN source is a trunk port, you might want to mirror only traffic from specific VLANs on the trunk. You can specify a list of VLANs with the following command:

Switch(config)# monitor session session-number filter vlan vlan-range

From the previous picture above, suppose you would like to monitor traffic going to and coming from a device connected to interface Gigabit Ethernet 1/0/1. You have connected a network analyzer to interface Gigabit Ethernet1/0/48. Because the source and destination devices are connected to the same logical switch, you can use a local SPAN session to monitor the traffic.

Configuring a Local SPAN Session example

Switch(config)# monitor session 1 source interface gigabitethernet1/0/1 both
Switch(config)# monitor session 1 destination interface gigabitethernet1/0/48

 

Note: When local SPAN is enabled, STP is disabled on the destination port. This allows STP BPDUs to be captured and monitored but also allows the possibility for a bridging loop to form. Never connect a SPAN session’s destination port back into an active network. If the monitored packets need to be sent toward another switch, use RSPAN instead.

You can configure one or more simultaneous SPAN sessions on a Catalyst switch. The number of supported SPAN sessions depends on the switch model. A Catalyst 3750-X can support two sessions, a Catalyst 6500 can support up to 64. Each SPAN session is completely independent because there is no interaction between the mirroring processes of each one.

Set up SPAN session 1 for monitoring source port traffic to a destination port. First, any existing SPAN configuration for session 1 is deleted, and then bidirectional traffic is mirrored from source Gigabit Ethernet port 1 to destination Gigabit Ethernet port 2, retaining the encapsulation method.

Switch(config)# no monitor session 1
Switch(config)# monitor session 1 source interface gigabitethernet1/0/1
Switch(config)# monitor session 1 destination interface gigabitethernet1/0/2 encapsulation replicate
Switch(config)# end

 

Remove port 1 as a SPAN source for SPAN session 1

Switch(config)# no monitor session 1 source interface gigabitethernet1/0/1
Switch(config)# end

 

Disable received traffic monitoring on port 1, which was configured for bidirectional monitoring

Switch(config)# no monitor session 1 source interface gigabitethernet1/0/1 rx

The monitoring of traffic received on port 1 is disabled, but traffic sent from this port continues to be monitored.

 

Remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor received traffic on all ports belonging to VLANs 1 through 3, and send it to destination Gigabit Ethernet port 2. The configuration is then modified to also monitor all traffic on all ports belonging to VLAN 10.

Switch(config)# no monitor session 2
Switch(config)# monitor session 2 source vlan 1 - 3 rx
Switch(config)# monitor session 2 destination interface gigabitethernet1/0/2
Switch(config)# monitor session 2 source vlan 10
Switch(config)# end

 

Creating a Local SPAN Session and Configuring Incoming Traffic

Remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor received traffic on Gigabit Ethernet source port 1, and send it to destination Gigabit Ethernet port 2 with the same egress encapsulation type as the source port, and to enable ingress forwarding with IEEE 802.1Q encapsulation and VLAN 6 as the default ingress VLAN.

Switch(config)# no monitor session 2
Switch(config)# monitor session 2 source gigabitethernet1/0/1 rx
Switch(config)# monitor session 2 destination interface gigabitethernet1/0/2 encapsulation replicate ingress dot1q vlan 6 
Switch(config)# end

 

Specifying VLANs to Filter

Remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor traffic received on Gigabit Ethernet trunk port 2, and send traffic for only VLANs 1 through 5 and VLAN 9 to destination Gigabit Ethernet port 1.

Switch(config)# no monitor session 2
Switch(config)# monitor session 2 source interface gigabitethernet1/0/2 rx
Switch(config)# monitor session 2 filter vlan 1 - 5 , 9
Switch(config)# monitor session 2 destination interface gigabitethernet1/0/1
Switch(config)# end

 

Remote SPAN

In a large switched network or one that is geographically separated, it might not always be convenient to take a network analyzer to the switch where a SPAN source is located. To make SPAN more extensible, Cisco developed the Remote SPAN (RSPAN) feature. With RSPAN, the source and destination can be located on different switches in different locations.

The RSPAN source is identified on one switch where the source is connected, just as with local SPAN. The RSPAN destination is identified on another switch where the mirrored traffic will be collected. Then RSPAN will carry only the mirrored data over a special purpose VLAN across trunk links and intermediate switches between the source and destination. As long as every switch along the way is RSPAN capable, the source can be located at the far-end switch, while the network analyzer might be conveniently located at the switch nearest you.

The bellow example shows a network that uses RSPAN to mirror traffic from the source on Switch A to the destination on Switch C. The switches are connected by trunk links that carry a VLAN that is set aside for RSPAN traffic. At the source switch, mirrored frames are copied and sent toward the RSPAN destination over the RSPAN VLAN. At the destination switch, packets are pulled off the RSPAN VLAN and copied to the RSPAN destination port.

RSPAN VLAN has important differences from a regular VLAN. First, MAC address learning is disabled on the RSPAN VLAN. This is to prevent intermediate switches that transport the RSPAN VLAN from trying to forward the mirrored packets to their real destination MAC addresses.

Note: The purpose of SPAN or RSPAN is to simply mirror or copy interesting frames, not forward them normally.

An RSPAN-capable switch also floods the RSPAN packets out all its ports belonging to the RSPAN VLAN, in an effort to send them toward the RSPAN destination. Intermediate switches have no knowledge of the RSPAN source or destination; they know only of the RSPAN VLAN itself. Therefore, the RSPAN VLAN should be limited to the links that participate in RSPAN transport. In other words, the RSPAN VLAN should be allowed on trunks between switches, but should not be assigned to any other switch ports along the path.

RSPAN

 

 

 

 

 

 

 

Configuration wise, on switch 1 the configuration needed is port 1 as RSPAN source and VLAN 99 as the RSPAN destination. Following the switch path switch2 has no need for configuration and switch3 is then configured with VLAN 99 as the RSPAN source and port 48 as the RSPAN destination.

 

Configuring RSPAN

RSPAN configuration begins with the definition of the special-purpose RSPANVLAN. If you configure the RSPANVLAN on a VTP server, VTP correctly propagates it to other intermediate switches. If you are not using VTP, be sure to configure this VLAN for RSPAN explicitly on each intermediate switch. Otherwise, the RSPAN packets will not be delivered correctly.

If VTP pruning is in use, the RSPAN VLAN will be pruned from unnecessary trunks, limiting the traffic impact in unrelated areas of the network so make sure not to prune the desired VLAN from crossing the trunks.

Best is to create and maintain one or more RSPAN VLANs for the special monitoring purpose only. Set aside one RSPAN VLAN for each RSPAN session that will be used. Do not allow any normal hosts to join an RSPAN VLAN.

 

Configuration guidelines when configuring RSPAN

  • As RSPAN VLANs have special properties, you should reserve a few VLANs across your network for use as RSPAN VLANs; do not assign access ports to these VLANs.
  • You can apply an output ACL to RSPAN traffic to selectively filter or monitor specific packets. Specify these ACLs on the RSPAN VLAN in the RSPAN source switches.
  • For RSPAN configuration, you can distribute the source ports and the destination ports across multiple switches in your network.
  • RSPAN does not support BPDU packet monitoring or other Layer 2 switch protocols.
  • The RSPAN VLAN is configured only on trunk ports and not on access ports. To avoid unwanted traffic in RSPAN VLANs, make sure that the VLAN remote-span feature is supported in all the participating switches.
  • Access ports (including voice VLAN ports) on the RSPAN VLAN are put in the inactive state.
  • RSPAN VLANs are included as sources for port-based RSPAN sessions when source trunk ports have active RSPAN VLANs. RSPAN VLANs can also be sources in SPAN sessions. However, since the switch does not monitor spanned traffic, it does not support egress spanning of packets on any RSPAN VLAN identified as the destination of an RSPAN source session on the switch.

You can configure any VLAN as an RSPAN VLAN as long as these conditions are met:

–The same RSPAN VLAN is used for an RSPAN session in all the switches.

–All participating switches support RSPAN.

 

Define an RSPAN VLAN on each switch between the source and destination with the following configuration commands:

Switch(config)# vlan vlan-id
Switch(config-vlan)# remote-span

 

Next, you must identify the RSPAN source and destination on the two switches where the source and destination are connected. At the source switch, identify the source and destination with the following :

Switch(config)# monitor session session-number source {interface type member/ mod/num | vlan vlan-id}[rx | tx | both]
Switch(config)# monitor session session-number destination remote vlan rspan-vlan-id

 

Here, the source is either a physical switch interface or a Layer 2 VLAN (not an SVI interface). Notice that the syntax is identical to the local SPAN monitor session source command. The RSPAN destination is simply the RSPAN VLAN. This allows the mirrored packets to be copied into the special VLAN and sent on their way toward the final RSPAN destination. As with a local SPAN session, you can also use the monitor session filter command to filter VLANs from a trunk interface that is used as a SPAN source.

At the destination switch, you must again identify the RSPAN source and destination by using the following commands:

Switch(config)# monitor session session-number source remote vlan rspan-vlan-id
Switch(config)# monitor session session-number destination interface type member/mod/num [encapsulation replicate]

 

RSPAN

 

 

 

 

 

 

 

Again, using the last above network design, the source is connected to Switch 1 port Gigabit Ethernet 1/0/1. The destination is a network analyzer connected to port Gigabit Ethernet 1/0/48 on Switch 3. Switch 2 simply passes the RSPAN session traffic over VLAN 99, transported by trunk links to switches 1 and 3. For Switch 2, only the commands relevant to the RSPAN VLAN are listed. The trunk links are assumed to allow VLAN 99 toward Switches 1 and 3.

Configuring RSPAN on Switch 1

Switch(config)# vlan 99
Switch(config-vlan)# remote-span
Switch(config-vlan)# exit
Switch(config)# monitor session 1 source interface gigabitethernet 1/0/1 both
Switch(config)# monitor session 1 destination remote vlan 99

 

Configuring RSPAN on Switch 2

Switch(config)# vlan 99
Switch(config-vlan)# remote-span
Switch(config-vlan)# exit 

 

Configuring RSPAN on Switch 3

Switch(config)# vlan 99
Switch(config-vlan)# remote-span
Switch(config-vlan)# exit
Switch(config)# monitor session 1 source remote vlan 99
Switch(config)# monitor session 1 destination interface gigabitethernet 1/0/48 

 

Managing SPAN Sessions

Like any other configuration commands, the monitor session source and monitor session destination commands are placed into the running configuration of the switch as you enter them. You can display SPAN sessions by searching for the commands in the switch configuration:

Verify SPAN Sessions in the Switch Configuration

Switch# show running-config | include monitor
monitor session 1 source interface Gi1/0/1
monitor session 1 destination interface Gi1/0/48
Switch#

 

You can also see verify about currently active SPAN sessions by entering the show monitor command. By default, all active sessions are displayed. You can use the session keyword to limit the output to specific sessions, all session, only local sessions, or only remote sessions. Command syntax:

Switch# show monitor [session {session-number | all | local | range range-list | remote}] [detail]

 

Verify the Currently Active SPAN Sessions

Switch# show monitor
Session 1
----------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/48
Encapsulation : Native
Ingress : Disabled

Session 2
----------
Type : Remote Source Session
Source Ports :
Both : Gi1/0/1
Dest RSPAN VLAN : 99
Switch#

 

You can delete a SPAN session after the packet analysis is complete. SPAN sessions are numbered, so you can delete them by referencing the session number.

Delete one or more sessions

Switch(config)# no monitor session {session | range session-range} | local | all}

 

Important Note:  Session numbers can be given as an individual session, a range of sessions, all local SPAN sessions, or all sessions (local or remote). When you finish using a SPAN session, you always should disable or delete it, or someone might try to connect to the port that is configured as the SPAN destination. You could spend a good bit of time troubleshooting that user’s connectivity problem only to find that you left a SPAN session active there.

 

Hope this helps someone else!