Advanced DMVPN Designs

Transcription

1

2 Advanced DMVPN Designs Alex HONORÉ Cisco TAC

3 Session Agenda DMVPN refresher Review of Phase 3 logic Per-Tunnel Quality of Service DMVPN virtualization MPLS over DMVPN Multicast over DMVPN DMVPN with IPv6 Tunnel protection sharing IKE Profile-based tunnel selection Migrating from DMVPN to FlexVPN 3

4 DMVPN refresher 4

5 Terminology Core Network /17 Overlay Addresses / /24 Tunnel Address Hub 1 Hub 2 Tunnel: Physical: Tunnel: Physical: NBMA Address Tunnel: Physical: Spoke 1 GRE/IPsec Tunnels Tunnel: Physical: Spoke / /24 Transport Network Overlay Network 5

6 Feature History IOS on 7301, 7200 series, ISR, ISR-G2: Phases 1 & 2 since 12.3(17), 12.3(14)T6, 12.4M, 12.4(4)T Phase 3 since 12.4(6)T, available in all 15.x M/T releases IOS-XE on ASR1k: Phase 3 support since Release 3S Cat6500, C7600 with VPN-SPA + Sup720: No Phase 3 ever Not recommended for DMVPN (all muscle, little brain) Recommended combos today: ASR1k + IOS-XE 3.4.2S (or above): full Phase 3 support, best scalability ISR-G2 + IOS 15.0M (or above) 6

7 Base Topology Core Network / / /24 Neighborship Hub 1 Hub 2 Spoke 1 Spoke / /24 Spokes can be configured with 1 or more hubs Each spoke registers (NHRP) to each of the configured hubs Hub records NBMA and Tunnel address for each registering spoke 7

8 Phase 3 Synopsis Core Network / /16 via Hub1 next hop = / /24 Hub 1 4: Resol. Request (Dest ) 1: Initial packet flow Hub 2 6: Tunnel initiation (S2 to S1) Spokes receive a summary for the overlay network with the hub(s) as next hop Hubs send NHRP indirection to source spokes when a more direct path exists Spokes send resolution requests to resolve destination addresses into NBMA addresses, reply generated by destination spoke over direct spoke-spoke tunnel Spoke 1 S1 LAN to S2 LAN Tunnel: NBMA: : Resol. Reply (NBMA ) 8: Direct packet flow Tunnel: NBMA: Spoke / /24 8

9 Review of Phase 3 logic

10 Configuration Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C1 (Core) NHRP cache Stat (H2) / /24 Hub 1 Core Network /17 Core 1 Core 2 interface Tunnel0 description DMVPN Hub 1 ip address ip nhrp network-id 1 ip nhrp map multicast dynamic ip nhrp map multicast ip nhrp map ip nhrp redirect tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile TP Tunnel: NBMA: Tunnel: NBMA: Static mapping for Hub 2 (peer) Hub 2 NHRP mcast Stat (H2) Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) Spoke 1 Tunnel: NBMA: /24 NHRP cache Stat (H1) interface Tunnel0 description DMVPN Spoke 1 ip address ip nhrp network-id 1 ip nhrp map multicast ip nhrp map ip nhrp nhs ip nhrp shortcut tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile TP Static mapping for Hub 1 (NHS) Stat (H1) NHRP mcast 10

11 1: Spoke Registration Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C1 (Core) NHRP cache Stat (H2) Dyn (S1) / /24 Hub 1 Core Network /17 Core 1 Core 2 Tunnel: NBMA: Tunnel: NBMA: Hub 2 Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C2 (Core) NHRP cache Stat (H1) Dyn (S2) Stat (H2) Dyn (S1) NHRP mcast Stat (H1) Dyn (S2) NHRP mcast Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) Spoke 1 Tunnel: NBMA: Spoke 2 Tunnel: NBMA: / /24 NHRP cache Stat (H1) Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) NHRP cache Stat (H2) Stat (H1) NHRP mcast NHRP mcast Stat (H2) 11

12 2: Routing Neighborship Establishment Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C1 (Core) B / (H2) B / B / NHRP cache Stat (H2) Dyn (S1) / /24 Hub 1 Core Network /17 Core 1 Core 2 Tunnel: NBMA: ibgp ( ) Tunnel: NBMA: Hub 2 Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C2 (Core) B / (H1) B / B / NHRP cache Stat (H1) Dyn (S2) Stat (H2) Dyn (S1) NHRP mcast Stat (H1) Dyn (S2) NHRP mcast Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / Spoke 1 Tunnel: NBMA: Spoke 2 Tunnel: NBMA: / /24 NHRP cache Stat (H1) NHRP mcast Stat (H1) Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / NHRP cache Stat (H2) NHRP mcast Stat (H2) 12

13 3: Spoke-Hub Traffic 4: Route Lookup Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C1 (Core) B / (H2) B / B / NHRP cache Stat (H2) Dyn (S1) / /24 Hub 1 Tunnel: NBMA: Core Network /17 Core 1 Core 2 5: Forwarding Tunnel: NBMA: Hub 2 Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C2 (Core) B / (H1) B / B / NHRP cache Stat (H1) Dyn (S2) Stat (H2) Dyn (S1) NHRP mcast 3: Forwarding Stat (H1) Dyn (S2) NHRP mcast Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / Spoke 1 Tunnel: NBMA: : Route Lookup S1 LAN to Core dest: Spoke 2 Tunnel: NBMA: / /24 NHRP cache Stat (H1) 2: NHRP Lookup (*) NHRP mcast Stat (H1) CEF switching: follow adjacency on Tun0 for next hop Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / NHRP cache Stat (H2) NHRP mcast Stat (H2) 13

14 4: Spoke-Spoke Traffic: Initial Flow & Indirection 4: Route Lookup Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C1 (Core) B / (H2) B / B / NHRP cache Stat (H2) Dyn (S1) 5: NHRP Lookup / /24 Hub 1 Tunnel: NBMA: Core Network /17 Core 1 Core 2 6: Forwarding Tunnel: NBMA: Hub 2 Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C2 (Core) B / (H1) B / B / NHRP cache Stat (H1) Dyn (S2) Stat (H2) Dyn (S1) NHRP mcast Stat (H1) Dyn (S2) NHRP mcast Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / Spoke 1 Tunnel: NBMA: : Route Lookup S1 LAN to S2 LAN dest: : NHRP Lookup Spoke 2 Tunnel: NBMA: / /24 NHRP cache Stat (H1) Dyn (incomplete) 8: Cache Update + Resolution Request NHRP mcast Stat (H1) Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / NHRP cache Stat (H2) NHRP mcast Stat (H2) 14

15 5: Spoke-Spoke Traffic: Resolution Request Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C1 (Core) B / (H2) B / B / NHRP cache Stat (H2) Dyn (S1) Stat (H2) Dyn (S1) 4: Route Lookup NHRP mcast Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / Spoke / /24 Hub 1 Tunnel: NBMA: Tunnel: NBMA: : Route Lookup 2: NHRP Lookup Core Network /17 Core 1 Core 2 Tunnel: NBMA: Hub 2 Spoke 2 Tunnel: NBMA: / /24 NHRP cache Stat (H1) Dyn (incomplete) NHRP mcast Stat (H1) 6: Resolution Request ( /32) Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C2 (Core) B / (H1) B / B / NHRP cache Stat (H1) Dyn (S2) Stat (H1) Dyn (S2) 7: Route Lookup 5: NHRP Lookup 8: NHRP Lookup Generate NHRP Resolution Request DMVPN exit point for destination address 10: Route Lookup + Resolution Reply NHRP mcast NHRP cache Stat (H2) NHRP mcast Stat (H2) 15

