CCNA Security - L2 Security - Port Security

In this post we will be taking a look at Port Security as it pertains to the CCNA Security 210-260 IINS blueprint.

Port Security as the name of the feature states, is security of the port. It limits the number of MAC address that can be learned and how they are learned. By default there is no port security enabled on a Cisco Catalyst switch. It first has to be enabled and then the different attributes that can be configured can be applied.

Operationally whenever a switch port learns a MAC address, whether through normal ARP or Gratuitous ARP, the MAC address is stored in the CAM table. This table builds a binding for the MAC to Port, so whenever traffic is forwarded and the MAC address is the destination MAC, the CAM table is referenced to determine which port forward the traffic out of. This covers why a MAC address is needed. Why would we ever needed to enable a feature to control how many MAC addresses could be learned?

A practical deployment would be a conference room switchport that has a switch plugged into one of the wall jacks. If the wall jack port is an access port, then multiple MAC addresses could be learned in on that port. This maybe acceptable for some networks but not others. Port Security could be used to limit how many MAC addresses are learned and how they are learned. Then apply some enforcement if a violation occurs. Depending on the violation, re-enabling a port maybe required.


To enable Port Security use the following commands: - Caveat, the port must be static Access

SW1(config-if)#switchport port-security
Command rejected: GigabitEthernet0/0 is a dynamic port.


interface GigabitEthernet0/0
 switchport mode access
 switchport port-security mac-address sticky
 switchport port-security mac-address sticky ca01.133c.0000
 switchport port-security

Step 1 is enable the port as an access port.
Step 2 is enable the port-security feature under the interface
Step 3 is enable the MAC address learning mechanism, in this case we used "sticky"

Do this on all the interfaces that you want to enable this feature on, if enabled with the "sticky" feature, the learned MAC address will be treated as a "static" MAC entry.

interface range g0/0 - 3
switchport mode access
switchport port-security mac-address sticky
switchport port-security

SW1#sh mac address-table
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    ca01.133c.0000    STATIC      Gi0/0
   1    ca02.05f8.0000    STATIC      Gi0/1
   1    ca03.13e8.0000    STATIC      Gi0/2
   1    ca04.0cb4.0000    STATIC      Gi0/3

Total Mac Addresses for this criterion: 4

Since we enabled the port security feature on the interfaces listed above, the learned MAC addresses are learned and stored as static MACs. 

SW1#sh run | in interface|ca
interface GigabitEthernet0/0
 switchport port-security mac-address sticky ca01.133c.0000
interface GigabitEthernet0/1
 switchport port-security mac-address sticky ca02.05f8.0000
interface GigabitEthernet0/2
 switchport port-security mac-address sticky ca03.13e8.0000
interface GigabitEthernet0/3

 switchport port-security mac-address sticky ca04.0cb4.0000

So now that we have it enabled and ports have learned MACs, let's verify everything.


SW1#show port-security
Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action
                (Count)       (Count)          (Count)
---------------------------------------------------------------------------
      Gi0/0              1            1                  0         Shutdown
      Gi0/1              1            1                  0         Shutdown
      Gi0/2              1            1                  0         Shutdown
      Gi0/3              1            1                  0         Shutdown
---------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port)     : 0

Max Addresses limit in System (excluding one mac per port) : 4096


This output lists the MAC addresses that have been learned and how many have been learned. 


SW1#show port-security address
               Secure Mac Address Table
-----------------------------------------------------------------------------
Vlan    Mac Address       Type                          Ports   Remaining Age
                                                                   (mins)
----    -----------       ----                          -----   -------------
   1    ca01.133c.0000    SecureSticky                  Gi0/0        -
   1    ca02.05f8.0000    SecureSticky                  Gi0/1        -
   1    ca03.13e8.0000    SecureSticky                  Gi0/2        -
   1    ca04.0cb4.0000    SecureSticky                  Gi0/3        -
-----------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port)     : 0
Max Addresses limit in System (excluding one mac per port) : 4096

This output lists the addresses learned, the method they were learned by and the port they were learned in on. 


SW1#show port-security address forbidden
----------------------------------
 Globally Forbidden MAC Addresses
