CCIE SPv4 MPLS Inter AS Option A BGP VRF Aware Traffic Engineering - Local Preference

In the past few posts I focused on the Inter AS L2VPN options, with that covered, I focus now on BGP Path Selection manipulation. This will focus on Option A, and likely Options B and C in later posts, but since they are focusing on the Global RIB, leveraging normal IPv4/IPv6 BGP Path Selection logic could be used.

Leveraging the same topology we have for the past few posts, we'll focus on IOS and XR for the demo's. IOSv1 on the left has reachability between both ASNs to reach IOSv7, IOSv9 and IOSv10. The goal in this post is to manipulate the currently selected BGP Best path selection to something we determined.

CSR1#sh bgp vpnv4 unicast all
BGP table version is 13, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 20:20 (default for vrf BGP)
 *>  1.1.1.1/32       20.1.1.10                0             0 65001 i
 *>i 3.3.3.3/32       1.1.1.14                 0    100      0 65003 i
 *>i 7.7.7.7/32       1.1.1.2                  0    100      0 200 65007 i
 *>i 9.9.9.9/32       1.1.1.2                  0    100      0 200 65009 i
 *>i 10.10.10.10/32   1.1.1.2                  0    100      0 200 65010 i

As you can see, XRv4 and CSR2 are our egress points in the network. We'll first modify LP on XRv4 to affect all VPN traffic towards ASN 200. We'll create an RPL that sets the local preference to 400 and passes all traffic. It's important to pass all traffic along with setting the BGP attribute or traffic won't pass through.

route-policy RPL_LP
  set local-preference 400
  pass

end-policy
!
router bgp 100
 vrf BGP
  neighbor 20.11.14.11
   address-family ipv4 unicast
    route-policy RPL_LP in
    route-policy PASS out
 
With the above configuration in place, we should be able to affect all traffic towards ASN200 going out of XRv4.

CSR1#show bgp vpnv4 unicast all 
BGP table version is 34, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 20:20 (default for vrf BGP)
 *>  1.1.1.1/32       20.1.1.10                0             0 65001 i
 *>i 3.3.3.3/32       1.1.1.14                 0    100      0 65003 i
 *>i 7.7.7.7/32       1.1.1.14                      400      0 200 65007 i
 *>i 9.9.9.9/32       1.1.1.14                      400      0 200 65009 i
 *>i 10.10.10.10/32   1.1.1.14                      400      0 200 65010 i

As you can see, XRv4 is the egress point for all traffic. Let's test reachability, I had already conducted a traceroute to IOSv7 so you'll see a before and after trace.

IOSV1#traceroute vrf BGP 7.7.7.7 source lo0 numeric 
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 20.1.1.1 13 msec 6 msec 3 msec
  2 10.1.13.13 [MPLS: Labels 24006/81 Exp 0] 36 msec 42 msec 21 msec
  3 10.13.3.3 [MPLS: Labels 28/81 Exp 0] 26 msec 23 msec 32 msec
  4 10.3.11.11 [MPLS: Labels 24009/81 Exp 0] 36 msec 43 msec 33 msec
  5 20.2.14.2 [MPLS: Label 81 Exp 0] 24 msec 27 msec 26 msec
  6 20.2.14.14 27 msec 28 msec 29 msec
  7 10.11.14.11 [MPLS: Labels 27/38 Exp 0] 46 msec 34 msec 36 msec
  8 10.11.10.10 [MPLS: Labels 24007/38 Exp 0] 62 msec 35 msec 42 msec
  9 20.7.12.12 [MPLS: Label 38 Exp 0] 58 msec 79 msec 113 msec
 10 20.7.12.7 84 msec *  38 msec

As you can see, there is a 10 hop trace traversing CSR2 and CSR14, the 20.2.14.0/24 subnet.

IOSV1#traceroute vrf BGP 7.7.7.7 source lo0 numeric 
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 20.1.1.1 23 msec 5 msec 4 msec
  2 10.1.13.13 [MPLS: Labels 24004/24022 Exp 0] 28 msec 43 msec 214 msec
  3 10.13.3.3 [MPLS: Labels 24/24022 Exp 0] 37 msec 29 msec 27 msec
  4 10.3.14.14 [MPLS: Label 24022 Exp 0] 33 msec 16 msec 20 msec
  5 20.11.14.11 41 msec 85 msec 55 msec
  6 10.11.10.10 [MPLS: Labels 24007/38 Exp 0] 38 msec 37 msec 32 msec
  7 20.7.12.12 [MPLS: Label 38 Exp 0] 40 msec 55 msec 25 msec
  8 20.7.12.7 43 msec *  84 msec

Here you can see an 8 hop trace now traversing XRv4 on the 20.11.14.0/24 subnet.

Now we will take a look at doing a per prefix modification, IOSv7's loopback trace should flow via CSR6.

ip prefix-list PL_IOSv7_LB seq 5 permit 7.7.7.7/32
route-map RM_LP permit 10
 match ip address prefix-list PL_IOSv7_LB

 set local-preference 400
!
router bgp 100
 address-family ipv4 vrf BGP
  neighbor 20.6.9.9 route-map RM_LP in

CSR1#show bgp vpnv4 unicast all 
BGP table version is 44, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 20:20 (default for vrf BGP)
 *>  1.1.1.1/32       20.1.1.10                0             0 65001 i
 *>i 3.3.3.3/32       1.1.1.14                 0    100      0 65003 i
 *>i 7.7.7.7/32       1.1.1.6                  0    400      0 200 65007 i
 *>i 9.9.9.9/32       1.1.1.14                      400      0 200 65009 i

 *>i 10.10.10.10/32   1.1.1.14                      400      0 200 65010 i

Here we see the traffic being forwarded out CSR6. Just to make sure it's not a fluke, we can check the prefix-list on CSR6 for hits.

CSR6#show ip prefix-list detail 
Prefix-list with the last deletion/insertion: PL_IOSv7_LB
ip prefix-list PL_IOSv7_LB:
   count: 1, range entries: 0, sequences: 5 - 5, refcount: 3

   seq 5 permit 7.7.7.7/32 (hit count: 2, refcount: 1)

Let's retest the traceroute again to see if looks different.

IOSV1#traceroute vrf BGP 7.7.7.7 source lo0 numeric 
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 20.1.1.1 16 msec 6 msec 5 msec
  2 10.1.13.13 [MPLS: Labels 24008/39 Exp 0] 65 msec 26 msec 27 msec
  3 10.13.3.3 [MPLS: Labels 20/39 Exp 0] 37 msec 35 msec 34 msec
  4 10.3.11.11 [MPLS: Labels 24006/39 Exp 0] 39 msec 28 msec 45 msec
  5 10.11.15.15 [MPLS: Labels 24002/39 Exp 0] 37 msec 36 msec 28 msec
  6 20.6.9.6 [MPLS: Label 39 Exp 0] 52 msec 31 msec 29 msec
  7 20.6.9.9 64 msec 30 msec 37 msec
  8 10.9.14.14 [MPLS: Labels 22/38 Exp 0] 57 msec 41 msec 54 msec
  9 10.11.14.11 [MPLS: Labels 27/38 Exp 0] 55 msec 43 msec 47 msec
 10 10.11.10.10 [MPLS: Labels 24007/38 Exp 0] 67 msec 53 msec 117 msec
 11 20.7.12.12 [MPLS: Label 38 Exp 0] 38 msec 50 msec 43 msec
 12 20.7.12.7 72 msec *  486 msec

As you can see the path changed.

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