Encrypting P-to-P traffic in MPLS VPN
Encrypting P-to-P traffic in MPLS VPN
Here, the solution to encrypt P2-to-P3 router traffic in MPLS VPN is IPSec over GRE tunnel. Cisco IOS can only encrypt IP traffic using IPSec. Now, to convert an MPLS frame forwarded by P2-router back to IP, GRE can be used. A GRE tunnel is setup between P2 and P3 router. IPSec runs over GRE carrying MPLS payload. At P3-router, it decrypts the IPSec packet, removes the GRE header and obtains the MPLS frame.
GRE over MPLS:
First, a GRE tunnel is configured between P2 and P3 router. OSPF is enabled on the Tunnel interface and OSPF cost is changed to 10 so that the Tunnel interface is forced to forward traffic to P3 router, and vice versa. Also, MPLS is enabled on the Tunnel interface so that the LSP is not broken.
GRE tunnel configuration on P2 & P3
P2 router:interface tunnel 0 ip address 172.16.1.1 255.255.255.252 tunnel mode gre ip tunnel source fastethernet 0/1 tunnel destination 10.1.1.6 ip ospf 1 area 0 ip ospf cost 10 mpls ip!P3 router:interface tunnel 0 ip address 172.16.1.2 255.255.255.252 tunnel mode gre ip tunnel source fastethernet 0/0 tunnel destination 10.1.1.5 ip ospf 1 area 0 ip ospf cost 10 mpls ip!The packet capture below taken between P2 and P3 router shows the encapsulations (highlighted in RED) applied on the packet when an ICMP packet is sent from PE1 Loopback 1 to PE4 Loopback 1. It shows that P2 router receives a frame with 2 MPLS headers (carrying two labels- LDP label (top) and VPN label (bottom)) encapsulating the original IP packet. When P2-router receives the MPLS frame, it looks up its LFIB table, swaps the top label, puts the GRE header including a new IP header, a L2-header on top of that and forwards the packet to P3 router. P3 router decapsulates the headers and obtains the MPLS frame.
The following output shows the MPLS labels imposed on the packet by PE1 router.
MPLS labels imposed by PE1 router
VPN label sent by PE4 router using BGP for 192.168.2.0/24 customer network.PE1# show ip bgp vpnv4 all 192.168.2.0 255.255.255.0BGP routing table entry for 1:1:192.168.2.0/24, version 5Paths: (1 available, best #1, table CUST1) Not advertised to any peer Local 4.4.4.4 (metric 31) from 4.4.4.4 (4.4.4.4) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:1:1 mpls labels in/out nolabel/21Labels imposed by PE1 router for 192.168.2.0/24. Label 19 is the LDP label advertised by P2 router and Label 21 is the VPN label advertised by PE4 router.PE1# show ip cef vrf CUST1 192.168.2.0 detail192.168.2.0/24, version 8, epoch 0, cached adjacency 10.1.1.20 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Fa0/0, 10.1.1.2, tags imposed: {19 21} via 4.4.4.4, 0 dependencies, recursive next hop 10.1.1.2, FastEthernet0/0 via 4.4.4.4/32 valid cached adjacency tag rewrite with Fa0/0, 10.1.1.2, tags imposed: {19 21}IPSec over GRE over MPLS:
Now, IPSec is configured over GRE carrying MPLS frame.
IPSec configuration on GRE Tunnel on P2
crypto isakmp policy 10 encryption des authentication pre-share hash md5 group 2!crypto isakmp key 0 MY_K3Y address 10.1.1.6!crypto ipsec transform-set TS esp-des esp-md5-hmac!crypto ipsec profile MY_PROFILE set transform-set TS!interface tunnel 0 tunnel protection ipsec profile MY_PROFILE!The following output shows ISAKMP and IPSec security associations (SAs).
ISAKMP & IPSec SA
P2# show crypto isakmp saIPv4 Crypto ISAKMP SAdst src state conn-id slot status10.1.1.5 10.1.1.6 QM_IDLE 1002 0 ACTIVEIPv6 Crypto ISAKMP SAP2# show crypto ipsec sainterface: Tunnel0 Crypto map tag: Tunnel0-head-0, local addr 10.1.1.5 protected vrf: (none) local ident (addr/mask/prot/port): (10.1.1.5/255.255.255.255/47/0) remote ident (addr/mask/prot/port): (10.1.1.6/255.255.255.255/47/0) current_peer 10.1.1.6 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 16, #pkts encrypt: 16, #pkts digest: 16 #pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 10, #recv errors 0 local crypto endpt.: 10.1.1.5, remote crypto endpt.: 10.1.1.6 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1 current outbound spi: 0xE20B1E30(3792379440) inbound esp sas: spi: 0x7F7CC621(2138883617) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } conn id: 3, flow_id: SW:3, crypto map: Tunnel0-head-0 sa timing: remaining key lifetime (k/sec): (4452064/3568) IV size: 8 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xE20B1E30(3792379440) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } conn id: 4, flow_id: SW:4, crypto map: Tunnel0-head-0 sa timing: remaining key lifetime (k/sec): (4452064/3568) IV size: 8 bytes replay detection support: Y Status: ACTIVE outbound ah sas: outbound pcp sas:A packet capture is taken between P2 and P3 routers when an ICMP packet is sent from PE1 router Loopback 1 to PE4 router Loopback 1. It shows the encapsulations applied inside the frame. It shows a L2-header encapsulating an ESP packet (protocol 0x32 or decimal value 50).
Unfortunately, the packet capture cannot show the actual ESP payload. But, if it would, it would look something as below-
A sample Ping and traceroute outputs taken from PE1 router are shown below including the debug ip packet detail.
PE1# ping vrf CUST1 192.168.2.1 source Loopback 1 size 1500Type escape sequence to abort.Sending 5, 1500-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:Packet sent with a source address of 192.168.1.1!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 616/690/800 msPE1# traceroute vrf CUST1 192.168.2.1 source Loopback 1Type escape sequence to abort.Tracing the route to 192.168.2.1 1 10.1.1.2 [MPLS: Labels 19/21 Exp 0] 272 msec 232 msec 324 msec 2 172.16.1.2 [MPLS: Labels 19/21 Exp 0] 312 msec 148 msec 328 msec 3 192.168.2.1 [MPLS: Label 21 Exp 0] 336 msec 324 msec *PE1# debug ip packet detail*Mar 1 00:47:19.603: IP: tableid=0, s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), routed via FIB*Mar 1 00:47:19.603: IP: s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), g=10.1.1.6, len 136, forward, proto=50*Mar 1 00:47:23.511: IP: tableid=0, s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), routed via FIB*Mar 1 00:47:23.511: IP: s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), g=10.1.1.6, len 136, forward, proto=50*Mar 1 00:47:23.547: IP: tableid=0, s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), routed via FIB*Mar 1 00:47:23.547: IP: s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), g=10.1.1.6, len 160, forward, proto=50*Mar 1 00:47:27.631: IP: tableid=0, s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), routed via FIB*Mar 1 00:47:27.631: IP: s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), g=10.1.1.6, len 136, forward, proto=50*Mar 1 00:47:31.443: IP: tableid=0, s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), routed via FIB*Mar 1 00:47:31.447: IP: s=10.1.1.5 (local), d=10.1.1.6 (FastEthernet0/1), g=10.1.1.6, len 136, forward, proto=50MTU Issues:
As seen above, due to extra overheads, the size of the IP packet increases considerably causing the packet to become oversize. If default MTU settings (1500 bytes) are kept unchanged, the router performance and packet travelling time increases as the router has to perform fragmentation. If the DF-bit is set to 1 for a packet size of 1500 bytes, the packets are not forwarded by P2 router.
Failed packet delivery with DF set to 1
PE1# ping vrf CUST1 192.168.2.1 source loopback1 size 1500 df-bitType escape sequence to abort.Sending 5, 1500-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:Packet sent with a source address of 192.168.1.1Packet sent with the DF bit set.....Success rate is 0 percent (0/5)This situation is avoidable if the DF-bit is cleared along the path on P2 router or Path-MTU discovery is turned ON.