FRR Routing v8.0 is out and happy to see SR

Hey,

For (perhaps) futur projet I read different documentations around Bird, FRR Routing, … and I am really happy to see in FRR Routing v8.0 the new ‘pathd‘ daemon, which implement SR (Segment Routing). It is really cool to see this.

There is others new feature which have been implemented in this release and are major IMHO.

  • TI-LFA for OSPF and IS-IS (great too for SR) ;
  • VRF for OSPFv3 ;
  • EVPN full-implementation.

It is really great work !!!

More information there : https://frrouting.org/release/8.0/

See you soon 🙂

Long long time ago, blog and FreeBSD…

It was a long long timeago I wrote here. ot of things happens to me but I don’t think it is the time and place to explain it.

This post is about a new experience to me : hosting this blog on FreeBSD machine. I am in love with BSD but don’t use it everyday. Networking&Telco is not an professional area where you can use it or your employer allow you to use it. Damn Windows, Teams, … and his egemony.

I will move this blog from Debian to FreeBSD server. I think it will lot of fun. If I have FreeBSD’s tips or remarks I will post it here. By the way I am currently studying for Cisco’s CCNP SPCOR (350-501) exam. Either I will try to give me a kick in the ass to post more technical posts.

Have fun 🙂

Site to site IKEv2 tunnel

Hello guys,

Here it is a tips / reminder how to implement an site-ot-site IKEv2 tunnel :

crypto ikev2 proposal aes-cbc-256-proposal 
 encryption aes-cbc-256
 integrity sha1
 group 2
crypto ikev2 policy policy1 
 match address local x.x.x.x
 proposal aes-cbc-256-proposal
crypto ikev2 keyring v2-kr1
 peer abc
  address y.y.y.y
  pre-shared-key somesecretpass
 !
crypto ikev2 profile profile1
 description IKEv2 profile
 match address local x.x.x.x
 match identity remote address y.y.y.y 255.255.255.255 
 authentication local pre-share
 authentication remote pre-share
 keyring v2-kr1

crypto ipsec transform-set myset esp-des esp-md5-hmac 

crypto map mymap 20 ipsec-isakmp 
 set peer y.y.y.y
 set security-association lifetime seconds 27000
 set transform-set ESP-AES-SHA 
 set ikev2-profile profile1
 match address 120

With ACL 120 is your flows / SA and your implement your crypto map on your WAN interface.

IPv6 prefix delegation feature

We will dive into IPv6 prefix delegation prefix.

First of all, we will make a real simple topology :

ipv6-delegation-simple

R1 acts as a DHCP server and use the prefix delegation feature. But how it works ? How it is configured ?

R1 :

ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool POOLv6
 prefix-delegation pool p lifetime 180 120
 domain-name lucas.fr.eu.org

ipv6 local pool p 2001:DB8::/40 48

interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 duplex half
 ipv6 address 2A02::1/48
 ipv6 enable
 ipv6 dhcp server POOLv6


R1#   show ipv6 dhcp interface 
FastEthernet0/0 is in server mode
  Using pool: POOLv6
  Preference value: 0
  Hint from client: ignored
  Rapid-Commit: disabled
R1#

R2 :

interface FastEthernet0/0
 duplex half
 ipv6 address autoconfig default
 ipv6 enable
 ipv6 dhcp client pd prefix-from-provider

interface FastEthernet1/1
 no ip address
 duplex auto
 speed auto
 ipv6 address prefix-from-provider ::1:0:0:0:1/64
 ipv6 enable

R2#show ipv6 dhcp interface 
FastEthernet0/0 is in client mode
  Prefix State is OPEN
  Renew will be sent in 00:00:04
  Address State is IDLE
  List of known servers:
    Reachable via address: FE80::C805:ADFF:FE80:0
    DUID: 00030001CA05AD800000
    Preference: 0
    Configuration parameters:
      IA PD: IA ID 0x00040001, T1 60, T2 120
        Prefix: 2001:DB8::/48
                preferred lifetime 120, valid lifetime 180
                expires at May 03 2016 10:53 PM (125 seconds)
      Domain name: lucas.fr.eu.org
      Information refresh time: 0
  Prefix name: prefix-from-provider
  Prefix Rapid-Commit: disabled
  Address Rapid-Commit: disabled
R2#