16 5: Spoke-Spoke Traffic: Resolution Reply & Shortcut Creation Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C1 (Core) B / (H2) B / B / NHRP cache Stat (H2) Dyn (S1) Stat (H2) Dyn (S1) NHRP mcast Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / H / Spoke / /24 Hub 1 Tunnel: NBMA: : RIB Update (15.2T+, IOS-XE) Tunnel: NBMA: Core Network /17 Core 1 Core 2 3: Resolution Reply ( /24, NH , NBMA ) 4: Cache Update Tunnel: NBMA: Hub 2 Spoke 2 Tunnel: NBMA: / /24 NHRP cache Stat (H1) Dyn / NH = NHRP mcast Stat (H1) 2: Tunnel Initiation (S2 to S1) Generate NHRP Resolution Reply Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / Routing table C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B /27 C2 (Core) B / (H1) B / B / NHRP cache Stat (H1) Dyn (S2) Stat (H1) Dyn (S2) NHRP cache Stat (H2) Dyn (S1) Dyn Loc / S (H2) NHRP mcast 1: Cache Update NHRP mcast 16

17 Phase 3 Shortcuts: Old & New CEF Forwarding Hub 1 NH: NHRP Shortcut Switching NH: Forwarding table B / (H1) NHRP cache Stat (H1) Dyn / NH = (S2) Adjacencies Tu GRE Tu GRE Spoke 1 (15.1M) Spoke 2 (15.2T) Forwarding table B / (H1) H / (S1) NHRP cache Stat (H1) Dyn / NH = (S1) Adjacencies Tu GRE Tu GRE NH: # show cef int Tunnel0 i Output features Output features: NHRP Shortcut Switching FIB lookup for S2 LAN next hop = H1 Packet hits NHRP Shortcut output feature NHRP lookup for S2 LAN next hop = S2 Next hop rewritten to S2 Follow adjacency for S2 on Tunnel ifc FIB lookup for S2 LAN next hop = S1 No need for NHRP Shortcut output feature (next hop & adjacency are already correct) Follow adjacency for S1 on Tunnel ifc 17

18 Per-tunnel Quality of Service

19 The need for QoS QoS is crucial on DMVPN for: Sharing network bandwidth Marshaling bandwidth usage of applications Meeting application latency & speed requirements The greedy spoke problem: Spoke 1 (greedy) Hub Crypto engine or WAN link CE 1 Interface w/ limited downstream rate Packets are lost, AND other spokes are starved Spoke 2 Spoke 3 Packets are lost Most common problem 19

20 Per-tunnel QoS overview Per-tunnel QoS will apply dynamic per-spoke QoS policy on hub Spokes are split into groups (spoke sends group ID during NHRP registration) Each group is mapped to a QoS template HQF / CCE framework is used The feature applies to FlexVPN, DMVPN and EzVPN with dvti Not supported for crypto map based designs Hub crypto engine and WAN link overruns are rare WAN link overrun could be addressed with aggregate QoS Spoke downlink overruns are more frequent Nothing could be done This is the primary goal of per-tunnel QoS 20

21 Per-tunnel QoS groups Spokes register as part of a specific group during NHRP registration Each spoke tunnel inherits the QoS policy for the corresponding group interface Tunnel0 ip nhrp map group gold service-policy output gold ip nhrp map group silver service-policy output silver policy-map gold class class-default offer 5Mbps to each spoke in the group shape average policy-map silver class class-default offer 1Mbps to each spoke in the group shape average Hub hub# sh ip nhrp group-map Interface: Tunnel0 NHRP group: gold QoS policy: gold Tunnels using the QoS policy: Tunnel destination overlay/transport address / NHRP group: silver QoS policy: silver Tunnels using the QoS policy: Tunnel destination overlay/transport address / / Spoke 1 Spoke 2 Spoke 3 interface Tunnel0 ip nhrp group gold interface Tunnel0 ip nhrp group silver interface Tunnel0 ip nhrp group silver 21

22 Hierarchical shaper Tunnel bandwidth parent policy Each tunnel is allocated a maximum bandwidth A shaper provides the backpressure mechanism Protected packets processed by the client policy Reserved bandwidth, LLQ, etc. class-map control match ip precedence 6 class-map voice match ip precedence 5 policy-map sub-policy class control bandwidth 20 class voice priority percent 60 policy-map gold class class-default shape average service-policy sub-policy policy-map silver class class-default shape average service-policy sub-policy Reserved BW Low-latency queuing Fair queuing Aggregate shaper 22

23 SA Classification Derived Interface QoS Policy Per-tunnel QoS sequence Classification happens at the tunnel level (before encaps & crypto engine) Policing (dropping) & marking also applied at the tunnel level Queuing & scheduling happen at the physical interface Classification, policing & marking Hierarchical queuing per tunnel Tunnel 1 Data Tunnel 1 Voice Data Voice Tunnel 1 Policy Tunnel 2 Data Tunnel 2 Voice Crypto Engine Data Voice Tunnel 2 Policy Physical Interface Tunnel 3 Data Tunnel 3 Voice Data Voice Tunnel 3 Policy 23

24 DMVPN virtualization

25 Quick review: Virtual Routing/Forwarding Router maintains separate L3 forwarding information for each VRF instance (RIB, FIB, routing protocols) Two variants: VRF with MPLS, and VRF-Lite Each interface belongs to a single VRF For ip unnumbered, referenced interface must belong to the same VRF If no VRF specified, interface belongs to the global VRF VRF definition and assignment: Old CLI: ip vrf red rd 1:1 interface Ethernet0/0 ip vrf forwarding red ip address New CLI: vrf definition red rd 1:1 address-family ipv4 exit-address-family interface Ethernet0/0 vrf forwarding red ip address

26 Quick review: forwarding & tunneling with VRF-Lite Blue RIB/FIB Red RIB/FIB Global RIB/FIB Red RIB/FIB Orange RIB/FIB Routing Routing Routing Routing Routing Eth0/0 Eth0/1 Eth1/0 Eth1/1 Eth2/0 Eth2/1 Tunnel1 Tunnel2 interface Eth0/0 vrf forwarding blue interface Eth0/1 vrf forwarding blue Inside VRF (ivrf) interface Eth1/0 vrf forwarding red interface Eth1/1 no VRF = global interface Tunnel1 vrf forwarding red tunnel source Eth1/1 Front VRF (fvrf) interface Eth2/0 vrf forwarding green interface Eth2/1 vrf forwarding orange interface Tunnel2 vrf forwarding green tunnel vrf orange tunnel source Eth2/1 ivrf 26

27 DMVPN virtualization with VRF-Lite (1) Tunnel interface can be part of only one ivrf one DMVPN Tunnel per ivrf needed Spokes can be single-tenant or multi-tenant (single-tenant not necessarily VRF-aware) Spoke-spoke direct communication One pair of IPsec SAs per peer per ivrf Hub Spokes 27