----------------------------------
-----------------------------------------
  No of Global Forbidden Addresses : 0


-------------------------------------


       Forbidden Mac Addresses
 ------------------------------------------
 Mac Address        Ports
 -----------        -----
-----------------------------------------
Total Forbidden Addresses in System : 0

This output identifies any MACs that are not allowed to be learned by the switch.

SW1#sh port-security interface g0/0
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 1
Last Source Address:Vlan   : ca01.133c.0000:1
Security Violation Count   : 0

This output shows the details of a given interface, G0/0 here, and the specifics of the port security implementation.
This port has port security enabled.
The status is secure-up meaning that port is security and operationally up.
The violation mode is shutdown meaning that if a violation were to occur, the port would be shutdown.
The total amount of MAC addresses that can be learned in on this interface is 1 which is the configured default once port security is enabled.
The total MAC address is how many MACs have been learned.
Configured MAC addresses is if you manually entered a MAC at the port level.
Sticky MAC addresses is our deployment and we have 1.
The Last Source Address:VLAN, this shows the MAC learned in on the port and the VLAN that port is currently in.

What happens when there is a violation?

R1(config-if)#mac-address 0000.0000.0001
R1(config-if)#do sh int f0/0 | in bia
  Hardware is DEC21140, address is 0000.0000.0001 (bia ca01.133c.0000)

We configure a new MAC on the F0/0 interface of R1. Any traffic that is generated by this router on this interface will be seen with MAC 0000.0000.0001, which will cause an issue. The issue is SW1 on G0/0 has learned a different MAC, the BIA address in (Parenthesis). 

*Sep 22 00:21:21.865: %PM-4-ERR_DISABLE: psecure-violation error detected on Gi0/0, putting Gi0/0 in err-disable state
*Sep 22 00:21:21.873: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0000.0000.0001 on port GigabitEthernet0/0.
*Sep 22 00:21:22.866: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
*Sep 22 00:21:23.868: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down

This output show that a new MAC address was learned in on G0/0 and is a violation, the violation enforcement is to shutdown the port and place the port into err-disable mode.

SW1#sh port-security interface g0/0
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        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 1
Last Source Address:Vlan   : 0000.0000.0001:1
Security Violation Count   : 1

The port is now secure-shutdown. It can not be used currently.

SW1#sh int status

Port      Name               Status       Vlan       Duplex  Speed Type

Gi0/0                        err-disabled 1            auto   auto unknown

To fix this issue we will have to remove the manually configured MAC on R1, shutdown and then no shutdown the G0/0 interface on SW1.

R1(config-if)#no mac-address 0000.0000.0001
R1(config-if)#do sh int f0/0 | in bia

  Hardware is DEC21140, address is ca01.133c.0000 (bia ca01.133c.0000)

SW1(config)#int g0/0
SW1(config-if)#shut
SW1(config-if)#
*Sep 22 00:26:59.642: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
SW1(config-if)#no shut
*Sep 22 00:27:06.441: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*Sep 22 00:27:07.441: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
SW1#sh port-security interface g0/0
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 1
Last Source Address:Vlan   : 0000.0000.0000:0
Security Violation Count   : 0

We can now see that the interface has recovered and no MAC info, Last Source, has been learned. We can generate some traffic from R1 and now populate that field.

R1(config-if)#do ping 10.10.20.20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.20.20, timeout is 2 seconds:
.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 24/69/144 ms

SW1#sh port-security interface g0/0
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 1
Last Source Address:Vlan   : ca01.133c.0000:1

Security Violation Count   : 0

Now the field is populated and all is well. 

Thanks for stopping by!
Rob Riker, CCIE #50693

Security - IOS to IOS Site to Site VPN with Crypto Maps and Pre Shared Keys

I'm back in the saddle again and this time it is with security. My job role has changed where I now do more security, pre sales and implementation. As a Solutions Integration Architect, I design and deploy solutions for customers. Because of the role and focus shift, Security is where I spend my time now. I currently have a CCNA in Security that I earned back in 2013, it's dated and I'm beginning the process of upgrading it to the current standard 210-260 IINS. I won't take the exam, but I will re-learn what I have forgotten and add to what I didn't already know.

