MPLS Part 2 Intro || LDP || VRF

google-site-verification: googled4f3b50296d72ca7.html

Discovering LDP Neighbors

o Like IGPs , LDP automatically discovers neighbours with Hello Protocol
o Hellos use multicast UDP
   o 224.0.0.2 - " All routers Multicast "
   o UDP SRC & DST Port 646

o Hello include "IPv4 Transport Address"
    o Address to use for the TCP session
    o Defaults to the LDP router-id

o Forming LDP Adjacencies
    o LDP sessions are formed reliably over TCP
         o unicast between transport address
         o TCP port 646


o Implies peers must have routes to each other's transport address
      o e.g their loopbacks

o Transport address could be modified but not normally needed
     o Like IGP , hardcoding router-id is recommended

Advertising Labels:
o Once LDP session is established , label is advertised
   for FEC
     o i.e label to IPv4 prefix mapping

o Label distribution can be implicit or explicit
   o unsolicited downstream vs downstream on demand
   o depends on implementation & config option

o Labels could be advertised for some or all routers
o Cisco default is all IGP routes
o Really only /32 loopback matters

LDP Configuration

Enable CEF
   o Should already be on by default
 
Agree on label protocol
    o MPLS label protocol
    o Should already be LDP by default

Recommended to define router - id
    o MPLS LDP router id

Enable LDP
    o interface mpls ip
    o IGP process : mpls ldp autoconfig

LDP Verification
   o Verify LDP is enabled
   o show mpls interfaces

Verify LDP sessions
   o  show mpls ldp neighbor

Verify LFIB
   o show mpls forwarding-table

Note : need to allow LDP via ACL

ip access-list extended ACL
permit udp any eq 646 host 224.0.0.2 eq 646
permit tcp any any eq 646
permit tcp any any eq 646 any

+++++++++++++++++++++++++++++++++++++++

VRF : Virtual routers insie IOS

o VRF defines a new instance of the routing table
o Interface assigned to the VRF belong to that routing table.
o Interfaces not in a VRF are in the "global" or "default" vrf

Result in essentially a VPN

o Separate control plan instances
o Separate data plan based on routing
o e.g i cannot reach you if i have no route to you
o addressing can overlap in different VRF

VRF Aware Routing
o Routing inside a VRF can be through .....
o VRF aware static routes
o VRF aware dynamic routes
        o RIP
        o EIGRP
        o OSPF
        o IS-IS
        o MP BGP
o Policy Routing

Creating VRFs
o Specify locally significant VRF name
     . ip vrf [name]
     . IPv4 only
     . vrf Defination [name]
- supports both IPv4 & IPv6

Specify "route distinguisher"
    rd [ASN:nn | ip-address:nn ]
   more on this MP BGP

Applying VRFs
   o Apply VRF to interface
     o ip vrf forwarding [name] | vrf forwarding [name]
    o removes ip address from interfaces

This minimum configuration is called "vrf lite"
     o i.e VRFs without any mpls config
     o VRFs do not always means MPLS
     o MPLS does not always means VRFs

VRF Verification
      o show ip route vrf [vrf]
      o ping vrf [vrf]
      o traceroute vrf [vrf]


upgrade like this :
vrf upgrade-cli multi-af-mode common-policies

++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MPLS Part 1 || Intro

BGP Problem Statment

o Global BGP table is huge, and growing
      o over 500 000 IPv4 prefixes & growing
      o IPv6 space is growing but currently negligible
      o See http://bgp.potaroo.net / for table grow

o Why is this a problem ?
     o IP Routing is destination based
     o all devices in the transit path must know the destination
     o E.g all transit routers must have full BGP feeds

o Routing Through vs To  the Core
o Transit providers sell transit , not applications
  o e.g ISP is not the same as an ASP
o Traffic routes through the SP, not to the SP
  o e.g end client needs to ping end application , not core link

o How does this affect core routing ?
   o To SP core , only the ingress point and egress point matter
   o original source & final destination are arbitrary

Tunnels - The ultimate band - aid
o Simple transit solution is to tunnel traffic over core from ingress to egress
o only the ingress & egress devices need full end to end information
o core only needs info about ingress & egress devices

How can we tunnel ?
o QinQ, GRE , IPinIP , MPLS etc
o MPLS is defacto standard