28 DMVPN virtualization with VRF-Lite (2) Convenient if only a few ivrfs Main drawbacks: Major configuration overhead if many ivrfs One hub-spoke routing protocol neighborship per ivrf Tunnel address ranges cannot overlap if hubs use the BGP Dynamic Neighbors feature to peer with spokes (CSCtw69765) If separate authentication is needed for each DMVPN: Different ISAKMP profiles required (different IKE credentials) Different IPsec profiles required Different source interfaces required (same source requires shared profile) 28

29 DMVPN virtualization with MPLS VPN Single Tunnel interface in global VRF MPLS VPN labels identify which ivrf the tunneled traffic belongs to Hub-spoke only, no spoke-spoke direct BGP must be used as the routing protocol between hubs & spokes Separate IKE authentication not possible Single pair of IPsec SAs per peer Hub Spokes 29

30 MPLS over DMVPN

31 Part 1: MPLS VPN review

32 Quick review of MPLS VPN (1) MPLS basics MPLS switches packets based solely on labels, protocol agnostic Label = integer between 0 and (2 20 1) Label stack inserted between L2 header and payload Each MPLS router (LSR): Binds a label to each IGP prefix Exchanges prefixes & labels with neighboring LSRs (using LDP or BGP) Builds a Label Information Base (LIB) with all prefix/label mappings Builds a Label Forwarding Information Base (LFIB) to forward labeled packets Updates the CEF Forwarding Information Base (FIB) to label packets as needed 32

33 Quick review of MPLS VPN (2) Forwarding & Penultimate Hop Popping Packet forwarding on LSR: FIB lookup for non-labeled packets (possible actions: label packet, forward, ) LFIB lookup for labeled packets (possible actions: push, swap, pop, un-label) LSRs advertise locally connected prefixes with an implicit-null label Instructs neighboring LSRs to pop the label on packets to those prefixes Saves an LFIB lookup (would anyway result in a second lookup in FIB) This is called Penultimate Hop Popping (PHP) 33

34 Sample MPLS core / / / /32 PE1 LDP LDP LDP P1 P / / / OSPF OSPF OSPF PE2 = mpls ip configured P1 Prefixes / / / / / / /24 P1 RIB/FIB P1 LIB P1 LFIB Type Via Interface Action Local On PE1 On P2 Label Action Interface Next Hop O (PE1) Eth0/0 Forward 18 NULL POP Eth0/ (PE1) C connected Loop0 Receive NULL O (P2) Eth1/0 Forward NULL 20 POP Eth1/ (P2) O (P2) Eth1/0 PUSH SWAP 18 Eth1/ (P2) C connected Eth0/0 Glean NULL NULL 21 - C connected Eth1/0 Glean NULL 18 NULL - O (P2) Eth1/0 Forward NULL 21 POP Eth1/ (P2) Next hop & output interface Local label Peer expects packet without a label 34

35 Forwarding on MPLS core / / / /32 PE1 P1 P / / / Label pushed Ethertype: 0x8847 Label: Label swapped Ethertype: 0x8847 Label: Penultimate hop Ethertype: 0x PE2 Label popped PE1 FIB P1 LFIB P2 LFIB PE2 FIB Prefix Adjacency /32 Receive Label Action Ifc. NH 18 POP E0 PE1 Label Action Ifc. NH 18 POP E0 PE2 Prefix Adjacency /32 E0 P2 TAG /32 E0 P1 IP 19 SWAP 18 E1 P2 19 POP E1 P /32 E0 P2 TAG /32 E0 P1 TAG POP E1 P2 20 SWAP 18 E1 P /32 E0 P2 IP /32 E0 P1 TAG POP E1 P2 21 POP E1 P /32 Receive /24 Glean /24 E0 P2 TAG /24 E0 P1 IP /24 E0 P2 IP /24 E0 P1 TAG /24 Glean 35

36 Quick review of MPLS VPN (3) MPLS Virtual Private Networks Terminology: Provider (P), Provider Edge (PE), Customer Edge (CE), Customer (C) routers P and PE routers run an IGP and exchange core labels with LDP PE routers maintain one VRF instance per connected VPN and connect to MPLS core within the global VRF (global routing table) PE routers run an IGP/EGP within the VRF to exchange prefixes with CE CE routers not necessarily VRF-aware (required if multi-tenant) PE routers exchange VPN prefixes & labels across the core with MBGP CE1 PE1 LDP P1 LDP P2 LDP PE2 CE2 VRF red VRF red C1 IGP/EGP IGP (core prefixes only) Global VRF IGP/EGP C2 MBGP (VPNv4 prefixes for VRF red) 36

37 Sample MPLS VPN topology / / / /32 VRF red PE / / / P1 VRF blue VRF red P2 PE2 VRF blue EIGRP EIGRP EIGRP EIGRP /30 dot1q /30 dot1q /30 dot1q /30 dot1q 20 CE1 CE / / / /30 EIGRP EIGRP EIGRP EIGRP R1 LAN /24 B1 LAN /24 R2 LAN /24 B2 LAN /24 37

38 Exchanging VPNv4 routes LDP / / / /32 VRF red EIGRP PE / / / P1 ibgp (AS 65100) P2 PE2 Core prefixes & labels via LDP /30 dot1q /24 EIGRP R1 LAN /24 router bgp neighbor PE peer-group neighbor PE remote-as neighbor peer-group PE address-family vpnv4 neighbor PE send-community extended neighbor activate exit-address-family address-family ipv4 vrf red redistribute connected redistribute eigrp 1 exit-address-family address-family ipv4 vrf blue redistribute connected redistribute eigrp 1 exit-address-family VPNv4 prefixes & labels via MBGP (SAFI 128) 65100:10: /30 via label :10: /24 via label :10: /24 via label 24 Extended Community: RT:65100: :20: /30 via label :20: /24 via label :20: /24 via label 27 Extended Community: RT:65100:20 vrf definition red rd 65100:10 route-target both 65100:10 vrf definition blue rd 65100:20 route-target both 65100:20 38

39 VRF red CE1 Forwarding across MPLS VPN / / / / / / / / /30 PE1 P P2.1.2 PE /24 Transport label Ethertype: 0x8847 Ethertype: 0x /24 VRF red Ethertype: 0x0800 Label: 19 (top) Label: 18 (top) Ethertype: 0x8847 Ethertype: 0x Label: 23 (bottom) Label: 23 (bottom) Label: CE2 PE1 FIB (VRF red) Prefix Adjacency /30 Glean / /24 E1.10 CE1 IP / /24 E1.10 CE1 IP / PE1 FIB (global) Prefix Adjacency /32 E0 P1 TAG 19 VPN label Top label swapped Top label popped VPN label popped P1 LFIB Label Action Ifc. NH 18 POP E0 PE1 19 SWAP 18 E1 P2 20 POP E1 P2 21 POP E1 P2 Label Action P2 LFIB Ifc. NH 18 POP E0 PE2 19 POP E1 P1 20 SWAP 18 E1 P1 21 POP E1 P1 LFIB entry contains adjacency no need for FIB lookup PE2 LFIB Lbl. Action VRF Ifc. NH 17 POP E0 P No Label red aggregate 23 No Label red E1.10 CE2 24 No Label red E1.10 CE2 25 No Label blue aggregate 26 No Label blue E1.20 CE2 27 No Label blue E1.20 CE2 39

40 Part 2: MPLS over DMVPN