IOS to IOS site to site VPNs with crypto maps secured with pre-shared-keys are a very common solution used today by companies all over the world. Very simple in the grand scheme to configure and verify. Our demonstration will consist of 2 CSR1000v's and 2 Windows 7 Pro VMs running in ESXi 6.0. The goal is to setup a VPN on the CSRs to allow the 2 Windows 7 VMs to communicate with each other. Sec-PC1 and Sec-PC4 will be our test devices. I already have this solution working, I will be copying and pasting the working configurations here. R1 and R4 do have reachability with each other, but I will prove this works with a couple of ping/traceroute outputs.

\

R1#ping 10.2.4.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.2.4.4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/20 ms

R4#ping 10.1.1.10

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/20 ms

Since we will be using IKEv1/ISAKMP with pre-shared-keys, the configuration will be relatively basic. 

R1's configuration

!

crypto isakmp policy 10

 encr aes

 hash sha256

 authentication pre-share

 group 2

crypto isakmp key cisco address 10.2.4.4

crypto ipsec transform-set TSET esp-aes esp-sha-hmac

 mode tunnel

crypto map CMAP 1 ipsec-isakmp

 set peer 10.2.4.4

 set transform-set TSET

 match address ACL

 crypto map CMAP

!

ip access-list extended ACL

 permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255

!

interface GigabitEthernet1.11

 crypto map CMAP

R4's configuration

!

crypto isakmp policy 10

 encr aes

 hash sha256

 authentication pre-share

 group 2

crypto isakmp key cisco address 10.1.1.10

crypto ipsec transform-set TSET esp-aes esp-sha-hmac

 mode tunnel

crypto map CMAP 1 ipsec-isakmp

 set peer 10.1.1.10

 set transform-set TSET

 match address ACL

 crypto map CMAP

!

ip access-list extended ACL

 permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255

!

interface GigabitEthernet1.24

 encapsulation dot1Q 24

 ip address 10.2.4.4 255.255.255.0

 crypto map CMAP

Let's breakdown the crypto, access-list and crypto map configuration and understand what is happening. The "isakmp" policy is considered the "phase 1" portion of the VPN, this is configured so that the VPN endpoints each have identical configurations and those configurations are used to prove the endpoints are who they say they are. This is essentially the "control-plane" for VPNs. The ISAKMP policy identifies the "policies" that each endpoint must agree on, if no agreement is found, Phase 1 fails. The "isakmp key" is the private key exchanged between VPN peers used to authenticate each other. The "key cisco" is the actual private key, the address is the remote end of the VPN endpoint.

crypto isakmp policy 10

 encr aes

 hash sha256

 authentication pre-share

 group 2

crypto isakmp key cisco address 10.1.1.10

This portion is the "phase 2" portion of the crypto configuration or the data plane. this identifies the encryption protocol used to protect the data.

crypto ipsec transform-set TSET esp-aes esp-sha-hmac

 mode tunnel

The access-list called ACL is also referred to as the "proxy acl" which basically means, any traffic that is matched in this ACL will be encrypted and sent over the VPN. It is required to match on interesting traffic, it is a data plane filter. The remote end swaps the source and destination, so 192.168.4.0/24 and 192.168.1.0/24 are reversed so that return traffic is appropriately matched.

ip access-list extended ACL

 permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255

The crypto map is what "glues" all of this together, it is identified by the ipsec-isakmp, it sets the remote VPN peer, identifies the encryption protocol and uses the ACL to identify what traffic is to be encrypted.

crypto map CMAP 1 ipsec-isakmp

 set peer 10.1.1.10

 set transform-set TSET

 match address ACL

Now we have to apply the crypto map the outgoing interface. The crypto map can be applied to many outside interfaces, in this case, only one is needed. Once this is applied, there is a syslog generated identifying that ISAKMP is now enabled

interface GigabitEthernet1.24

 crypto map CMAP

R4(config-subif)#crypto map CMAP

R4(config-subif)#exit

R4(config)#i

.Jul 24 01:05:17.161: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