Debug trace on R2 (debug ipv6 dhcp) :

*May  3 22:36:11.859: IPv6 DHCP: Sending RENEW to FF02::1:2 on FastEthernet0/0
*May  3 22:36:11.859: IPv6 DHCP: DHCPv6 changes state from OPEN to RENEW (TIMEOUT) on FastEthernet0/0
*May  3 22:36:11.879: IPv6 DHCP: Received REPLY from FE80::C805:ADFF:FE80:0 on FastEthernet0/0
*May  3 22:36:11.879: IPv6 DHCP: Processing options
*May  3 22:36:11.879: IPv6 DHCP: Adding prefix 2001:DB8::/48 to prefix-from-provider
*May  3 22:36:11.883: IPv6 DHCP: T1 set to expire in 60 seconds
*May  3 22:36:11.883: IPv6 DHCP: T2 set to expire in 120 seconds
*May  3 22:36:11.883: IPv6 DHCP: DHCPv6 changes state from RENEW to OPEN (REPLY_RECEIVED) on FastEthernet0/0

We have acquired the prefix via PD aka Prefix Delegation feature :

R2#show ipv6 general-prefix 
IPv6 Prefix prefix-from-provider, acquired via DHCP PD
  2001:DB8::/48 Valid lifetime 158, preferred lifetime 98
   FastEthernet1/1 (Address command)
R2#

On R3 or R4 :

interface FastEthernet0/0
 no ip address
 duplex half
 ipv6 address autoconfig default
 ipv6 enable
end


2#show ipv6 dhcp interface 
FastEthernet0/0 is in client mode
  Prefix State is OPEN
  Renew will be sent in 00:00:04
  Address State is IDLE
  List of known servers:
    Reachable via address: FE80::C805:ADFF:FE80:0
    DUID: 00030001CA05AD800000
    Preference: 0
    Configuration parameters:
      IA PD: IA ID 0x00040001, T1 60, T2 120
        Prefix: 2001:DB8::/48
                preferred lifetime 120, valid lifetime 180
                expires at May 03 2016 10:53 PM (125 seconds)
      Domain name: lucas.fr.eu.org
      Information refresh time: 0
  Prefix name: prefix-from-provider
  Prefix Rapid-Commit: disabled
  Address Rapid-Commit: disabled
R2#

If we debug we will see (debug ipv6 interface, debug ipv6 dhcp, debug ipv6 nd) :

May  3 22:05:01.335: ICMPv6-ND: Neighbour FE80::C806:ADFF:FE81:1D on FastEthernet0/0 : LLA ca06.ad81.001d
*May  3 22:05:01.335: ICMPv6-ND: INCMP -> STALE: FE80::C806:ADFF:FE81:1D
*May  3 22:05:01.335: IPv6-Address: intfid_algo is notactive on intf 4
*May  3 22:05:01.339: IPv6-Address: intfid_algo is active on intf 4
*May  3 22:05:01.339: IPv6-Address: Generating IntfID rc 0, prefix: 2001:DB8:0:1::/64, address 2001:DB8:0:1:C808:ADFF:FE85:0
*May  3 22:05:01.343: IPv6-Address: Prefix Information change for 2001:DB8:0:1::/64, 0x0 -> 0x1E0
*May  3 22:05:01.343: IPv6-Address: Adding prefix 2001:DB8:0:1::/64 to FastEthernet0/0
*May  3 22:05:01.343: IPv6-Address: Adding operating owner prefix configured on FastEthernet0/0
*May  3 22:05:01.347: IPv6-Address: Adding operating owner address configured on FastEthernet0/0
*May  3 22:05:01.347: IPv6-Address: Address 2001:DB8:0:1:C808:ADFF:FE85:0 configured on FastEthernet0/0
*May  3 22:05:01.347: IPv6-Addrmgr-
R4(config-if)#ND: DAD request for 2001:DB8:0:1:C808:ADFF:FE85:0 on FastEthernet0/0
*May  3 22:05:01.347: ICMPv6-ND: Sending NS for 2001:DB8:0:1:C808:ADFF:FE85:0 on FastEthernet0/0
*May  3 22:05:01.351: ICMPv6-ND: Autoconfiguring 2001:DB8:0:1:C808:ADFF:FE85:0 on FastEthernet0/0
*May  3 22:05:02.351: IPv6-Addrmgr-ND: DAD: 2001:DB8:0:1:C808:ADFF:FE85:0 is unique.
*May  3 22:05:02.351: ICMPv6-ND: Sending NA for 2001:DB8:0:1:C808:ADFF:FE85:0 on FastEthernet0/0
*May  3 22:05:02.355: IPv6-Address: Address 2001:DB8:0:1:C808:ADFF:FE85:0/64 is up on FastEthernet0/0