41 Synopsis Tunnel /24 MBGP Tunnel /24 VRF red VRF red VRF blue Spoke1 (PE) Global VRF Hub1 (PE) VRF blue VPNv4 prefix from Hub1: red: /16 label IPsec (ESP transport mode) GRE (protocol: 0x8847) Label: Tunnel interface in global, not part of any customer VRF Hub and spokes act as PE routers, exchange VRF prefixes over MBGP mgre Tunnel creates a back-to-back connection spoke LSR is the penultimate hop only the VPN label is pushed LDP still required for a supported design 41

42 Encapsulation sequence (1) Input interface VRF blue Global Output interface IP Data GRE encapsulation IP GRE IP Data IP Encryption ESP GRE IP Data ESP VRF-Lite MPLS over DMVPN Input interface VRF red Global Output interface IP Data Label imposition Encryption GRE encapsulation MPLS IP Data IP ESP GRE MPLS IP Data ESP IP GRE MPLS IP Data 42

43 Encapsulation sequence (2) VRF blue Global VRF-Lite MPLS over DMVPN VRF red GRE encapsulation VRF blue Encryption Global VRF red Single IPsec tunnel Label imposition Single GRE Tunnel 43

44 VRF & LAN interfaces (spoke & hub) Set extended community 1:1 on outgoing VPNv4 routes from VRF red Import incoming VPNv4 routes with extended community 1:1 into VRF red Enable IPv4 within VRF red (new CLI; not required with old CLI) Place Eth1/1 within VRF red Place Eth1/2 within VRF blue vrf definition red rd 1:1 route-target export 1:1 route-target import 1:1 address-family ipv4 exit-address-family vrf definition blue rd 2:2 route-target export 2:2 route-target import 2:2 address-family ipv4 exit-address-family interface Ethernet1/1 vrf forwarding red ip address interface Ethernet1/2 vrf forwarding blue ip address

45 mgre tunnel (spoke & hub) No vrf forwarding statement cleartext traffic enters mgre tunnel from the global VRF No tunnel vrf statement GRE traffic encrypted & routed using the global routing table No ip nhrp shortcut and ip nhrp redirect statements (no spoke-to-spoke tunnels) Enable MPLS on interface using labels received from BGP interface Tunnel0 ip address no ip redirects ip nhrp map multicast ip nhrp map ip nhrp network-id 1 ip nhrp nhs mpls bgp forwarding mpls ip tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile dmvpn interface Tunnel0 ip address no ip redirects ip nhrp map multicast dynamic ip nhrp map multicast ip nhrp map ip nhrp network-id 1 mpls bgp forwarding mpls ip tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile dmvpn Spoke Hub 45

46 Spoke BGP configuration Neighborships, VRF, redistribution & VPNv4 Use ibgp for spoke-hub peerings Define hub neighborships statically Send RT extended community along with VPNv4 routes Redistribute connected networks that belong to VRF red into BGP Redistribute LAN routes learned from EIGRP within VRF red into BGP router bgp bgp router-id bgp log-neighbor-changes neighbor hubs peer-group neighbor hubs remote-as neighbor hubs update-source Tunnel0 neighbor peer-group hubs neighbor peer-group hubs address-family vpnv4 neighbor hubs send-community extended neighbor activate neighbor activate exit-address-family address-family ipv4 vrf red redistribute connected redistribute eigrp 1 exit-address-family address-family ipv4 vrf blue redistribute connected redistribute eigrp 1 exit-address-family 46

47 Hub BGP configuration Listener, neighborships, VRF, redistribution & VPNv4 Listen for incoming BGP connections from all spoke tunnel addresses Use ibgp for hub-spoke and hub-hub peerings Define hubs neighborships statically Send RT extended community along with VPNv4 routes Reflect spoke routes to other hubs Set next hop to self on ibgp routes sent to other hubs Redistribute connected networks that belong to VRF blue into BGP Redistribute LAN routes learned from EIGRP within VRF blue into BGP router bgp bgp listen range /24 peer-group spokes bgp listen limit 10 neighbor spokes peer-group neighbor spokes remote-as neighbor spokes update-source Tunnel0 neighbor hubs peer-group neighbor hubs remote-as neighbor hubs update-source Tunnel0 neighbor peer-group hubs address-family vpnv4 neighbor spokes activate neighbor spokes send-community extended neighbor hubs send-community extended neighbor hubs route-reflector-client neighbor hubs next-hop-self all neighbor activate exit-address-family address-family ipv4 vrf red redistribute connected redistribute eigrp 1 exit-address-family address-family ipv4 vrf blue redistribute connected redistribute eigrp 1 exit-address-family 47

48 Route summarization (1) Option 1: VPNv4 default routes VRF red VRF blue Spoke 1:1: /0 via label 16 Extended Community: RT:1:1 2:2: /0 via label 17 Extended Community: RT:2:2 Import static Null0 default for VRF blue and advertise it into BGP Ensure that: spokes will only receive one default per VRF hubs will receive spoke prefixes but no defaults Hub router bgp address-family vpnv4 neighbor spokes prefix-list default-only out neighbor hubs prefix-list no-default out exit-address-family address-family ipv4 vrf red network default-information originate exit-address-family address-family ipv4 vrf blue network default-information originate exit-address-family ip route vrf red Null0 ip route vrf blue Null0 ip prefix-list default-only seq 5 permit /0 ip prefix-list no-default seq 5 deny /0 ip prefix-list no-default seq 10 permit /0 le 32 48

49 Route summarization (2) Option 2: VPNv4 overlay summaries VRF red VRF blue Spoke 1:1: /17 via label 16 Extended Community: RT:1:1 2:2: /17 via label 17 Extended Community: RT:2:2 Ensure that: spokes will only receive the summary routes hubs will receive spoke prefixes but no summaries Match on RT value 2:2 in outbound VPN routes and compare with summary prefix for VRF blue Hub router bgp address-family vpnv4 neighbor spokes route-map summary-only out neighbor hubs route-map no-summary out address-family ipv4 vrf red network mask address-family ipv4 vrf blue network mask ip route vrf red Null0 ip route vrf blue Null0 ip prefix-list sum-red seq 5 permit /17 ip prefix-list sum-blue seq 5 permit /17 ip extcommunity-list 11 permit rt 1:1 ip extcommunity-list 22 permit rt 2:2 route-map no-summary deny 11 match ip address prefix-list sum-red match extcommunity 11 route-map no-summary deny 22 match ip address prefix-list sum-blue match extcommunity 22 route-map no-summary permit route-map summary-only permit 11 match ip address prefix-list sum-red match extcommunity 11 route-map summary-only permit 22 match ip address prefix-list sum-blue match extcommunity 22 49

50 Packet forwarding (1) Hub1 VRF red / /24 VRF red Spoke1 Spoke / / IPsec (ESP transport mode) GRE (protocol: 0x8847) Label: spoke1#show ip route vrf red Gateway of last resort is to network B* /0 [200/0] via , 00:00: /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Ethernet1/1 L /32 is directly connected, Ethernet1/1 R /24 [120/1] via , 00:00:08, Ethernet1/1 spoke1#show ip cef vrf red /0 nexthop Tunnel0 label 36 FIB lookup leads to label imposition 50