Now, the reason you have read this far, is it actually working? Here is how you verify Phase 1 and Phase 2. The phase 1 shows that R1 and R4 have an active "QM_IDLE" connection, QM being quick mode,  ISAKMP SA is authenticated and can be used for subsequent Quick Mode (Phase 2) exchanges. This indicates that the bidirectional ISAKMP connection is up and the VPN endpoints are successfully authenticated

Phase 1

R4#show crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst             src             state          conn-id status

10.1.1.10       10.2.4.4        QM_IDLE           1004 ACTIVE

Phase 2 is the actual data plane, the thing to look for, bolded, is the pkts encrypt and decrypt. This indicates that the unidirectional SA are both sending and receiving traffic.

Phase 2

R4#show crypto ipsec sa

interface: GigabitEthernet1.24

    Crypto map tag: CMAP, local addr 10.2.4.4

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

   current_peer 10.1.1.10 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 259105, #pkts encrypt: 259105, #pkts digest: 259105

    #pkts decaps: 244184, #pkts decrypt: 244184, #pkts verify: 244184

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

     local crypto endpt.: 10.2.4.4, remote crypto endpt.: 10.1.1.10

     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1.24

     current outbound spi: 0x14644456(342115414)

     PFS (Y/N): N, DH group: none

     inbound esp sas:

      spi: 0x9935538F(2570408847)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 2047, flow_id: CSR:47, sibling_flags FFFFFFFF80000048, crypto map: CMAP

        sa timing: remaining key lifetime (k/sec): (4607554/1027)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

      spi: 0x14644456(342115414)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 2048, flow_id: CSR:48, sibling_flags FFFFFFFF80000048, crypto map: CMAP

        sa timing: remaining key lifetime (k/sec): (4607309/1027)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

Proof from the Windows 7 VMs

This is from Sec-PC1 RDPd into Sec-PC4 where Sec-PC4 is pinging Sec-PC1 repeatedly.

This is from Sec-PC1 ping Sec-PC4 repeatedly. 

Thanks for stopping by!

Rob Riker, CCIE #50693, CCNA Security

CCIE SPv4 - MPLS Traffic Engineering - Directing Traffic to the TE Tunnel - Static Routing

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post, we will begin taking customer traffic and mapping it to the TE tunnel. There are several options available, so we'll take the first option, which you have seen in previous posts, static routing. Super simple to implement, relatively easy to verify, we'll take a look at both IOS and IOS XR for all of our examples. 

Static routing for TE tunnels is the simplest, effectively you are telling the TE headend how to get to the PE remote end. R3 will be sending traffic to XR1, remember that TE tunnels are unidirectional in nature. I have used TE tunnels from previous posts to leverage in this and future ones. I won't focus on tunnel creation but more on the steering of traffic over the tunnel. The tunnel we want to use is up and operational.

mpls traffic-eng lsp attributes DUAL_COLOR

 affinity 0x11 mask 0x11

interface Tunnel3

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.11

 tunnel mpls traffic-eng path-option 3 dynamic attributes DUAL_COLOR

ip route 192.168.1.13 255.255.255.255 Tunnel3

R3#show mpls traffic-eng tunnels tunnel 3

Name: R3_t3                               (Tunnel3) Destination: 192.168.1.11

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 3, type dynamic (Basis for Setup, path weight 2)

!

RSVP Path Info:

      My Address: 10.14.3.3

      Explicit Route: 10.14.3.14 10.11.14.14 10.11.14.11 192.168.1.11

As we can see, the tunnel is up and working, pointing to XR1 in this case.

R3#sh ip route 192.168.1.11

Routing entry for 192.168.1.11/32

  Known via "static", distance 1, metric 0 (connected)

  Routing Descriptor Blocks:

    directly connected, via Tunnel3

      Route metric is 0, traffic share count is 1

Since we have configured a static route to steer traffic over the TE tunnel, we have an exit interface of Tunnel 3.

R3#sh ip cef 192.168.1.11 detail

192.168.1.11/32, epoch 2, flags [attached], per-destination sharing

  local label info: global/30

  3 RR sources [non-eos indirection, heavily shared]

  attached to Tunnel3

We see that the CEF table has allocated a global label of 30 and an exit of Tunnel3.