Example case - BGP over GRE over core

o Form a GRE tunnel from ingress to egress
   o Tunnel subnet is link-local & arbitrary

o Peer BGP from ingress to egress

o Recover BGP next-hop to tunnel
  o Either peer through the tunnel , or modify next-hop to the tunnel

o What is the core's data plane result ?
o Core routes ingress PE to egress PE
o Core does not need end to end information

o Where MPLS fits in
 o MPLS is the core's tunnel encapsulation
 o same exact logic as GRE

MPLS is more flexible
o Arbitrary transport
o Arbitrary payload
o Extensible application

BGP over MPLS over core
o Form an MPLS tunnel from ingress to egress
o Typically IGP + LDP  is used for this
o Could be BGP or RSVP ( MPLS TE)

o Peer BGP from ingress to egress
o Recurse BGP next-hop to MPLS label
o What is the core's data plane result ?
   o Core label switches ingress PE to egress PE
   o Core does not need end to end information

++++++++++++++++++++++++++++++++++++++++++++++++++++

                                                  MPLS

o Multi protocol label switching
o Originally cisco proprietary
         o Previously called "tag switching"
o Now an open standard "RFC 3031 "
-- can transport different payloads
layer 2 payload - ethernet , FR , ATM , PPP , HDLC etc
layer 3 payload - ipv4 , ipv6 etc
extensible for new further payloads

Why use MPLS ?

 o Transparent tunneling over SP n/w
o BGP free core
   o saves routing table space on provider (P) routes
o offers L2/L3 VPN services to Customers
o No need for overlay VPN model

-- Traffic Engineering
-- Distribute load over underutilized links
-- Give b/w guarantes
-- Route based on service type
-- Detect & repair failure quickly , i.e Fast reroute (FRR)

MPLS label format :






RFC 3032 - MPlS label stack encoding
4 byte header used to "switch" packet
20 bit label = locally significant to router
3 bit EXP = class of service
S bit = defines last label in the label stack
8 bit TTL = time to live

# show mpls ldp bindings ( LRIB similar to sh ip route )
# show mpls forwarding table ( LFIB simil to show ip cef)

How Labels work:
o MPLS lables are bound to FECs
 o forwarding equivalence class
 o IPv4 prefix for our purposes

 o Router uses MPLS LFIB instead of IP Routing table to switch traffic
o Switch logic : if traffic comes in if1 with label X send it inter if2 with label Y

MPLS Device Roles:

o MPLS n/w consists of 3 types of devices
  oo Customer edge ( CE)
  oo Provider edge (PE)
  oo  Provider (P)

CE Devices
-- Last hop device in customer n/w
-- connects to providers n/w
-- can be L2 only or L3 aware
-- typically not MPLS aware

PE Devices
-- Provider Edge (PE)
   -- previously called label edge router (LER)
   -- Last hop device in providers n/w
   -- connects to CE and Provider (P) core devices .
o PE performs both ip routing & MPLS lookups
-- For traffic from customer to core ...
-- Receives unlabelled pkts ( e.g IPv4)
-- Adds one or more MPLS labels
-- Forwards labeled packet to Core
-- For traffic from core to customer
   -- receives MPLS labelled packets
  -- forwards pkt to customer

P Devices

 o Provider (P)
  Previously called label switch routers (LSR)
 core devices in providers n/w
  -- connects to PEs and / or other P routers
 o Switches traffic based only on MPLS labels

MPLS Devices operatoins

PE & P routers perform 3 major MPLS operations

oo Label Push
  -- add a label to an incoming pkt
  -- AKA label imposition

oo Label Swap
  -- Replace the label on an incoming pkt

oo Label PoP
   -- Remove the label from an outgoing pkt
   -- AKA label dispostion


 Label Distribution

-- label are advertised via a label distribution protocol
-- label distribution protocol (LDP)
   -- Advertised labels for IGP routes
   -- RFC 5036

MP- BGP
 oo advertise labels for BGP learned routes
 oo RFC 3107

RSVP

   oo Used for MPLS traffic engineering (MPLS TE)
   oo RFC 3209


                               ------------------oooooooooooooooooooo---------------------------

VPN Part 3 : GRE over IPSEC || VTI || DMVPN

GRE over IPSEC Tunnels:

o GRE over ipsec vs ipsec over gre
o gre over ESP transport vs tunnel mode
o IP MTU & TCP Adjust MSS

Why use GRE & IPSEC Together ?

o Crypto maps have no interface in routing table
o implies that dynamic IGP routing isn't supported
o Static routing is hard to scale
o BGP could be used , but complicated design

Simple solution, add a tunnel interface

 o Run routing inside of the GRE Tunnel
 o Encrypt the GRE tunnel inside of IPSEC


 Where does the Crypto Map apply ?
o If Crypto map attached at physical interface
o GRE over IPSEC ( IPSEC is transport )
o GRE ECAP FIRST
o Encryption Second
o Proxy-ACL with single entry " permit gre host A host B"

If Crypto map attached at tunnel interface level
 o  IPSEC over GRE ( GRE is transport )
 o Encryption First
 o GRE Second
 o Proxy ACL with end to end entries
 o Bad Design

GRE over ESP Transport Vs Tunnel mode

o |original IP Header | TCP/UDP  | data |
o |New IP Header | GRE IP Header | GRE | Original IP Header | TCP/UDP| Data|

Transport mode :
o|New IP Header|ESP Header|GRE|Original IP Header|TCP/UDP|Data|ESP Trailer|ESP Authen|

Tunnel mode:
o|New IP Header||GRE IP Header|ESP Header|GRE|Original IP Header|TCP/UDP|Data|ESP Trailer|ESP Authen|

GRE over IPSEC & Fragmentation Problem

o Overhead is negligible , why do we care ?
o Extra 20 bytes is only 1% overhead of 1500 byte MTU
o DF bit isn't copied between headers
o PMTUD is now broken
o Route must encrypt then fragment
o Throughput is now out the window

How do we fix it ?
o offload fragmentation to the end host

IP MTU & TCP Adjust MSS

o How do we offload fragmentation to host ?
o Lower IP MTU on GRE to account for ESP overhead
o Actual overhead varies based on crypto algorithm
            o E.g AES uses 16 byts block
o Good rule of thumb is about 1400 bytes normal MTU
o Jumbo MTU rule of thumb about 9000 bytes

What if host does not implement PMTUD ?

o Edit their MSS in TCP SYN & SYN ACK
o TCP adjust MSS is IP MTU -- 20 bytes
o IP 20 bytes TCP

configuration example: 
 https://supportforums.cisco.com/document/16066/how-configure-gre-over-ipsec-tunnel-routers

++++++++++ IPSEC VIRTUAL TUNNEL INTERFACE (VTI) ++++++++++++

IPSEC Virtual Tunnel Interface (VTI )
o Tunnel interface with direct ipsec encapsulation conceptually similar with GRE, but
    without additional GRE overhead.

Two VTI variations:
o Static VTI (SVTI)
   used for site to site VPN
o Dynamic VTI (DVTI)
   used for remote access VPN

                     GRE over IPSEC                        Vs                            IPSEC VTI

o More overhead                                                              o Less overhead
   (Arguably negligible)
o Multi protocol encapsulation                                        o Simple protocol encapsulation
   (E.g IPv4 , IPv6, IS-IS etc)                                              (IPv4 over IPv4 or IPv6 over IPv6)
o On demand VPN                                                           o Always on
   usually triggered by IGP                                                  No interesting traffic needed 
o Line protocol based on route to destination                  o Line protocol based on ipsec phase 2


                             IPSEC VTI Configuration

o Phase 1 steps are identical to crypto map based tunnel
o Phase 2 -- tunnel already defines the who : i.e tunnel destination
o Tunnel already defines the what : i.e ip any any
o How is the traffic treated ? : define by crypto ipsec profile

 Crypto IPSEC Profiles:

o IPSEC profile is essentially a stripped down version of crypto map
o Contains only ipsec phase 2 negotiation parameters :
    i.e ipsec transform set

o Does not contain peer address or proxy ACL
 -- Peer is the tunnel destination
 -- Proxy ACL is non configurable
 -- Permit ip / gre any any

o IPSEC profile can apply to both GRE tunnel & IPSEC VTI tunnel
   -- Tunnel MTU is automatically adjusted for ESP overhead

                     +++++++ FINAL CONFIG +++++++

Crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
crypto isakmp transfrom-set ESP_AES_SHA esp-aes esp-sha-hmac
!
! mode transport
crypto ipsec profile VTI_PROFILE
  set transform-set ESP_AES_SHA
!
 interface tunnel 0
    ip address 78.0.0.7/24
    ip tcp adjust-mss 1398
    ip ospf 1 area 0
   tunnel source lo0
   tunnel mode ipsec IPv4
   tunnel destination 150.1.8.9
   tunnel protection ipsec profile VTI_PROFILE
!
 IPSEC VTI Configuration example:

http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.html

  ++++++ DMVPN over IPSEC ++++++

 DMVPN Review

o DMVPN is P2M Layer 3 overlay VPN
   -- Logical hub & spoke topology
   -- Direct spoke to spoke traffic is supported

o DMVPN uses a combination of ----
  -- Multiprotocol GRE tunnels (mGRE)
  -- Next Hop Resolution Protocol ( NHRP)
  -- IPSEC Crypto Profiles
  -- Routing

IPSEC over DMVPN
o DMVPN typically implies IPSEC but doesn't required it .
-- DMVPN on its own is an mGRE routing technique
-- Can be combined with IPSEC to encrypt GRE

o IPSEC over DMVPN is same logic as ipsec over GRE
o Configured as Crypto ipsec profile to tunnel
o Only difference is dynamic spoke to spoke tunnels

DMVPN order of operations
o Crypto First ( Phase 1 ----> Phase 2 )
o NHRP second
o Routing third

IPSEC DMVPN Phase 1/2/3

Spoke to hub tunnels are always nailed up
o True for all DMVPN phase
o Implies hub always has IPSEC SA for all spokes
o Spokes to Spokes tunnels are on demand
-- True for DMVPN phase 2/3
-- Implies ipsec SA is established on demand between spokes

Scaling ipsec over DMVPN

o AS DMVPN cloud grows , ipsec stat grows
 -- Linear ipsec SA  stat from hub to spoke , spoke to spoke scal is on demand
o Scaling ISAKMP Authentication
  -- PSK is supported but hard to manage
-- Wildcard PSKs are bad idea
-- PKI is the preferred solution

o Scaling IPSEC SAs
-- DMVPN over GETVPN

Configuration example:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-mt/sec-conn-dmvpn-15-mt-book/sec-conn-dmvpn-dmvpn.html

   ------------------------------oooooooooooooooooooooo------------------------------

VPN Part 2

Crypto Map Based IPSEC Overview:

"Legacy " Method of IOS IPSEC Configuration
-- Still the most common method though

> Used to form on-demand IPSEC Tunnels
-- Session initiated only when interesting traffic detect

>  No dynamic routing support through tunnel
-- Not without additional encapsulation such GRE

How Crypto Maps Work

> Crypto map is a data-plane filter
-- Matching traffic triggers an ISAKMP session to start
> Traffic is matched using ACLs
-- ACLs define proxy IDs for IPSEC Phase 2 , e.g what should be encrypted

> Allows for granular control over VPN
-- e.g only send TCP port 12345 over the VPN

 Applying Crypto Maps

> Crypto maps apply to physical (sub) interfaces
-- Only one crypto map per interface
-- always outbound with respect to traffic direction

One crypto map can apply to multiple interfaces

-- Entries processed top-down until ACL match occurs , order is important

Tunnel source defaults to interface IP
-- can be changed using crypto map local-address

Crypto Maps order of operations
-- Encryption applies after routing
   o static routing may be required

-- Encryption applies after NAT
NAT exemption may be required

-- Rule of thumb is that crypto , routing & NAT process are always independent of each
    other



High Level Configuration steps

Define phase 1 ISAKMP policy
Define phase 2 IPSEC policy
Apply crypto map
o Generating interesting traffic

 Defining Phase 1 ISAKMP Policy

> Peers must agree of four main attributes
   o Authentication o Encryption o Hash o DH Group o Lifetime (Lower value is negotiated)

> Policy is processed top-down until a match occurs by the responder
   o Based on policy priority
   o Lower priority value has higher precedence
   o order is important

> Defining phase 2 IPSEC Policy
> IPSEC policy defines 3 main attributes
who ? define peer adds, hostname , or FQDN
what ? define proxy ACL
How ? Define transform set

 Configuration Verification 