Finally, we are able to ping the DHCPv6 server :

R4#ping ipv6 2A02::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A02::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/45/96 ms
R4#traceroute 2A02::1

Type escape sequence to abort.
Tracing the route to 2A02::1

  1 2001:DB8:0:1::1 12 msec 36 msec 12 msec
  2 2A02::1 8 msec 56 msec 36 msec
R4#

IP SLA operation

IP SLA is a great tool to automation some treatment. You could do great things with it. We will work on IP SLA Reaction here.

What is it ? You could launch some action on some state of an IP SLA. Such as (Even if it is not a good example) : some nested ping.

ip-sla-reaction

 

 

 

 

 

 

 

The job here, is to check R4 – R3 and R4 – R2 if IP SLA beetween R1 – R4 is awful.

We could do this such as :
R4 :

ip sla 1
 udp-jitter 10.1.12.1 3200 source-ip 10.1.43.4 source-port 6565 codec g711ulaw codec-size 128
 frequency 5
ip sla schedule 1 start now life forever 

ip sla 43 
 icmp-echo 10.1.43.3 source-ip 10.1.43.4
 frequency 5
ip sla schedule 43 start pending life 60

ip sla 42 
 icmp-echo 10.1.32.2 source-ip 10.1.43.4
 frequency 5
ip sla schedule 42 start pending life 60

ip sla reaction-trigger 1 43
ip sla reaction-trigger 43 42
ip sla reaction-configuration 1 react MOS threshold-type consecutive 4 threshold-value 390 220 action-type trapAndTrigger
ip sla reaction-configuration 43 react rtt threshold-value 100 50 threshold-type immediate action-type trapAndTrigger
ip sla reaction-configuration 42 react rtt threshold-value 100 50 threshold-type immediate action-type trapOnly

snmp-server host 10.1.1.1
snmp-server enable traps syslog

We do an analyze on each segment of path and if it fails on our condition, it traps it.

Obvisouly on R1 :

ip sla responder

BGP rib-failure

I think everyone now what is a RIB-Failure in BGP context. It sounds obviously as an exact same route with a lowest AD as {e|i}BGP. We have VRF-Lite on R1 here :

Capture d’écran 2016-02-01 à 22.29.40

We have :

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

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST)
 *>  10.1.1.1/32      12.0.0.2                 0             0 65002 ?
 *>  10.2.2.1/32      12.0.0.2                 0             0 65002 ?
 r>  10.3.3.1/32      12.0.0.2                 0             0 65002 ?
 r>  10.4.4.1/32      12.0.0.2                 0             0 65002 ?
 r>  10.5.5.1/32      12.0.0.2                 0             0 65002 ?
 r>  10.5.5.5/32      12.0.0.2                 0             0 65002 ?
 r>  10.6.6.6/32      12.0.0.2                 0             0 65002 ?
 r>  12.0.0.0/24      12.0.0.2                 0             0 65002 ?
R1#
R1#show ip route vrf CUST

Routing Table: CUST

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 2 subnets
B        10.1.1.1 [20/0] via 12.0.0.2, 00:37:49
B        10.2.2.1 [20/0] via 12.0.0.2, 00:37:49
      12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        12.0.0.0/24 is directly connected, Ethernet0/0
L        12.0.0.1/32 is directly connected, Ethernet0/0
R1#

So the only route we can have a RIB-Failure due to lowest AD is : 12.0.0.0/24. What is the problem with others ?
We can know this by using :

R1#show ip bg vpnv4 vrf CUST rib-failure
  Network            Next Hop                      RIB-failure   RIB-NH Matches
Route Distinguisher: 65001:1 (default for vrf CUST)
10.3.3.1/32        12.0.0.2                      Route limit              n/a
10.4.4.1/32        12.0.0.2                      Route limit              n/a
10.5.5.1/32        12.0.0.2                      Route limit              n/a
10.5.5.5/32        12.0.0.2                      Route limit              n/a
10.6.6.6/32        12.0.0.2                      Route limit              n/a
12.0.0.0/24        12.0.0.2            Higher admin distance              n/a
R1#