R3#sh mpls forwarding-table labels 30 detail

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

30         Pop Label  192.168.1.11/32  0             Tu3        point2point

        MAC/Encaps=18/22, MRU=1500, Label Stack{24011}, via Gi1.143

        000C29769933000C290626448100008F8847 05DCB000

        No output feature configured

    Per-destination load-sharing, slots: 0 2 4 6 8 10 12 14

The transport label we'll use is 24011 to get to XR4. We'll do an MPLS traceroute to see if the core is correct.

R3#traceroute mpls traffic-eng tunnel 3

Type escape sequence to abort.

  0 10.14.3.3 MRU 1500 [Labels: 24011 Exp: 0]

L 1 10.14.3.14 MRU 1500 [Labels: implicit-null Exp: 0] 9 ms

! 2 10.11.14.11 8 ms

The core trace looks good. let's verify from R8 to R12.

R8#sh ip route vrf BGP 12.12.12.12

Routing Table: BGP

Routing entry for 12.12.12.12/32

  Known via "bgp 8", distance 20, metric 0

  Tag 50693, type external

  Last update from 83.0.0.3 00:00:12 ago

  Routing Descriptor Blocks:

  * 83.0.0.3, from 83.0.0.3, 00:00:12 ago

      Route metric is 0, traffic share count is 1

      AS Hops 2

      Route tag 50693

      MPLS label: none

We can see that normal BGP route propagation is working as expected. We see a route to R12's lo12121212 in R8's VRF BGP RIB.

R8#traceroute vrf BGP 12.12.12.12 source 8.8.8.8

Type escape sequence to abort.

Tracing the route to 12.12.12.12

VRF info: (vrf in name/id, vrf out name/id)

  1 83.0.0.3 3 msec 1 msec 0 msec

  2 10.14.3.14 [MPLS: Labels 24011/24027 Exp 0] 8 msec 5 msec 6 msec

  3 10.11.14.11 [MPLS: Label 24027 Exp 0] 5 msec 17 msec 20 msec

  4 112.0.0.12 24 msec *  10 msec

Seeing label 24011 as the transport label shows us that the TE tunnel is being used.

Thanks for stopping by!

Rob Riker, CCIE #50693

CCIE SPv4 - MPLS Traffic Engineering - TE Attributes - Auto Bandwidth

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

This post will be a look at "auto-bandwidth or auto-bw". The idea behind this feature is make better use of bandwidth allocation for a tunnel rather than just give the tunnel all the bandwidth that the "bandwidth" command specified. Leveraging just the bandwidth definitely works and has it's use but if you specify 100 Mbps as the bandwidth reservation and the average bandwidth use is 10 Mbps, the tunnel is being under utilized. Auto BW would take a look at the utilization over a given period of time, 5 minutes by default, and allocate the highest bandwidth seen in that period of time to the tunnel. 

interface Tunnel7

 ip unnumbered Loopback0

 load-interval 60

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.6

 tunnel mpls traffic-eng priority 7 7

 tunnel mpls traffic-eng bandwidth 6

 tunnel mpls traffic-eng affinity 0x0 mask 0x0

 tunnel mpls traffic-eng path-option 1 dynamic

 tunnel mpls traffic-eng auto-bw frequency 600 max-bw 100 min-bw 10

R3#show mpls traffic-eng tunnels tunnel 7 | sec auto-bw

    auto-bw: (600/328) 0  Bandwidth Requested: 10

          Samples Missed 0: Samples Collected 0

The auto-bw (600/xxx) means that every 600 seconds, the tunnel will get checked for bandwidth optimization. The "0" next to it would have the bandwidth allocated. Bandwidth requested is 10 here, for 10 Kbps. The drawback in my lab is that the platform limit is 100000 bps. 

R3#sh ip rsvp reservation filter session-type 7 tunnel-id 7

Destination     Tun Sender      TunID LSPID Next Hop        I/F      Fi Serv BPS

192.168.1.6     192.168.1.3     7     7     10.14.3.14      Gi1.143  SE LOAD 6K