> show crypto isakmp [default ] policy
-- verify custom or default phase 1 policies
> show crypto isakmp key
-- verify pre-shared keys
> show crypto ipsec transform-set <name>
-- Verify custom or default phase 2 policies
> show crypto debug-condition
-- verify conditions / filters for debugging
> show crypto map interface <intf>
-- verify crypto-map configuration

Advanced Verification

> show crypto isakmp sa
-- show the result of phase 1 negotiations
> debug crypto isakmp
-- show the step-by-step phase 1 negotiation
> show crypto ipsec sa
-- show the result of phase 2 negotiation
> debug crypto ipsec
-- show the step by step phase 2 negotiation

refer link:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-3s/sec-sec-for-vpns-w-ipsec-xe-3s-book/sec-ipsec-virt-tunnl.html

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IPSEC Verification & Troubleshooting: 
Phase 1 Verification & Troubleshooting 
o Show crypto isakmp sa [detail]
o Debug crypto isakmp 
-- state should be "QM-IDLE" and state "ACTIVE"
o debug crypto isakmp
 (shows negotiation process)
o debug crypto condition peer IPv4 <ip>
-- Restricts debugging output to relevant peer 

## is authentication working ? 
o check PSK/CA
o Failure means corrupted packets

## Do IKE v1 SA attributes match ? 
o debug will show failure to negotiate attributes

## Result will be one bidirectional ISAKMP SA 

                 Phase 2 Verification & Troubleshooting 

## Phase 1 ISAKMP IKE v1 "ACTIVE"   first 
## show crypto ipsec sa [Peer <ip> ]
o Are packets getting .....
  o en/decrypted ...
  o en / decapsulation ...
  o check both sides

## debug crypto ipsec
  o shows negotiation of ipsec SA's

o did transform sets match ?
o Are ACLs mirror images ?
o Result should be two SA's per ACL entry
(inbound & outbound )

o Unidirectional pkt conters usually mean a data plane, problem is the transit path.

++ i.e someone is filtering ESP
## clear crypto isakmp -----   delete phase 1
## clear crypto ipsec sa ----  delete phase 2


+++++++++++  Next is labe +++++++++++++


















 


 

VPN Part 1

IPSEC Overview
IPSEC Control Plane
        > ISAKMP & IKE Negotiation
IPSEC data plane 
        >  ESP & AH Encapsulations


          VPN Overview : 

 Extension of a private n/w over a public n/w
 VPN doesn't necessarily imply encryption

Examples:
Layer 2 VPNs
    Ethernet  VLANs , QinQ , FR, PVCs , ATM

Layer 3 VPNs
     GRE, MPLS, Layer 3 VPN , IPSEC



IPSEC Features:
Data origin authentication : Who did the packet come from ?
Data integrity : was the packet changed in the transit path
Data Confidentiality : can anyone read the packet in the transit path
Anti-replay : Did i already receive this packet

Why use IPSEC VPN
Does not need static SP provisioning link MPLS
independent of SP access method
          > IPv4/IPv6 transport is the only requirement
- Allows both site to site & remote access
- Always on VS dial on demand
- offers data protection
  -- Main motivation for IPSEC

+++++++    HOW IPSEC WORKS        ++++++

- IPSEC is a N/W layer protocol (layer 3)
-- Different from SSL(7) or 802.1AE macsec (2)
- Main goal is to encrypt and authenticate IPv4 or IPv6 packets
    - Uses symmetric ciphers for encryption ( e.g 3DES)
    - Keyed hashing for authentication ( e.g MD5 )
- Used to create P2P tunnels between endpoints
     - GetVPN is an exception , which can use P2MP


 ++++  HOW IPSEC TUNNELS WORK  ++++
- Tunnels are dynamically negotiated through IKE
   - Main goal is to not define crypto keys manually
- IPSEC use two data structures to build a tunnel

Security association (SA)
  - An agreement of ipsec parameters
  - Maintains encryption & authentication keys on peers

Security parameter index ( SPI)
  - Field in packet header to select SA on receiver
  - Analogous to VLAN header or MPLS Label

ISAKMP vs IKE

-- ISAKMP / IKE are the negotiation protocols used to form SAs
-- Internet security association key management protocol is the framwork
-- says that authentication & keying occurs