51 Detailed FIB entry & Tunnel adjacency spoke1#show ip cef vrf red internal /0, epoch 0, flags rib defined all labels, default route, RIB[B], refcount 5, per-destination sharing output chain: label 36 TAG midchain out of Tunnel0, addr F33D7CB0 IP adj out of Ethernet0/0, addr F33D7F10 spoke1#show adjacency Tunnel0 detail Protocol Interface Address IP Tunnel (7) Encap length FF2FFDABAC AC Tun endpt Next chain element: IP adj out of Ethernet0/0, addr TAG Tunnel (5) Encap length FF2FFDABAC AC = Hub1 NBMA address Packets following default route will be labeled Tun endpt Next chain element: IP adj out of Ethernet0/0, addr Specific TAG adjacency for labeled packets 0x2F = 47 = GRE 0x8847 = MPLS unicast = mgre tunnel source 51

52 Packet forwarding (2) Hub1 VRF red / /24 VRF red Spoke1 Spoke / / IPsec (ESP transport mode) IPsec (ESP transport mode) GRE (protocol: 0x8847) GRE (protocol: 0x8847) Label: 36 Label: hub1#show mpls forwarding-table labels 36 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 36 No Label /0[V] 0 aggregate/red Aggregate of multiple prefixes FIB lookup needed hub1#show ip cef vrf red /24 nexthop Tunnel0 label 19 FIB lookup yields Spoke2 and new label Spoke2 LFIB contains adjacency to LAN next hop router spoke2#show mpls forwarding-table labels 19 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 19 No Label /24[V] \ 114 Et1/

53 Multicast over DMVPN

54 NHRP Replication: Local Multicast interface Tunnel0 ip nhrp map multicast dynamic ip nhrp map multicast ip nhrp map hub1# show ip nhrp multicast I/F NBMA address Tunnel Flags: static Tunnel Flags: dynamic Hub 1 (LAN) Gig0/1 Locally generated multicast (WAN) Gig0/0 Tun /24 Replication by NHRP NHRP always performs replication of local multicast ( /24) NHRP multicast mappings can be static or dynamic (spoke registration) Each packet gets replicated to all NBMA addresses in the NHRP multicast table To Spoke 1 (NBMA ) To Hub 2 (NBMA ) 54

55 PIM: Hub-Spoke & Spoke-Hub Multicast interface Tunnel0 ip pim nbma-mode ip pim sparse-mode ip nhrp map multicast dynamic ip nhrp map (LAN) Gig0/1 Source Multicast traffic ( ) Transit multicast traffic is always replicated in the forwarding path PIM neighborship established thanks to NHRP multicast replication Only PIM-SM and PIM-SSM are supported ip pim nbma-mode instructs PIM to set up multicast traffic replication NBMA-mode required: on hubs and IOS-XE spokes (always) on IOS spokes (if hosting a source) Group OIL Hub 1 Tun /24 (WAN) Gig0/0 To Spoke 1 (Tunnel ) Receiver Selective replication by CEF To Hub 2 (Tunnel ) No receiver (*, ), 00:19:28/00:03:26, RP , flags: S Incoming interface: Null, RPF nbr Outgoing interface list: Tunnel0, , Forward/Sparse, 00:19:28/00:03:26 55

56 PIM-SM: Spoke-Spoke Multicast (1) Unicast RIB C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / (summary) B / (anycast RP) Multicast RIB C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / (summary) B / (anycast RP) / /24 Tunnel: NBMA: Hub 1 PIM Join Shared Tree Core Network /17 Core 1 Core 2 Anycast RP: MSDP Tunnel: NBMA: Hub 2 Spoke 1 Spoke 2 IP mroutes (*, ),, RP , flags: SJC Incoming interface: Tunnel0, RPF nbr Outgoing interface list: Gig1/0, Forward/Sparse, 05:09:41/00:02:59 Tunnel: NBMA: Tunnel: NBMA: / /24 IGMP Join Receiver (.2) (Group: ) Source (.2) (Group: ) 56

57 PIM-SM: Spoke-Spoke Multicast (2) Unicast RIB C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / (summary) B / (anycast RP) Multicast RIB C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / (summary) B / (anycast RP) / /24 Tunnel: NBMA: Hub 1 Core Network /17 Core 1 Core 2 Anycast RP: PIM Prune Shared Tree PIM Join Source Tree Tunnel: NBMA: Hub 2 Shared Tree Source Tree Spoke 1 Spoke 2 IP mroutes (*, ),, RP , flags: SJC Incoming interface: Tunnel0, RPF nbr Outgoing interface list: Gig1/0, Forward/Sparse, 05:09:41/00:02:59 ( , ),, flags: JT Incoming interface: Tunnel0, RPF nbr Outgoing interface list: Gig1/0, Forward/Sparse, 00:00:04/00:02:55 Tunnel: NBMA: Receiver (.2) (Group: ) / /24 Tunnel: NBMA: Traffic to Source (.2) (Group: ) 57

58 PIM-SM: Spoke-Spoke Multicast (3) Unicast RIB C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / (summary) B / (anycast RP) H / (S2) Multicast RIB C /30 Gig0/0 (WAN) C /24 Gig0/1 (LAN) C /24 Tun0 (DMVPN) B / (summary) B / (anycast RP) H / (S2) IP mroutes (*, ),, RP , flags: SJC Incoming interface: Tunnel0, RPF nbr Outgoing interface list: Gig1/0, Forward/Sparse, 05:09:41/00:02:59 ( , ),, flags: JT Incoming interface: Tunnel0, RPF nbr Outgoing interface list: Gig1/0, Forward/Sparse, 00:00:04/00:02:55 RPF nbr Core Network / / /24 Tunnel: NBMA: Hub 1 Spoke 1 Core 1 Core 2 Tunnel: NBMA: Receiver (.2) (Group: ) Anycast RP: PIM Prune Shared Tree PIM Join Source Tree No PIM neighborship / /24 Similar issue with PIM-SSM (cannot join (S,G) at all) Tunnel: NBMA: Tunnel: NBMA: Hub 2 Shared Tree Spoke 2 Traffic to Source (.2) (Group: ) 58

59 Why did this happen? A mechanism exists in PIM-SM to prevent this situation: the T flag T flag set on (S,G) entry if traffic was received over the source-based tree Prune shared tree & join source-based tree only if T flag is set on (S,G) entry Not effective for DMVPN RP and source are behind the same mgre interface Traffic from RP comes in through mgre Tunnel mgre Tunnel = RPF interface towards the source T flag is set while it should not (multicast believes that it has seen traffic over the source-based tree, while it was actually coming from the RP) (*, ),, RP , flags: SJC Incoming interface: Tunnel0, RPF nbr Outgoing interface list: Gig1/0, Forward/Sparse, 05:09:41/00:02:59 ( , ),, flags: JT Incoming interface: Tunnel0, RPF nbr Outgoing interface list: Gig1/0, Forward/Sparse, 00:00:04/00:02:55 59

60 Possible solutions (1) Option 1: SPT-threshold infinity Simplest solution: never switch to source-based tree ip pim vrf <ivrf> spt-threshold infinity Drawbacks: Not applicable for source-specific multicast (no shared tree) Must be configured on all multicast-enabled routers on spoke LANs (so that none of the last-hop routers will try to join the SPT) Not selective, applies to all multicast traffic within the ivrf Prevents creation of (S,G) entries reduced granularity in show commands Alternative: cancel adverse effect of NHRP route on RPF check RPF check must keep pointing towards the hub NHRP route must no longer be replicated into multicast RIB 60