As you can see the 6 Kbps of bandwidth reservation are signaled and working. However, since we are requesting less than the minimal limit that the auto-bw option can support, we won't actually see any modification. 

Thanks for stopping by!

Rob Riker, CCIE #50693

CCIE SPv4 - MPLS Traffic Engineering - TE Attributes - Path Options

Software versions:

IOS XE 15.5

IOS XR 5.3

The topology for this demo:

In this post we will take a look at the "path option" feature, which essentially determines how the TE tunnel will calculate its path. We can be either really "lazy" or really involved in this process, lazy with using the dynamic option and letting RSVP go out and find the shortest path and pretty much use IGPs path and call it a day. We could also use the explicit path option which allows us to have more control over where the traffic goes. We haven't covered PE to P LSPs yet for things like H-VPLS TE support, what we'll focus on here is R3 to XR3 and XR3 to R3 LSP signalling. The dynamic path option is the easiest and has been used so far in all of our testing so no reason to really break that out here. Let's focus on the explicit path and start there.

There are several ways to "code" the path, the "ip explicit-path" is the primary way. This method allows us to be really specific or be rather general. General in the sense I can give the path certain IPs that must be in the path and the others I may not care about. Other times I could give per interface path IPs and be really specific. Using the "loose" keyword allow us to specify the node we want to go through, but not necessarily how we go through. The strict keyword pretty much says you have to go through it. 

Our demo will start with leveraging the loose option and just build a TE tunnel path from R3 to XR3. The path we will take is XR4 to XR1 to R1 to XR5 to XR6 to R2 to XR3, not exactly direct but we want to exercise our capabilities. 

R3

ip explicit-path name LOOSE_TO_XR3 enable

 next-address loose 192.168.1.14

 next-address loose 192.168.1.11

 next-address loose 192.168.1.1

 next-address loose 192.168.1.15

 next-address loose 192.168.1.16

 next-address loose 192.168.1.2

 next-address loose 192.168.1.13

interface Tunnel4

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.13

 tunnel mpls traffic-eng affinity 0x0 mask 0x0

 tunnel mpls traffic-eng path-option 1 explicit name LOOSE_TO_XR3

R3#show mpls traffic-eng tunnels tunnel 4

Name: R3_t4                               (Tunnel4) Destination: 192.168.1.13

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type explicit LOOSE_TO_XR3 (Basis for Setup, path weight 1)

RSVP Path Info:

      My Address: 10.14.3.3

      Explicit Route: 10.14.3.14 192.168.1.14 192.168.1.11* 192.168.1.1*

                      192.168.1.15* 192.168.1.16* 192.168.1.2* 192.168.1.13*

Explicit Route: 10.14.3.3 10.14.3.14 10.14.15.14 10.14.15.15

                    10.15.16.15 10.15.16.16 10.16.2.16 10.16.2.2

                    10.13.2.2 10.13.2.13 192.168.1.13

As you can see above, we have configured our explicit path to use the TE ID of the nodes in the path to XR3. The * you see next to each of the router IDs is the indication of a loose path. The explicit path noted below the RSVP path is the actual path that will be taken from R3 to XR3. 

Now let's take a look at an strict explicit path.

R3

ip explicit-path name STRICT_TO_XR3 enable

 next-address 192.168.1.4

 next-address 192.168.1.15

 next-address 192.168.1.1

 next-address 192.168.1.12

 next-address 192.168.1.13

interface Tunnel5

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.13

 tunnel mpls traffic-eng priority 4 4

 tunnel mpls traffic-eng affinity 0x0 mask 0x0

 tunnel mpls traffic-eng path-option 1 explicit name STRICT_TO_XR3

R3#show mpls traffic-eng tunnels tunnel 5

Name: R3_t5                               (Tunnel5) Destination: 192.168.1.13

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type explicit STRICT_TO_XR3 (Basis for Setup, path weight 5)

RSVP Path Info:

      My Address: 10.3.4.3

      Explicit Route: 10.3.4.4 10.15.4.4 10.15.4.15 10.1.15.15

                      10.1.15.1 10.1.12.1 10.1.12.12 10.12.13.12

                      10.12.13.13 192.168.1.13