-- Internet key exchange ( IKE)
-- IKE is the actual implementation
-- Defines how authentication and keying occurs

In general ISAKMP/IKE terms are interchangeable 

IKEv1 VS. IKEv2 Negotiation

-- IKE v1 was the original implementation
-- spread across lots of RFCs
-- Problem with  Interoperability with same feature  

-- IKE v2 adds new improvements
    -- Simplified RFC & Packet formats , better interoperability
    -- More flexible designs
        -- E.g use pre-shared keys on one but certificates on the other
        -- supports more secure "suite B" algorithm

-- No change to IPSEC data plane only control plane (IKE)


 IPSEC Tunnel Negotiation with IKE
-- goal of ipsec exchange is to establish SAs
  -- occurs through two main negotiation phase using IKE


-- IPSEC phase 1
  -- Authenticate endpoints and build a secure tunnel for further negotiation
  -- Result is called the ISAKMP SA

-- IPSEC phase 2
  -- Establish the tunnel used to protect the actual data traffic
  -- Result is called the IPSEC SA

 Negotiating the ISAKMP SA
-- During IKE phase 1 , peers negotiate 4 main parameters
    -- Authentication method
    -- Diffi - hellman group ( 1/2/5/ ----)
    -- Encryption type (DES/ 3DES / AES)
    -- Hash algorithm ( MD5 / SHA 1 )

 IKE Authentication - 2 ways 
     -- Pre-shared keys (PSK)
     -- X.509 Certificates (PKI)

PSK is easy , but PKI is scalable
o PSKs are difficult to maintain and change
o PKI allows easy revocation & also hierarchy

IKE v2 adds improved authentication : e.g EAP methods

IKE Diffie-Hellman group 
-- DH is the method to exchange crypto keys
    -- DH group number determines strength of keys
       -- Higher group is better , but at expense of CPU

-- Result of DH is what 3DES , AES etc , use as their symmetric keys

IKE Encryption
o Encryption algorithm used to protect the traffic
    o DES, 3 DES , AES-128,256 etc
    o Higher is better but at the expense of CPU
    o Some can be h/w accelerated
    i.e AES crypto offload card

IKE v2 ------- RFC 4307

IKE Hashing
 -- One way hash used to authenticate the packet
            o if hashes match , the packet was not modified in transit
            o Higher is better , but again at the expense of CPU


Hashes supported depends on IKE version

            o IKE v1 MD5 & SHA-1
            o IKE v2 SHA - 256 , SHA - 384 etc

 ISAKMP Policies:

o Combinations of IKE params are ISAKMP policy
   o IKE initiator sends all its policies through a proposal
   o IKE respond checks received policies against its own
   o First match is used , based on lowest priority value
   o Else , connection is rejected

After phase 1 completes , an encrypted tunnel exists between the peers 

o phase 2 negotiation can now be hidden from devices in transit

Negotiating the IPSEC SA
o In phase 2 peers agree on more parameters ......
>> security protocol
      encapsulating security payload (ESP ) or Authentication header (AH)
>> encapsulation mode
       tunnel mode or transport mode
>> encryption
      DES, 3 DES , AES , etc
>> authentication
      MD5, SHA, SHA-256, SHA - 512 etc
>>  Combination of these is called IPSEC Transform set

IPSEC security protocols:

>> IPSEC supports two data plane encapsulations
          AH & ESP


AH vs ESP

AH

o IP Protocol number 51
o Data origin authentication includes IP Header
o Data integrity

ESP

o IP Protocol number 50
o Data origin authentication encludes IP Header
o Data integrity
o Data encryption
o Anti - reply

AH supports only authentication

o Rarely used for VPNs due to this reason
o IPv6 OSPFv3 can use AH for neighbor authentication

ESP supports authentication & encryption

o Preferred method of IPSEC . VPNs
o Most remote access clients only supports ESP


 Tunnel vs Transport
AH & ESP supports 2 modes of encapsulation

Transport : 
o original ip header retained
o payload and layer 4 header authenticated encrypted with ESP
o complete pkt authenticated with AH
o typically used in host to host IPSEC


Tunnel : 
o adds new ip header
o original header & payload authenticated / encrypted with ESP
o complete packet authenticated with AH
o typically used between ipsec gateways or host to IPSEC gateway