61 Possible solutions (2) Option 2: push multicast default route Best solution: push multicast default route from hubs via MBGP (SAFI 2) Overrides replication of BGP routes Compatible with anycast RP Caution: SAFI 129 support required if ivrf is not global/default IOS-XE: 3.5S (IPv4), 3.7S (IPv6) IOS: 15.3(1)T (IPv4 & IPv6) Hub 1 Multicast [vrf lan]: /0 via Hub1 Spoke 1 Routing Table: lan:multicast Gateway of last resort is to network B* /0 [200/0] via (lan), 00:00: /8 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Tunnel0 L /32 is directly connected, Tunnel /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Ethernet1/0 L /32 is directly connected, Ethernet1/0 router bgp address-family ipv4 multicast [vrf lan] neighbor spokes peer-group neighbor spokes remote-as neighbor spokes update-source Tunnel0 neighbor spokes default-originate exit-address-family router bgp address-family ipv4 multicast [vrf lan] neighbor hubs peer-group neighbor hubs remote-as neighbor hubs update-source Tunnel0 neighbor peer-group hubs neighbor activate exit-address-family Unicast routes replicated from BGP & NHRP have disappeared 61

62 DMVPN with IPv6

63 IPv6 support in DMVPN IPv6 overlay supported since IOS 12.4(20)T and IOS-XE 3.7S Transport/NBMA is still IPv4-only Dual-stack: IPv6 & IPv4 data packets over the same mgre tunnel Complete set of NHRP commands for IPv6 NHRP registers both global and link-local IPv6 addresses Phase 3 designs only Hub interface Tunnel0 ipv6 address fe80::2001 link-local ipv6 address 2001::1/64 ipv6 nhrp network-id 1 ipv6 nhrp map multicast dynamic Spoke interface Tunnel0 ipv6 address fe80::2002 link-local ipv6 address 2001::2/64 ipv6 nhrp map 2001:: ipv6 nhrp map multicast ipv6 nhrp nhs 2001::1 ipv6 nhrp network-id 1 IPv6 transport support added in IOS 15.2(1)T and IOS-XE 3.8S 63

64 Shared tunnel protection

65 Reminder: static crypto map vs. tunnel protection crypto ipsec transform-set tset mode transport crypto map cmap 10 ipsec-isakmp set peer set transform-set tset match address gre-tun0 interface GigabitEthernet0/0 ip address crypto map cmap interface Tunnel1 ip address tunnel source GigabitEthernet0/0 tunnel destination ip access-list extended gre-tun1 permit gre host host crypto ipsec transform-set tset mode transport crypto ipsec profile tp set transform-set tset interface Tunnel1 ip address tunnel source GigabitEthernet0/0 tunnel destination tunnel protection ipsec profile tp Must be repeated for every new GRE/IPsec tunnel IPsec profile = crypto map template (no peer, no ACL) ( ) Gi0/0 ( ) Gi0/0 Single config statement for every new GRE/IPsec tunnel Tun1 ( ) IPsec protection Tun1 ( ) Makes mgre possible GRE tunneling 65

66 Background: IPsec data structures Security Policy Database (SPD): Describes traffic that should be protected with IPsec Describes which parameters to use (algorithms, tunnel/transport mode) Control plane-only concept show crypto map Security Association Database (SAD): Describes traffic that we are currently protecting with IPsec Control & data plane concept show crypto ipsec sa SPD and SAD maintained together within SP/SA DB 66

67 Scope of SP/SA DB: static crypto map (1) One SP/SA DB per IKE/IPsec endpoint Single crypto map on single interface one SP/SA DB for the crypto map Single crypto map on two interfaces two separate SP/SA DBs Each interface becomes a separate IKE/IPsec endpoint SPDs are distinct but identical (protecting the same traffic) SADs are maintained separately (tunnels can be up at the same time) IKE & IPsec traffic terminates on each interface s IP address Gig1/0 Tun1 Gig0/0 Single SP/SA DB Gig1/0 Tun1 Gig0/0 Gig0/1 Multiple SP/SA DBs crypto map cmap 10 ipsec-isakmp set peer set transform-set tset match address gre-tun0 interface GigabitEthernet0/0 ip address crypto map cmap = crypto map = SP/SA DB scope crypto map cmap 10 ipsec-isakmp set peer set transform-set tset match address gre-tun0 interface GigabitEthernet0/0 ip address crypto map cmap interface GigabitEthernet0/1 ip address crypto map cmap 67

68 Scope of SP/SA DB: static crypto map (2) With crypto map local-address Defines a single IKE/IPsec endpoint for the map Can be an interface with no crypto map applied Single SP/SA DB: Attached to the configured local address Shared by all interfaces where map is applied router#show crypto map Crypto Map: "cmap" idb: Loopback0 local address: Crypto Map IPv4 "cmap" 10 ipsec-isakmp Peer = Extended IP access list gre-tun0 access-list gre-tun0 permit gre host Current peer: Interfaces using crypto map cmap: Ethernet0/0 Ethernet0/1 Tun1 Gig0/0 Gig1/0 Gig0/1 Loop0 = crypto map = SP/SA DB scope Single SP/SA DB Root: Loop0 interface Loopback0 ip address crypto map cmap local-address Loopback0 crypto map cmap 10 ipsec-isakmp set peer set transform-set tset match address gre-tun0 interface GigabitEthernet0/0 ip address crypto map cmap interface GigabitEthernet0/1 ip address crypto map cmap 68

69 Tunnel Protection & Crypto Secure Sockets (1) Tunnel Protection feature Signals to Crypto Secure Sockets Crypto Secure Sockets subsystem Creates ad hoc crypto map based on IPsec profile Creates new SP/SA DB for this tunnel Binds new crypto map and SP/SA DB to protected interface crypto ipsec profile tp set transform-set tset interface Tunnel1 ip address tunnel source GigabitEthernet0/0 tunnel destination tunnel protection ipsec profile tp Tunnel Protection router#show crypto sockets Number of Crypto Socket connections 1 IKE endpoints Tu1 Peers (local/remote): / Local Ident (addr/mask/port/prot): ( / /0/47) Remote Ident (addr/mask/port/prot): ( / /0/47) IPSec Profile: "tp" Socket State: Open Client: "TUNNEL SEC" (Client State: Active) GRE endpoints Crypto Sockets Crypto Sockets in Listen state: Client: "TUNNEL SEC" Profile: "tp" Map-name: "Tunnel1-head-0" Listener for incoming connections 69

70 Tunnel Protection & Crypto Secure Sockets (2) router#show crypto map Crypto Map IPv4 "Tunnel1-head-0" ipsec-isakmp Profile name: tp Security association lifetime: kilobytes/3600 seconds Responder-Only (Y/N): N PFS (Y/N): N Transform sets={ tset: { esp-256-aes esp-sha-hmac }, } Entry 65536: crypto socket listener (similar to dynamic-map) Crypto Map IPv4 "Tunnel1-head-0" ipsec-isakmp Map is a PROFILE INSTANCE. Peer = Extended IP access list access-list permit gre host host Current peer: Security association lifetime: kilobytes/3600 seconds Responder-Only (Y/N): N PFS (Y/N): N Transform sets={ tset: { esp-256-aes esp-sha-hmac }, } Interfaces using crypto map Tunnel1-head-0: Tunnel1 Each new socket triggers the creation of a profile instance entry in the tunnel map-head Entries & higher: crypto sockets (open or closed) 70