Explicit Route: 10.14.3.3 10.14.3.14 10.14.15.14 10.14.15.15

                    10.15.16.15 10.15.16.16 10.16.2.16 10.16.2.2

                    10.13.2.2 10.13.2.13 192.168.1.13

As you can see, the RSVP path is configured to use R4 to XR5 to R1 to XR2 to XR3. I don't have a static route or other traffic to tunnel mapping mechanism in place for this TE tunnel, so this path is simply a different output to show you the difference. The Other explicit route is the route that falls under the "Shortest Unconstrained Path" in the network, basically, this is the LDP path in the network. The RSVP path is the one that will be followed.

The next option is the "identifier" where state which devices we want the TE tunnel to go through.

ip explicit-path identifier 1 enable

 next-address 192.168.1.4

 next-address 192.168.1.5

 next-address 192.168.1.6

 next-address 192.168.1.2

 next-address 192.168.1.16

 next-address 192.168.1.15

 next-address 192.168.1.14

 next-address 192.168.1.11

 next-address 192.168.1.1

 next-address 192.168.1.12

 next-address 192.168.1.13

interface Tunnel6

 ip unnumbered Loopback0

 tunnel mode mpls traffic-eng

 tunnel destination 192.168.1.13

 tunnel mpls traffic-eng affinity 0x0 mask 0x0

 tunnel mpls traffic-eng path-option 1 explicit identifier 1

ip route 192.168.1.13 255.255.255.255 Tunnel6

R3#show mpls traffic-eng tunnels tunnel 6

Name: R3_t6                               (Tunnel6) Destination: 192.168.1.13

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type explicit 1 (Basis for Setup, path weight 11)

RSVP Path Info:

      My Address: 10.3.4.3

      Explicit Route: 10.3.4.4 10.4.5.4 10.4.5.5 10.5.6.5

                      10.5.6.6 10.2.6.6 10.2.6.2 10.16.2.2

                      10.16.2.16 10.15.16.16 10.15.16.15 10.14.15.15

                      10.14.15.14 10.11.14.14 10.11.14.11 10.1.11.11

                      10.1.11.1 10.1.12.1 10.1.12.12 10.12.13.12

                      10.12.13.13 192.168.1.13

This path hits every router in the MPLS core, intentionally configured to show you it could be done that way. I also configured a static route pointing towards XR3 to use Tunnel 6. 

R3# traceroute mpls traffic-eng tunnel 6

Type escape sequence to abort.

  0 10.3.4.3 MRU 1500 [Labels: 28 Exp: 0]

L 1 10.3.4.4 MRU 1500 [Labels: 42 Exp: 0] 10 ms

L 2 10.4.5.5 MRU 1500 [Labels: 36 Exp: 0] 3 ms

L 3 10.5.6.6 MRU 1500 [Labels: 26 Exp: 0] 5 ms

L 4 10.2.6.2 MRU 1500 [Labels: 24013 Exp: 0] 4 ms

L 5 10.16.2.16 MRU 1500 [Labels: 24014 Exp: 0] 10 ms

L 6 10.15.16.15 MRU 1500 [Labels: 24010 Exp: 0] 17 ms

L 7 10.14.15.14 MRU 1500 [Labels: 24026 Exp: 0] 15 ms

L 8 10.11.14.11 MRU 1500 [Labels: 40 Exp: 0] 18 ms

L 9 10.1.11.1 MRU 1500 [Labels: 24014 Exp: 0] 11 ms

L 10 10.1.12.12 MRU 1500 [Labels: implicit-null Exp: 0] 17 ms

! 11 10.12.13.13 17 ms

Let's do a little recursion to make sure we still know how to figure out where the TE label gets allocated and why.

R3#show ip route 192.168.1.13

Routing entry for 192.168.1.13/32

  Known via "static", distance 1, metric 0 (connected)

  Routing Descriptor Blocks:

  * directly connected, via Tunnel6

      Route metric is 0, traffic share count is 1

R3#sh ip cef 192.168.1.13 detail

192.168.1.13/32, epoch 2, flags [attached]

  local label info: global/30

  3 RR sources [non-eos indirection, heavily shared]

  attached to Tunnel6