Negotiating the IPSEC SA (cont.)
>> Phase 2 negotiation also includes .....
>> Proxy identities
     o Defines what traffic will be protected
     o Also called " proxy acls "

>> Security Association (SA) lifetime
     o How often should we re-key

>> Perfect forward secrecy (PFS)
     o Should we re-negotiated DH before we re-key

 IPSEC proxy identities 

>> Defines what traffic goes into the ipsec-tunnel
      o i.e the "interesting traffic " to trigger the tunnel
>> Proxy ACLs should be mirror images
      o Take a tunnel from peer A to Peer B
      o Peer A says traffic from X > Y
      o Peer B says traffic from Y > X

 Like any other parameter mismatch , misconfiguration will cause tunnel failure 

SA Lifetimes: 
>> ISAKMP/ IPSEC SA both have finite lifetime
     o Before expiration , SA is re-keyed
     o Lifetime can be time or bits
     o Lower value of initiator or receive is negotiated

What do we re-key with ?
      o previous DH exchange or new DH exchange
      o depends on PFS

Perfect Forward secrecy (PFS)

o without PFS, IPSEC SA re-keying is done from the initially negotiated master key
o one compromised key theoretically means all keys compromised

>> PFS cause new DH exchange prior to rekeying
   o makes IPSEC SA keys independent from previous ones
   o more secure but at the expense of CPU


 IPSEC control plane vs Data plane 

>> All traffic is unicast IPv4 / IPv6
>> IPSEC control plane (ISAKMP)
             o udp 500
             o UDP 4500 if going through NAT
>> IPSEC Data Plane
             o ESP (50) or AH (51)
             o ESP over udp 4500 if going through NAT

>> Some platforms allow custom ports
             o e.g ASA firewall 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++

vPC

vPC by Giga Networkers on Scribd

VxLAN Underlay Fabric Convergence

VxLan underlay fabric convergence is based on 3 factors

• IGP Convergence 
• PIM Convergence 
• BGP Convergence 

Factors must be addressed separately to achieve high availability for VxLan overlay flow

Generally 4 factors affect IGP convergence time

1. Failure Detection time           : is the neighbor down ?
2. Event propagation time          : Tell neighbor about the change
3. Recalculation Time                 : Run SPF/DUAL/ etc calculation 
4. Forwarding table update time : Install new paths

• Failure Detection Time 
• How long does it take me to realize there is a failure ?
• Example failure detection 
• Link up/down event
• Routing protocol hello/dead timers
• IP SLA & EEM
• Bidirectional Forwarding Detection (BFD) 

• Event Propagation Time
• How long does it take to tell everyone else ?
• Example event propagation 
• Eigrp Query/Reply
• OSPF LSA Flooding Procedure 
• BGP update / withdraw

• Recalculation Time
• How long does it take me to decide on the new topology
• Example recalculation Time 
• Eigrp DUAL/ OSPF SPF / BGP Best path selection 

• Forwarding Table update Time
• How long does it take me to install the changes 
• Example update time 
• Eigrp topology to RIB download 
• RIB to S/W FIB download
• S/W FIB to H/W TCAM download 

Example ospf re convergence 

ospf failure detection 

   - Neighbor dead interval expires

ospf event propagation 

   - LSA flooding procedure 

ospf recalculation time 

    - SPF runtime 

forwarding table update time

    - ospf database to RIB installation , RIB to FIB , FIB to TCAM

How do we affect convergence 

Some factors are s/w & configuration dependent 

e.g smaller eigrp query domain is better 

e.g ospf stub areas are better 

e.g unnumbered fabric links or prefix-suppresison is better 

Some factor are h/w dependent 

e.g SPF runtime is function of CPU Size

e.g TCAM download is function of the line card

Methods of modifying convergence time 

Can be both reactive & proactive .

Reactive optimizations:

e.g Carrier delay & link de bounce timer

e.g Fast Hellos & BFD

e.g ospf LSA & SPF pacing

e.g FIB prefix prioritization 

Proactive optimizations 

Eigrp feasible successors

ospf loop free alternate (LSA)

BGP prefix independent convergence 

MPLS traffic engineering fast reroute ( TE FRR)

--------------------------------------+++++++++++++++--------------------------