71 Scope of SP/SA DB: tunnel protection Point-to-point GRE: Single remote endpoint Remote endpoint is known socket created automatically Multipoint GRE + NHRP: Some remote endpoints are known via NHRP mappings sockets created automatically Incoming dynamic connections will hit the listening socket Outgoing dynamic connections based on NHRP resolutions sockets created dynamically crypto map Tunnel1-head-0 listening crypto socket crypto socket to Tun1 Gig1/0 Gig0/0 crypto map Tunnel1-head-0 listening crypto socket crypto socket to crypto socket to From NHRP mappings crypto ipsec profile tp set transform-set tset P-P GRE interface Tunnel1 ip address tunnel source GigabitEthernet0/0 tunnel destination tunnel protection ipsec profile tp = Tunnel1-head-0 crypto map = Tunnel1 SP/SA DB scope crypto ipsec profile tp set transform-set tset mgre interface Tunnel1 ip address ip nhrp map ip nhrp map ip nhrp nhs ip nhrp nhs ip nhrp network-id 1 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile tp 71

72 Quick Mode proposal processing (1) Example 1: dual mgre, different tunnel sources Gig1/0 Tun1 (mgre) Gig1/1 Tun2 (mgre) QM request from peer on Gig0/0: ESP with AES-128/SHA, transport mode GRE / /32 SP/SA DB root: Gig0/0 SPD: crypto map Tunnel1-head-0 listening crypto socket Profile: tp1 (tset, red-peers) crypto socket to Select SP/SA DB based on local address (Gig0/0) Look for local/remote proxies in SPD Best match: / /0 (listening socket) Check for matching transforms Check for matching IKE profile (if configured) SP/SA DB root: Gig0/1 SPD: crypto map Tunnel2-head-0 listening crypto socket Profile: tp2 (tset, blue-peers) crypto socket to All OK create new crypto socket and profile instance Gig0/0 Tun1 SP/SA DB Root: Gig0/0 ( ) Gig0/1 Tun2 SP/SA DB Root: Gig0/1 ( ) tset = esp-aes 128 sha-hmac trans. crypto ipsec profile tp1 set transform-set tset set isakmp-profile red-peers crypto ipsec profile tp2 set transform-set tset set isakmp-profile blue-peers interface Tunnel1 ip address vrf forwarding red tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile tp1 interface Tunnel2 ip address vrf forwarding blue tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel protection ipsec profile tp2 72

73 Quick Mode proposal processing (2) Example 2: dual mgre, same tunnel source Gig1/0 Tun1 Gig1/1 Tun2 QM request from peer on Gig0/0: ESP with AES-128/SHA, transport mode GRE / /32 SP/SA DB root: Gig0/0 SPD: crypto map Tunnel1-head-0 listening crypto socket Profile: tp1 (tset, red-peers) crypto socket to Ambiguity: multiple SP/SA DB rooted on Gig0/0 Only works if we use different transforms (not just separate identical transform sets ) under tp1 & tp2? SP/SA DB root: Gig0/0 SPD: crypto map Tunnel2-head-0 listening crypto socket Profile: tp2 (tset, blue-peers) crypto socket to Using different IKE Profiles in this configuration looks appealing but is not supported Gig0/0 ( ) tset = esp-aes 128 sha-hmac trans. crypto ipsec profile tp1 set transform-set tset set isakmp-profile red-peers crypto ipsec profile tp2 set transform-set tset set isakmp-profile blue-peers interface Tunnel1 ip address vrf forwarding red tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile tp1 interface Tunnel2 ip address vrf forwarding blue tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile tp2 73

74 Shared tunnel protection (1) tp-head-0 crypto map Gig1/0 Tun1 Gig1/1 Tun2 Shared tunnel protection: tunnel protection ipsec profile <profile> shared All tunnels protected by the shared IPsec profile will share the same SP/SA DB and crypto map: <profile>-head-1 SP/SA DB root: Gig0/0 SPD: crypto map tp-head-0 listening crypto socket Profile: tp (tset, all-peers) crypto socket to crypto socket to Socket for Tunnel1 Socket for Tunnel2 GRE traffic multiplexed based on tunnel key Removes the ambiguity, but introduces many restrictions Gig0/0 Profile tp SP/SA DB Root: Gig0/0 ( ) crypto ipsec profile tp set transform-set tset set isakmp-profile all-peers interface Tunnel1 ip address vrf forwarding red tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 1 tunnel protection ipsec profile tp shared interface Tunnel2 ip address vrf forwarding blue tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 2 tunnel protection ipsec profile tp shared

75 Shared tunnel protection (2) Gig1/0 Tun1 Gig1/1 Tun2 router#show crypto sockets Shd Peers (local/remote): / Local Ident (addr/mask/port/prot): ( / /0/47) Remote Ident (addr/mask/port/prot): ( / /0/47) Flags: shared IPSec Profile: "tp" Socket State: Open Client: "TUNNEL SEC" (Client State: Active) Gig0/0 Crypto Sockets in Listen state: Client: "TUNNEL SEC" Profile: "tp" Map-name: "tp-head-1" router#show crypto map Crypto Map: "tp-head-1" idb: GigabitEthernet0/0 local address: Crypto Map IPv4 "tp-head-1" ipsec-isakmp Profile name: tp Crypto Map IPv4 "tp-head-1" ipsec-isakmp Map is a PROFILE INSTANCE. Peer = Extended IP access list Crypto is applied to Tun1 and Tun2 access-list permit gre host host but local address is set to Gig0/0 Interfaces using crypto map tp-head-1: Tunnel1 Tunnel2 75

76 Guidelines & restrictions (1) Tunnel1 Tunnel2 Situation TP shared Differentiator(s) P-P GRE or mgre P-P GRE or mgre Different sources Not required Tunnel source (IPsec profiles must be different) P-P GRE P-P GRE Same source Different destinations Not required Tunnel destination P-P GRE P-P GRE Same source Same destination Required Tunnel key mgre mgre Same source Required Tunnel key mgre P-P GRE Same source P-P GRE initiator only Required Tunnel key mgre P-P GRE Same source P-P GRE responder Need fix for CSCub95247 (*) Tunnel key IPsec profile (**, as workaround) (*) fix available in: IOS 15.1(4)M6, 15.2(4)M3, 15.3(2)T & IOS-XE 3.7.3S/15.2(4)S3, 3.8.2S/15.3(2)S (**) workaround: use different IPsec profiles with different transforms and no shared keyword mode & algorithms act as differentiator during QM (two separate identical transform sets will not work) 76

77 Guidelines & restrictions (2) Shared tunnel protection Summary: Keyword shared always required if tunnel source is shared Exception: all point-point GRE with different destinations (no ambiguity) Special case: mgre & point-point GRE responder (CSCub95247) Prevents the use of multiple IKE Profiles (due to single IPsec profile) If TP shared is used for a given tunnel source: All tunnels with that tunnel source must use TP shared and the same IPsec profile Other tunnels with different sources may not use the same IPsec profile Always use the interface name as tunnel source, never the IP address interface Tunnel0 tunnel source Incorrect interface Tunnel0 tunnel source GigabitEthernet0/0 Correct 77

78 IKE Profile-based tunnel selection

