• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

LISP + GETVPN as alternative to DMVPN+OSPF+GETVPN

on

  • 5,672 views

These slide are from a presentation I gave at the Cisco NAG2010 conference about using LISP to build large VPN's over the internet instead of regular GRE or DMVPN based setups.

These slide are from a presentation I gave at the Cisco NAG2010 conference about using LISP to build large VPN's over the internet instead of regular GRE or DMVPN based setups.

Statistics

Views

Total Views
5,672
Views on SlideShare
5,672
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    LISP + GETVPN as alternative to DMVPN+OSPF+GETVPN LISP + GETVPN as alternative to DMVPN+OSPF+GETVPN Presentation Transcript

    • Applied LISP
      LISP is good for you!
      Job Snijders
      job@instituut.net
      Protégé of InTouch N.V., The Netherlands
    • Who am I?
      Job Snijders
      One of the chosen few: I got native v6 at home
      Love bleeding edge stuff
      Co-author LISP LCAF draft
    • What’s InTouch NV?
      16 years old (73 in internet years)
      Managed Service provider
      Nice & decent network through West-Europe
      Sells technology independent products which we call “services”
      Example: Large private networks for multinationals in multi-tenant way
    • What is LISP?
      http://en.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol
      Abstraction layer
      Location independent prefixes
      IPv4 over IPv4, IPv6 over IPv4, IPv4 over IPv6, IPv6 over IPv6
    • Problem statement
      Dear Santa,
      I’d like a manageable way of building large virtual private networks over the internet.
      your friend,
      Job
    • Our typical “Satellite” office
      2 (cheap) internet connections from 2 ISP’s
      1 (cheap) router
      1 RFC1918 prefix behind it
      5 to 10 people behind it that need access to corporate IT: Active Directory, Exchange, etc
    • Our typical “Satellite” office
    • Current approach
      Remember: We don’t own the last mile. We have to deliver over the top.
      Build 2 GRE or DMVPN tunnels
      Use plain IPSEC or GETVPN
      OSPF for tunnel/link failover
    • DMVPN is horrible:
    • Quick overview
      Replace DMVPN + OSPF with LISP
      GETVPN stays because we need security
      Components:
      Map-Server (NX-OS)
      Key-Server (IOS)
      Proxy Router (IOS because we do GETVPN)
      xTR (IOS)
    • Helicopter overview
    • Proxy Router (PxTR)bridge between LISP world and VRF
      Public IP address (reachable for all xTR’s)
      Talk BGP with VRF intouch-office
      GRE Tunnel to MapServer for LISP+ALT
      Talk BGP with MapServer
      GRE Tunnel to Keyserver
      because PxTR and xTR functionality don’t mix (this is an implementation limitation, not protocol)
    • PxTR Picture
      interface LISP0
      ip policy route-map nexthop
      crypto map GETVPN_MAP
      end
      route-map nexthop permit 10
      match ip address 10
      set ip next-hop 172.16.0.1
    • PxTRConfig
      ip lisp path-mtu-discovery min 1280 max 1500
      ip lisp alt-vrf lisp
      ip lisp proxy-etr
      ip lisp proxy-itr 212.2.2.2
      interface FastEthernet0/1.300
      encapsulation dot1Q 300
      ip address 172.16.0.20 255.255.255.0
      ipmtu 1400
      iptcp adjust-mss 1360
      address-family ipv4 vrf lisp
      no synchronization
      redistribute connected
      redistribute static
      neighbor 10.0.1.1 remote-as 65100
      neighbor 10.0.1.1 update-source Tunnel321
      neighbor 10.0.1.1 activate
      neighbor 10.0.1.1 next-hop-self
      neighbor 10.0.1.1 soft-reconfiguration inbound
      exit-address-family
    • Pxtr# show ip route vrf lisp
      Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
      C 10.0.1.0/30 is directly connected, Tunnel321
      L 10.0.1.2/32 is directly connected, Tunnel321
      172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks
      B 172.16.31.1/32 [20/0] via 10.0.1.1, 6d09h
      B 172.16.31.3/32 [20/0] via 10.0.1.1, 1d06h
      B 172.16.31.4/32 [20/0] via 10.0.1.1, 6d09h
      B 172.16.31.5/32 [20/0] via 10.0.1.1, 5d20h
      B 172.16.31.6/32 [20/0] via 10.0.1.1, 1d05h
      B 172.16.42.0/24 [20/0] via 10.0.1.1, 6d09h
      B 172.16.43.0/24 [20/0] via 10.0.1.1, 6d09h
      B 172.16.45.0/24 [20/0] via 10.0.1.1, 5d20h
      B 172.16.46.0/24 [20/0] via 10.0.1.1, 1d04h
    • MapServer
      Similar to DNS Server
      Public reachable IP address
      Not a part of the GETVPN cloud
      xTR’s register themselves at the MapServer
      PxTR talks with MapServer to know who is where (over that GRE tunnel)
    • MapServer picture (think DNS!)
    • MapServerConfig
      lisp site jobsnijders-thuis
      eid-prefix 172.16.31.3/32
      eid-prefix 172.16.42.0/24
      authentication-key 3 28923r98234ed6cace39629cdd637
      description Job Snijders home
      lisp site kevin-home-xtr
      eid-prefix 172.16.31.6/32
      eid-prefix 172.16.46.0/24
      authentication-key 3 3fac3b00cfbfd17b3e9ec69b8c43efd
      description Kevin home
      lisp site keyserver
      eid-prefix 172.16.31.1/32
      authentication-key 3 023489234eabce94ed6cace3dd637
      description keyserver
    • KeyServer
      Reachable for every xTR over the LISP cloud
      Has 1 /32 EID
      Tunnel to PxTR so PxTR can join in the GDOI without being an xTR
    • KeyServer Picture
    • KeyServerConfig #1 (LISP)
      lisp loc-reach-algorithm rloc-probing
      ip lisp database-mapping 172.16.31.1/32 IPv4-interface FastEthernet0/0.95 priority 0 weight 100
      ip lisp itr map-resolver 212.2.2.2
      ip lisp itr
      ip lisp etr map-server 212.2.2.2 key k3ys3rv3r
      ip lisp etr accept-map-request-mapping
      ip lisp etr
    • KeyServerconfig #2 (GETVPN)
      crypto isakmp policy 10
      encraes 256
      authentication pre-share
      group 2
      lifetime 1000
      !
      crypto isakmp policy 50
      encr 3des
      hash md5
      authentication pre-share
      group 2
      crypto isakmp key blablastrong address 0.0.0.0 0.0.0.0 no-xauth
      crypto isakmpkeepalive 10 periodic
      !
      !
      crypto ipsec transform-set GETVPN_TS esp-3des esp-sha-hmac
      !
      crypto ipsec profile GETVPN_PROFILE
      set transform-set GETVPN_TS
      !
      crypto gdoi group GETVPN_GROUP
      identity number 666
      server local
      rekey retransmit 10 number 2
      rekey authentication mypubkeyrsa public-intouch-office-ks-key
      rekey transport unicast
      saipsec 1
      profile GETVPN_PROFILE
      match address ipv4 LAN
      replay time window-size 36
      address ipv4 172.16.31.1
      interface Loopback0
      ip address 172.16.31.1 255.255.255.255
      !
      interface Tunnel10
      description to PxTR
      ip address 10.0.2.1 255.255.255.252
      tunnel source FastEthernet0/0.95
      tunnel destination 212.26.197.2
      !
      interface LISP0
      end
      ip access-list extended LAN
      deny udp any eq 848 any eq 848
      deny udp any eqisakmp any eqisakmp
      deny ip 172.16.31.0 0.0.0.255 172.16.31.0 0.0.0.255
      permit ip any any
    • xTR“the satellite office router”
      1 or 2 uplinks to the internet (just transport)
      Push all packets from LAN to PxTR or other xTR’s
      All “vpn” packets go with encrypted payload over the internets
      “internet access” is done via Firewall in the VRF
    • xTR Picture
      xTR
    • xTRconfig #1 (LISP)
      lisp loc-reach-algorithm rloc-probing
      ip lisp path-mtu-discovery min 1280 max 1500
      ip lisp use-petr 212.2.2.2
      ip lisp database-mapping 172.16.31.5/32 IPv4-interface ATM0/0/0.1 priority 0 weight 100
      ip lisp database-mapping 172.16.45.0/24 IPv4-interface ATM0/0/0.1 priority 0 weight 100
      ip lisp itr map-resolver 212.3.3.3
      ip lisp itr
      ip lisp etr map-server 212.3.3.3 key blablakeymap
      ip lisp etr accept-map-request-mapping
      ip lisp etr
    • xTRconfig #1 (GETVPN)
      crypto isakmp policy 10
      encraes 256
      authentication pre-share
      group 2
      lifetime 1000
      crypto isakmp key blablastrong address br /> 0.0.0.0 0.0.0.0 no-xauth
      !
      !
      crypto gdoi group GETVPN_GROUP_GM
      identity number 666
      server address ipv4 172.16.31.1
      client registration interface Loopback0
      crypto map GETVPN_MAP 10 gdoi
      set group GETVPN_GROUP_GM
      interface Loopback0
      ip address 172.16.31.5 255.255.255.255
      !
      interface LISP0
      crypto map GETVPN_MAP
      interface FastEthernet0/0
      description LAN
      ip address 172.16.45.1 255.255.255.0
      ipmtu 1400
      iptcp adjust-mss 1360
    • A Sample traceroute:from satellite office to server behind the VRF
      job@DennyCrane:~$ traceroute 172.16.4.202
      traceroute to 172.16.4.202 (172.16.4.202), 30 hops max, 60 byte packets
      1 172.16.42.253 (172.16.42.253) 6.102 ms 7.229 ms 7.212 ms
      2 172.16.0.20 (172.16.0.20) 18.650 ms 18.651 ms 18.622 ms
      3 172.16.0.1 (172.16.0.1) 13.968 ms 13.993 ms 14.020 ms
      4 172.16.4.202 (172.16.4.202) 13.931 ms 13.899 ms 13.897 ms
      job@DennyCrane:~$
    • Things to worry about
      MTU (with 1500 internet you have 1390 payload)
      Security
      Mapserver registrations are unencrypted
      RFC1918 ip addresses are visible when wiretapping
      But GETVPN protects everything and ensures integrity
      (So I think LISP is actually doing pretty fine)
    • Our status
      At InTouch we have been running this for a while now with a select group of “special” customers (read: guinea pigs)
    • Near Future
      We have got that much faith that we will deploy this to real customers in the next 3 weeks
    • Conclusion
      LISP is good for you!
      Any questions?
      job@instituut.net