The problem is :

ip vrf CUST
 rd 65001:1
 maximum routes 4 80
!

You know surely now why it is in ‘RIB-Failure’ state…

BGP review – ‘received-only’ prefix state

Today a little review :

edge12.bor03>show ip bg 37.8.8.8
BGP routing table entry for 37.8.0.0/20, version 47221703
Paths: (3 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  15975, (received-only)
    17.69.240.117 from 17.69.240.117 (17.69.255.1)
      Origin IGP, metric 16, localpref 500, valid, internal
  12671 15975 15975 15975 15975, (received & used)
    46.218.1.1 from 46.218.1.1 (172.17.1.6)
      Origin IGP, localpref 100, valid, external, best
  12671 15975 15975 15975 15975, (received & used)
    46.218.1.1 from 46.218.1.1 (172.17.1.2)
      Origin IGP, localpref 100, valid, external
edge12.bor03>

Why the path through 17.69.240.117 is not used, although it is the a better path to 37.8.0.0/20 ?
Why is it marked as “received-only”

“Received-only” means as it says that this prefix is received, stored in Adj-IN, but cannot be selected for a valid prefix. Why ?

Lot of reasons. Commons are : route-maps, NEXTHOP not reachable…

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

In my example, the problem is here : a route-map without an explicit permit.

Redback magic command

For those of you who are working with Redback equipments, this command can be useful :

[local]Redback# washoutthewash

Then you will have access to all commands the CLI hide you such as : ‘show sub ip’ or ‘show qos meter’ …

[CUSTOMER_1194]Redback# show sub act
CUST_8HL2@isp.vpn
        Session state Up
        Circuit   14/1:1 vpi-vci 1 928
        Internal Circuit   14/1:1:63/1/2/1407
        Interface bound  pppoe
        Current port-limit 1
        ppp mtu 1508 (applied)
        context-name CUSTOMER_1194 (applied)
        ip route 198.18.50.202 255.255.255.255 172.31.64.7  (applied)
        ip route 192.1.48.0 255.255.255.0 172.31.64.7  (applied)
        ip route 172.26.48.0 255.255.255.0 172.31.64.7  (applied)
        ip address 172.31.64.7 (applied)
        port-limit 1 (applied from sub_default)
[CUSTOMER_1194]Redback#show sub ?
  access-line       Show DSL line attributes of active subscribers
  active            Display active subscribers
  address           Display subscriber IP-Addresses
  agent-circuit-id  Show subscriber by agent circuit id
  agent-remote-id   Show subscriber by agent remote id
  all               Display all subscribers
  log               Display AAAd log
  session           Display subscriber by circuit
  summary           Display subscriber summary
  username          Display subscriber by username
  |                 Output Modifiers
  
[CUSTOMER_1194]Redback#washoutthewash
[CUSTOMER_1194]Redback#show sub ?
  access-line       Show DSL line attributes of active subscribers
  active            Display active subscribers
  address           Display subscriber IP-Addresses
  agent-circuit-id  Show subscriber by agent circuit id
  agent-remote-id   Show subscriber by agent remote id
  all               Display all subscribers
  debug             Display debug counters
  handle            Show subscriber by internal circuit handle
  ip-addr           Display subscriber by IP address
  log               Display AAAd log
  profile           Display subscriber profile info
  session           Display subscriber by circuit
  summary           Display subscriber summary
  username          Display subscriber by username
  |                 Output Modifiers
  
[CUSTOMER_1194]Redback#show sub ip 172.31.64.7
TYPE    CIRCUIT                    SUBSCRIBER         CONTEXT   START TIME    
--------------------------------------------------------------------------------
ppp     14/1:1 vpi-vci 1 928       CUST_8HL2@is CUSTOMER Aug 27 14:20:51
--------------------------------------------------------------------------------
Total=1
 
Type            Authenticating          Active          Disconnecting
PPP                          0               1                      0
PPPoE                        0               0                      0
DOT1Q                        0               0                      0
CLIPs                        0               0                      0
ATM-B1483                    0               0                      0
ATM-R1483                    0               0                      0
Mobile-IP                    0               0                      0
[CUSTOMER_1194]Redback#

GETVPN : Group Encrypted Transport VPN

Schema Here it comes. We will use the same topology as the last two blog posts.
This time we will play with GETVPN. GETVPN is a Cisco technology. One of the advantage of GETVPN is that we are able to build somespoke-to-spoke IPSEC tunnel without Tunnel interface and it is highly scalable.

We could say to me : ok, man ! but you could do this by means of static tunnels. Yes you can, BUT with GETVPN you can maintain easily full mesh networks by means of Key Server and the GETVPN technology.

Tunnel is build between GM (Group Member). The Key Server (KS) maintains security policies and is not part of the Forwarding Path. This server is here to provide security policy and make it possible to GM to build a encrypted tunnel between each other. No need to pass through a central node. GETVPN is a answer, DMVPN phase 3 is another 🙂

We have R4 as KS with a loopback address : 4.4.4.4/32
We have R2 and R3 as our spokes. These routers has each other a loopback 99 with a different /24 subnet.

  • R2 : 99.99.99.0/24
  • R3 : 100.100.100.0/24

Let’s go and see how it is configured. Begin with the Key Server :

crypto key generate rsa modulus 1024 label REKEYRSA

crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0
crypto ipsec transform-set SET esp-3des esp-md5-hmac
 mode tunnel
crypto ipsec profile PROFILE
 set transform-set SET
crypto gdoi group GDOI-GROUP1
 identity number 12345
 server local
  rekey algorithm aes 128
  rekey authentication mypubkey rsa REKEYRSA
  rekey transport unicast
  sa ipsec 1
   profile PROFILE
   match address ipv4 getvpn-acl
   replay time window-size 5
   no tag
  address ipv4 4.4.4.4

ip access-list extended getvpn-acl
 permit ip 99.99.99.0 0.0.0.255 100.100.100.0 0.0.0.255
 permit ip 100.100.100.0 0.0.0.255 99.99.99.0 0.0.0.255
 deny   ip any any

Now R2 and R3 :

R2 : 

crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0
crypto ipsec transform-set SET esp-3des esp-md5-hmac
 mode tunnel
crypto ipsec profile PROFILE
 set transform-set SET
crypto gdoi group GDOI-GROUP1
 identity number 12345
 server address ipv4 4.4.4.4
crypto map gdoimap 1 gdoi
 set group GDOI-GROUP1
 crypto map gdoimap

interface Ethernet0/1
 ip address 123.0.0.2 255.255.255.0
 ip router isis
 crypto map gdoimap
R3 : 
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0
crypto ipsec transform-set SET esp-3des esp-md5-hmac
 mode tunnel
crypto ipsec profile PROFILE
 set transform-set SET
crypto gdoi group GDOI-GROUP1
 identity number 12345
 server address ipv4 4.4.4.4
crypto map gdoimap 1 gdoi
 set group GDOI-GROUP1
 crypto map gdoimap

GM use and interact with the KS to build their IPSec SA. Here, the security policy is identified by “identity number 12345”.

To make my topology works I have been obliged to add a static route towards my remote endpoints. I have been obliged to due to a bug on my IOS. It crashes if I add a “reverse-route” command in my crypto map.

Now, we could try to ping each other :

R2#  ping 100.100.100.3 so lo 99
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.3, timeout is 2 seconds:
Packet sent with a source address of 99.99.99.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/7 ms
R2#

Good ! it pings. Let’s see if it is encrypted :

https://www.cloudshark.org/captures/a99bd1404eaa or http://www.clucas.fr/downloads/GETVPN.pcap

Great it works 🙂

Now see some troubleshooting commands :

R2#show crypto session
Crypto session current status

Interface: Ethernet0/1
Session status: UP-ACTIVE
Peer: 0.0.0.0 port 500
  Session ID: 0
  IKEv1 SA: local 123.0.0.2/848 remote 4.4.4.4/848 Active
  IPSEC FLOW: deny ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 0, origin: crypto map
  IPSEC FLOW: permit ip 100.100.100.0/255.255.255.0 99.99.99.0/255.255.255.0
        Active SAs: 2, origin: crypto map
  IPSEC FLOW: permit ip 99.99.99.0/255.255.255.0 100.100.100.0/255.255.255.0
        Active SAs: 2, origin: crypto map

R2#
R2#show crypto gdoi gm
Group Member Information For Group GDOI-GROUP1:
    IPSec SA Direction       : Both
    ACL Received From KS     : gdoi_group_GDOI-GROUP1_temp_acl

    Group member             : 123.0.0.2       vrf: None
       Local addr/port       : 123.0.0.2/848
       Remote addr/port      : 4.4.4.4/848
       fvrf/ivrf             : None/None
       Version               : 1.0.8
       Registration status   : Registered
       Registered with       : 4.4.4.4
       Re-registers in       : 2673 sec
       Succeeded registration: 1
       Attempted registration: 1
       Last rekey from       : 4.4.4.4
       Last rekey seq num    : 10
       Unicast rekey received: 2
       Rekey ACKs sent       : 2
       Rekey Rcvd(hh:mm:ss)  : 00:11:50
       DP Error Monitoring   : OFF

R2#
R2# show crypto ipsec sa

interface: Ethernet0/1
    Crypto map tag: gdoimap, local addr 123.0.0.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (100.100.100.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (99.99.99.0/255.255.255.0/0/0)
   Group: GDOI-GROUP1
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 25, #pkts decrypt: 25, #pkts verify: 25
[...]
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (99.99.99.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (100.100.100.0/255.255.255.0/0/0)
   Group: GDOI-GROUP1
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 25, #pkts encrypt: 25, #pkts digest: 25
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
[...]

Ok each SA encrypt and decrypts the correct number of packets 🙂

KS side :

R4#show crypto gdoi ks
Total group members registered to this box: 2

Key Server Information For Group GDOI-GROUP1:
    Group Name               : GDOI-GROUP1
    Re-auth on new CRL       : Disabled
    Group Identity           : 12345
    Group Members            : 2
    IPSec SA Direction       : Both
    ACL Configured:
	access-list getvpn-acl


R4#show crypto gdoi ks acl
Group Name: GDOI-GROUP1
 Configured ACL:
   access-list getvpn-acl  permit ip 99.99.99.0 0.0.0.255 100.100.100.0 0.0.0.255
   access-list getvpn-acl  permit ip 100.100.100.0 0.0.0.255 99.99.99.0 0.0.0.255
   access-list getvpn-acl  deny ip any any


R4#

For more information : http://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html

Have fun with GETVPN !!

IPSEC VTI

IPSEC VTI stands for IPSEC Virtual Tunnel Interface.

Besides traditionnal IPSEC configuration with cyrpto map, VTI allows to use an interface. It is useful to apply some policies as we can do as other : service-policy, …

For this example, I will use the previous topology with four routers (R1, R2, R3, R4) : see the blog post below for a diagram.

I will implement a IPSEC VTI tunnel between R2 and R4.

VTI is really simple to implement :

 

R4#  show run int tun 11
Building configuration...

Current configuration : 179 bytes
!
interface Tunnel11
 ip address 11.1.1.4 255.255.255.0
 tunnel source Loopback0
 tunnel mode ipsec ipv4
 tunnel destination 2.2.2.2
 tunnel protection ipsec profile PROFILE
end

R4#show run | sec crypto
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0        
crypto ipsec transform-set SET esp-3des esp-md5-hmac 
 mode tunnel
crypto ipsec profile PROFILE
 set transform-set SET 
R4#

And :

R2#show run | sec crypto
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0        
crypto ipsec transform-set SET esp-3des esp-md5-hmac 
 mode tunnel
crypto ipsec profile PROFILE
 set transform-set SET 
R2#show run int tun 11
Building configuration...

Current configuration : 179 bytes
!
interface Tunnel11
 ip address 11.1.1.2 255.255.255.0
 tunnel source Loopback0
 tunnel mode ipsec ipv4
 tunnel destination 4.4.4.4
 tunnel protection ipsec profile PROFILE
end

R2#

When the two tunnels are implemented the two tunnels states to up/up. Previous state is up/down.

We could do this kind of things and others :

 

R4(config)#int tun 11
R4(config-if)#service-policy output pm

R4#ping 11.1.1.2 rep 200
Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 11.1.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (200/200), round-trip min/avg/max = 3/7/25 ms
R4#show policy-map interface tunnel 11
 Tunnel11 

  Service-policy output: pm

    Class-map: class-default (match-any)  
      200 packets, 20000 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any 
R4#