79 The future of tunnel protection (1) IKE Profile-based tunnel selection IPsec-protected Tunnel interface linked to IKEv1 or IKEv2 profile: Through IPsec profile (current behavior) Through extended tunnel protection command: tunnel protection ipsec profile <ipsec-prof> [shared {isakmp ikev2}-profile <ike-prof>] Each IPsec profile can have either an IKEv1 or IKEv2 profile, not both Tunnel interface selection in Phase 2 based on IKE profile IKE profile on Tunnel must match the one derived by IKE from peer ID TP shared still supported (mutually exclusive per local address) 79

80 The future of tunnel protection (2) Major improvements Configuration: Allows different IPsec profiles to coexist on the same local address Allows IKEv1 & IKEv2 tunnels to coexist with the same source address IKEv1 profile remains optional on initiator & responder IKEv2 profile becomes mandatory on responder (already mandatory on initiator) dvti responder: profile derived by IKE assigned to Virtual-Access upon creation Behavior changes: Tunnel with IKEv1 profile no longer accepts all IKEv2 connections (& vice-versa) Makes Tunnel selection deterministic, removes ambiguities for good Currently planned for IOS-XE 3.10S & IOS 15.3(3)T 80

81 Migrating from DMVPN to FlexVPN

82 Why migrate to FlexVPN? Includes all capabilities of DMVPN Phase 3 (and many more): Dynamic peers, spoke-spoke direct tunnels, redundancy Key advantages over DMVPN: Point-to-point interfaces all features can be configured per peer AAA integration most parameters can be stored on a RADIUS server Advanced initiator logic (tracking-based) via FlexVPN client block Much more concise configuration in complex setups (e.g. multi-tenant) IKEv2 routes can complement or replace a dynamic routing protocol Brings all advantages of the IKEv2 protocol Upgrading the hardware? opportunity to move to next-gen crypto as well 82

83 Why NOT migrate to FlexVPN? If something is not broken, don t fix it DMVPN still fully supported (Phase 3 = the only recommended design) Hardware constraints (FlexVPN only supported on ASR1k & ISR-G2) Constraints due to migration scenarios 83

84 Sample configuration Hub FlexVPN with dynamic mesh Match peers with a certificate where DN O field is cisco Populate Virtual-Access attributes based on RADIUS profile named after DN OU field Default IPsec profile (pre-configured) points to default IKEv2 profile (not pre-configured) IP unnumbered, ivrf, NHRP network-id, GRE tunnel key, will be populated based on AAA authorization attributes aaa new-model aaa authorization network rad group radius crypto pki certificate map cisco-map 10 subject-name co o = cisco crypto ikev2 name-mangler ou dn organization-unit crypto ikev2 profile default match address local interface Ethernet0/0 match certificate cisco-map identity local dn authentication remote rsa-sig authentication local rsa-sig pki trustpoint root-ca aaa author group cert list radius name-mangler ou virtual-template 2 interface Virtual-Template2 type tunnel ip nhrp redirect tunnel protection ipsec profile default 84

85 Sample configuration Spoke FlexVPN with dynamic mesh Match peers with a certificate where DN O field is cisco and OU is eng Use default local IKEv2 authorization policy (route set interface, route accept any) Tunnel interface required on initiator, tunnel destination can be hardcoded or dynamic (driven by Flex client configuration block) Spoke of eng type interface parameters are hardcoded (on hub side, will be derived from AAA authorization based on OU field) A separate Virtual-Access is instantiated for every spoke-spoke direct connection aaa new-model aaa authorization network here local crypto pki certificate map cisco-eng 10 subject-name co o = cisco subject-name co ou = eng crypto ikev2 profile default match certificate cisco-eng... aaa authorization group cert list here default virtual-template 2 interface Tunnel2 ip unnumbered Loopback2 ip nhrp network-id 2 ip nhrp shortcut virtual-template 2 tunnel source Ethernet0/0 tunnel destination tunnel key 2 tunnel protection ipsec profile default interface Virtual-Template2 type tunnel ip unnumbered Loopback2 ip nhrp network-id 2 ip nhrp shortcut virtual-template 2 tunnel key 2 tunnel protection ipsec profile default 85

86 Migration scenarios (1) stating the obvious Premise: spoke router is not being replaced 1) One step approach: Pre-configure FlexVPN on all spokes (tunnel remains shut down) Bring up FlexVPN hub Turn DMVPN off & FlexVPN on, on all spokes at once 2) Progressive approach: Bring up FlexVPN alongside DMVPN DMVPN DMVPN Hub WAN/MPLS/ Spoke Make the FlexVPN routes less preferred (change metrics on the hubs) Use e.g. a test prefix to ensure spoke-spoke direct works OK Make the FlexVPN routes preferred (change metrics on the hubs) FlexVPN Hub FlexVPN 86

87 Migration scenarios (2) One step approach Advantages: No need for DMVPN and FlexVPN to coexist (no need to share tunnel source) Tunnel addressing scheme can be reused Disadvantages: Only practical for small number of spokes Potentially long maintenance window required Downtime is unavoidable 87

88 Migration scenarios (3) Progressive approach Advantages: Spoke sites can be prepared in sequence FlexVPN fully brought up (incl. routing) while DMVPN remains in production Short maintenance window required for switchover, easy rollback Virtually no downtime (just re-routing) Disadvantage: IKEv1 and IKEv2 must coexist on the same device 88

89 Option 1: separate source addresses Progressive approach DMVPN & FlexVPN both use tunnel protection DMVPN IPsec profile requires IKEv1 profile FlexVPN IPsec profile requires IKEv2 profile Only possible if tunnel source is different Need additional routable WAN address (not always possible or practical) Loopback /32 WAN/MPLS/ Spoke Ethernet0/ /30 crypto ipsec profile DMVPN set transform-set tset set isakmp-profile DMVPN interface Ethernet0/0 ip address interface Tunnel1... tunnel source Ethernet0/0 tunnel protection ipsec profile DMVPN DMVPN crypto ipsec profile default set ikev2-profile default interface Loopback0 ip address interface Tunnel2... tunnel source Loopback0 tunnel protection ipsec profile default FlexVPN 89

90 Option 2: IKE Profile-based tunnel selection Progressive approach Tunnel interface becomes IKEv1- or IKEv2-only Different IPsec profiles allowed on single tunnel source Currently planned for IOS-XE 3.10S & IOS 15.3(3)T WAN/MPLS/ Ethernet0/ /30 Spoke crypto ipsec profile DMVPN set transform-set tset set isakmp-profile DMVPN interface Tunnel1... tunnel source Ethernet0/0 tunnel protection ipsec profile DMVPN DMVPN crypto ipsec profile default set ikev2-profile default interface Tunnel2... tunnel source Ethernet0/0 tunnel protection ipsec profile default FlexVPN 90

91 Before we part

92 Call to Action Attend these recommended sessions: Advanced IPSec with FlexVPN and IKEv2 (BRKSEC-3013, Frederic Detienne) IPv6 Security Threats and Mitigations (BRKSEC-2003, Eric Vyncke) Get hands-on experience with the following Walk-in Labs: Deploying DMVPN (LABSEC-2031) Advanced DMVPN (LABSEC-2035) Meet the Engineer: Alex Honore & Olivier Pelerin (TAC Engineers) Frederic Detienne (Distinguished Engineer) Discuss your project s challenges at the Technical Solutions Clinics Visit the Cisco Campus at the World of Solutions 92

93 93

94