R3#sh mpls forwarding-table labels 30 detail

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

30         Pop Label  192.168.1.13/32  0             Tu6        point2point

        MAC/Encaps=18/22, MRU=1500, Label Stack{28}, via Gi1.34

        000C2924DCA2000C29062644810000228847 0001C000

        No output feature configured

We will first look at the RIB, we see that traffic to XR3s loopback will be sent out Tunnel 6, if we do a CEF lookup we can see that a local global label of 30 has been allocated to that prefix. We can use that now in the MPLS lookup and see that 30 is the local label, label 28 is the outgoing label and it points out Tunnel 6.

Let's checkout XR3 now, we can also configure path options on XR3. They are almost identical in XR so I'll only show you the TE tunnel to R3 I created to show some basic verification against.

XR3

explicit-path identifier 1

 index 1 next-address strict ipv4 unicast 192.168.1.2

 index 2 next-address strict ipv4 unicast 192.168.1.6

 index 3 next-address strict ipv4 unicast 192.168.1.5

 index 4 next-address strict ipv4 unicast 192.168.1.4

 index 5 next-address strict ipv4 unicast 192.168.1.3

interface tunnel-te2

 ipv4 unnumbered Loopback0

 destination 192.168.1.3

 affinity ignore

 path-option 1 explicit identifier 1

RP/0/0/CPU0:XR3#show mpls traffic-eng tunnels 2

Sun Feb  5 03:18:33.883 UTC

Name: tunnel-te2  Destination: 192.168.1.3  Ifhandle:0x780

  Signalled-Name: XR3_t2

  Status:

    Admin:    up Oper:   up   Path:  valid   Signalling: connected

Node hop count: 5

  Hop0: 10.13.2.2

  Hop1: 10.2.6.2

  Hop2: 10.2.6.6

  Hop3: 10.5.6.6

  Hop4: 10.5.6.5

  Hop5: 10.4.5.5

  Hop6: 10.4.5.4

  Hop7: 10.3.4.4

  Hop8: 10.3.4.3

  Hop9: 192.168.1.3

We can see that the tunnel was successfully signalled and the path was built. Slightly different output from IOS but it still makes sense. I created a static route to point to R3 for verification purposes.

router static

 address-family ipv4 unicast

  192.168.1.3/32 tunnel-te2

RP/0/0/CPU0:XR3#sh cef 192.168.1.3 detail | in label

Sun Feb  5 03:20:18.416 UTC

     local label 24013      labels imposed {ImplNull}

RP/0/0/CPU0:XR3#show mpls traffic-eng forwarding p2p tunnel-id 2 detail

Sun Feb  5 03:21:07.423 UTC

P2P tunnels:

Tunnel ID:    2 LSP ID:    2 Destination:     192.168.1.3 Ctype:  7

  Source:    192.168.1.13 Ext Tun ID:    192.168.1.13

  Output: Gi0/0/0/0.132     Next Hop: 10.13.2.2       Output Label: 29

  Input:  -                 Prev Hop: None            Local Label:  24028

RP/0/0/CPU0:XR3#traceroute mpls traffic-eng tunnel-te 2 lsp active

Type escape sequence to abort.

  0 10.13.2.13 MRU 1500 [Labels: 29 Exp: 0]

L 1 10.13.2.2 MRU 1500 [Labels: 37 Exp: 0] 0 ms

L 2 10.2.6.6 MRU 1500 [Labels: 43 Exp: 0] 10 ms

L 3 10.5.6.5 MRU 1500 [Labels: 29 Exp: 0] 10 ms

L 4 10.4.5.4 MRU 1500 [Labels: implicit-null Exp: 0] 0 ms

! 5 10.3.4.3 10 ms

The routing table has R3s loopback pointed out Tunnel 2, the CEF output states that local label 24013 will be used. IOS XR has a separate but equally important traffic-eng forwarding table for us to leverage, we see that label 29 will be used for outbound forwarding. A MPLS trace proves that label 29 will be used as the transport label to R3.

As you can see, the path option is very handy in situations like this, being able to manipulate the forwarding is key in modern networks. 

Thanks for stopping by!

Rob Riker, CCIE #50693