Introduction to MPLS World

Many of us may hear this kind of term in the Networking Technology, but what is exactly the Multi-Protocol Label Switching or MPLS technology is?

in this blog, I want to write about an overview about the MPLS Technology.

first thing first, let's discuss about why MPLS? In the Past, Service Provider (SP) have to deal with a lot of Technology to deliver their services to the customer. One Customer may need to use the TDM technology, in this case the SP have to invest the TDM Technology, while other customer may need to use the Frame-Relay Technology, the SP should provide the Frame-Relay Technology. the more the technology, such as X.25, ISDN, ATM, and so on....., they should investing a ton of US$ to deal with all of those thing, including the device, technology, and people to operate it.

from the simple illustration above, we can determine, how complex, technically and Financially, to provide lots of services to the customer. Then, in the early 2000, Cisco start to develop a Technology called 'Tag-Switching', where the router will create an additional Tag tabel, that is derived from the Routing table,  for example, in the Routing Table (RIB), the router may have route to the 192.168.1.0/24 via F0/0, and then an additional tag table will be created by the router, and the router will say, If I want to get to the 192.168.1.0/24, I will add Tag "102", so other router in the path can only see the Tag, which is embedded to the Packet, without having to see All the Layer 3 information within the packet. In this case, guess what, now the forwarding dependencies is moving from the L3 RIB into the TAG Information basis.

And this TAG technology become more and more standard, so the IETF make the standard version of the Cisco Proprietary Tag-Switching into the LDP.

Ok, let's take a look the the following example and Scenario in order to get better understanding:

Topology

·         R1-R6 is being configured as MPLS CORE

·         R3 & R6  will have iBGP neighborship and use ‘bgp redistribute-internal’, so that R3 can advertise iBGP prefix to the RIP and R6 can advertise iBGP prefizes to the EIGRP.

Configuration

R1-R6 (LSR) ! Interface  Mpls ip ! End R3(PE/Edge LSR) ! router bgp 36  no synchronization  bgp router-id 3.3.3.3  bgp log-neighbor-changes  bgp redistribute-internal  redistribute rip  neighbor 6.6.6.6 remote-as 36  neighbor 6.6.6.6 update-source Loopback0  neighbor 6.6.6.6 next-hop-self  no auto-summary ! router rip  version 2  redistribute bgp 36 metric 3  network 10.0.0.0  no auto-summary ! end R6 (PE/Edge LSR) ! router eigrp 68  network 10.14.68.0 0.0.0.255  redistribute bgp 36 metric 1 1 1 1 1 ! router bgp 36  no synchronization  bgp router-id 6.6.6.6  bgp log-neighbor-changes  bgp redistribute-internal  redistribute eigrp 68  neighbor 3.3.3.3 remote-as 36  neighbor 3.3.3.3 update-source Loopback0  neighbor 3.3.3.3 next-hop-self  no auto-summary ! end

Verification

R3 Rack14R3#show mpls ldp neighbor     Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0         TCP connection: 1.1.1.1.646 - 3.3.3.3.40991         State: Oper; Msgs sent/rcvd: 89/87; Downstream         Up time: 01:02:21         LDP discovery sources:           FastEthernet0/0, Src IP addr: 150.14.13.1         Addresses bound to peer LDP Ident:           150.14.12.1     150.14.13.1     150.14.15.1     1.1.1.1 Rack14R3#show mpls forwarding-table Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 300        Pop Label  1.1.1.1/32       0             Fa0/0      150.14.13.1 301        Pop Label  150.14.12.0/24   0             Fa0/0      150.14.13.1 302        101        2.2.2.2/32       0             Fa0/0      150.14.13.1 303        102        4.4.4.4/32       0             Fa0/0      150.14.13.1 304        103        5.5.5.5/32       0             Fa0/0      150.14.13.1 305        104        6.6.6.6/32       0             Fa0/0      150.14.13.1 306        105        150.14.24.0/24   0             Fa0/0      150.14.13.1 307        106        150.14.45.0/24   0             Fa0/0      150.14.13.1 308        107        150.14.56.0/24   0             Fa0/0      150.14.13.1 309        No Label   10.7.7.0/24      0             Fa0/1      10.14.37.7 Rack14R3#show ip route 10.8.8.8 Routing entry for 10.8.8.0/24   Known via "bgp 36", distance 200, metric 156160, type internal   Redistributing via rip   Advertised by rip metric 3   Last update from 6.6.6.6 00:36:37 ago   Routing Descriptor Blocks:   * 6.6.6.6, from 6.6.6.6, 00:36:37 ago       Route metric is 156160, traffic share count is 1       AS Hops 0       MPLS label: none Rack14R3#show mpls forwarding-table 6.6.6.6 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 305        104        6.6.6.6/32       0             Fa0/0      150.14.13.1

R2 So every single MPLS Router, P Router in this case will not know the customer prefixes (10.x.x.x/24) but they know how to route it to the both PEs, which are R3 and R6 in this case Rack14R2#show ip route 10.8.8.8 % Network not in table Rack14R2#show mpls forwarding-table 10.8.8.8 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface Rack14R2#show mpls for Rack14R2#show mpls forwarding-table 6.6.6.6 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 204        404        6.6.6.6/32       22098         Fa0/1      150.14.24.4

Let’s create traffic from the R7 to the R8, then we will use debug on the R4 in this case to prove that the traffic will be encapsulated with mpls label ;) Rack14R7#ping 10.8.8.8 sou lo1 rep 10000 Type escape sequence to abort. Sending 10000, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds: Packet sent with a source address of 10.7.7.7 !!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!. Success rate is 98 percent (169/172), round-trip min/avg/max = 120/150/188 ms The traffic from R7 to the R8 is reachable, eventhough all the P routers don’t have the prefix in their CEF, but this scenario took advantage of the MPLS where P Routers don’t need to know the Customer Prefix, but still, they can route them ;) Rack14R4#show mpls forwarding-table 6.6.6.6 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 404        504        6.6.6.6/32       32662         Fa0/0      150.14.45.5 Rack14R4#show mpls forwarding-table 6.6.6.6 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 404        504        6.6.6.6/32       34904         Fa0/0      150.14.45.5

noted that form the above configuration, we can see that the MPLS Core will not know about the  detail information about the Customer prefix, R7&R8.

R3 & R6 are the router that directly facing to the customer, this router will called as Provider Edge (PE) in the Cisco term or Edge LSP in the standarization term

R1-R4 are the router within MPLS Domain, where they will send the Data, based on Label/TAG instead of L3 information, in our example :)

I hope this little explanation can help you to get the understanding of the MPLS technology ;)

GETVPN Using Multicast Distribution on the KS

Hi and Hello, first of all I want to say Happy New Year, we're now entering the 2013, what a day, one year has just been passed so quickly

in this blog I want to write about the latest VPN Technology from Cisco, which is GETVPN. the Idea of the GETVPN is to overcome the Tunnels configuration that should have been done by the Router, which is in the Large deployment, one router, usually HQ Router, should have handled a ton off VPN tunnel from branch offices. Hey, Cisco has developed DMVPN solution, so we only need one tunnel for all connectivity?!?

that is correct, from the Management perspective, you may have one tunnel in the DMVPN, but from the VPN perspective (Phase-1 & Phase-2 IPSec), you still have a lot of 'established' IPSec Tunnel.

Cisco came with the Idea to create a 'Tunnel-less' IPSec VPN technology, so that every router will not create tunnel to the others.

so, puff, the GETVPN technology was introduced. the GETVPN Technology offers benefit compare to the traditional IPSec VPN Technology, in term of:

- The key Distribution will be handled by separate router, called the Key Server (KS). You could say that the KS will work on the 'Control-Plane' of the Implementation. this KS will not involved in the Data-Plane portion in the IPSec VPN.

- Tunnel-Less IPSec VPN implementation, so that VPN Traffic will rely on the Basic Routing on the environment.

- Can deliver any-to-any VPN implementation much more easily and efficiently ;)

Ok, lets get to the point, in My blog I will show you the deployment of the GETVPN using Multicast Distribution for the communication between KS and Group Members (GM), which are the router that will participate in the VPN Data-Plane. Why using multicast? Since most of the example, especially in the CiscoDoc, at the time of the writing, was done using unicast, So I think it is better to demonstrate something quite different :p

Here are the scenario:

  

• All Loopback Router Address are 150.19.X.X/16
•  Configure The Internetwork topology to allow multicast Traffic.
• Configure GETVPN where R3 will be act as KS and R1,R2, and R4 will be act as GM
•  Key distribution must be Use Multicast address 239.19.19.19
• Traffic from Loopback SW1 to SW2 should be encrypted and vice versa
• Any traffic goes to the multicast address 239.4.4.4 must be encrypted

·         Configure The Internetwork topology to allow multicast Traffic.

R1-R2 ! ip multicast-routing ! Interface loopback0  Ip pim sparse-mode ! Interface fa0/0 – 1  Ip pim sparse-mode ! end

R3&R4 ! ip multicast-routing ! Interface loopback0  Ip pim sparse-mode ! Interface fa0/0  Ip pim sparse-mode ! Interface virtual-template 34  Ip pim sparse-mode ! end

SW1 ! ip multicast-routing ! Interface loopback0  Ip pim sparse-mode ! Interface vlan 12  Ip pim sparse-mode ! end

I Used Bootstrap Router (BSR) to distribute the RP information. In this case, SW1 will act as Randevous-Point (RP) and R3 will act as BSR Announcing Router (BSR Candidate). Note that in order to run BSR, we should use PIM version 2, which is default in Cisco IOS.

SW1 ! ip pim rp-candidate Loopback0 ! End R3 ! ip pim bsr-candidate Loopback0 0 ! end

Verification:

Rack19R1#sh ip pim interface Address          Interface                Ver/   Nbr    Query  DR     DR                                           Mode   Count  Intvl  Prior 150.19.1.1       Loopback0                v2/S   0      30     1      150.19.1.1 10.19.123.1      FastEthernet0/0          v2/S   2      30     1      10.19.123.3 10.19.12.1       FastEthernet0/1          v2/S   2      30     1      10.19.12.7 Rack19R1#show ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.19.123.3       FastEthernet0/0          00:39:27/00:01:41 v2    1 / DR S P G 10.19.123.2       FastEthernet0/0          00:39:39/00:01:41 v2    1 / S P G 10.19.12.2        FastEthernet0/1          00:39:37/00:01:34 v2    1 / S P G 10.19.12.7        FastEthernet0/1          00:39:51/00:01:28 v2    1 / DR S G

Rack19R1-R4#show ip pim bsr-router PIMv2 Bootstrap information   BSR address: 150.19.3.3 (?)   Uptime:      00:39:18, BSR Priority: 0, Hash mask length: 0   Expires:     00:01:17 Rack19SW1#sh ip pim bsr-router PIMv2 Bootstrap information   BSR address: 150.19.3.3 (?)   Uptime:      00:39:49, BSR Priority: 0, Hash mask length: 0   Expires:     00:01:47   Candidate RP: 150.19.7.7(Loopback0)     Holdtime 150 seconds     Advertisement interval 60 seconds     Next advertisement in 00:00:12

Let pretend that some user is joining the Multicast group 239.4.4.4 on VLAN 4

R4 ! interface FastEthernet0/0 ip pim sparse-mode  ip igmp join-group 239.4.4.4 ! end

Let see that SW1 will be elected automatically as RP

Rack19R4#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4   RP 150.19.7.7 (?), v2     Info source: 150.19.3.3 (?), via bootstrap, priority 0, holdtime 150          Uptime: 00:45:43, expires: 00:02:24 Rack19R4#sh ip mroute IP Multicast Routing Table <…SNIP…> (*, 239.4.4.4), 00:43:08/00:02:38, RP 150.19.7.7, flags: SJCL   Incoming interface: Virtual-Access1, RPF nbr 10.19.34.3   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 00:43:08/00:02:38 (*, 224.0.1.40), 00:44:36/00:02:27, RP 0.0.0.0, flags: DCL   Incoming interface: Null, RPF nbr 0.0.0.0   Outgoing interface list:     Loopback0, Forward/Sparse, 00:44:34/00:02:27

Rack19R2#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4   RP 150.19.7.7 (?), v2     Info source: 150.19.3.3 (?), via bootstrap, priority 0, holdtime 150          Uptime: 00:46:06, expires: 00:02:03 Rack19R2#sh ip mroute <…SNIP…> (*, 239.4.4.4), 00:43:39/00:03:09, RP 150.19.7.7, flags: S   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.7   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 00:43:39/00:03:09 (*, 224.0.1.40), 00:46:14/00:02:46, RP 0.0.0.0, flags: DCL   Incoming interface: Null, RPF nbr 0.0.0.0   Outgoing interface list:     Loopback0, Forward/Sparse, 00:46:12/00:02:46

• Configure GETVPN where R3 will be act as KS and R1,R2, and R4 will be act as GM
• Key distribution must be Use Multicast address 239.19.19.19
• Traffic from Loopback SW1 to SW2 should be encrypted and vice versa
• Any traffic goes to the multicast address 239.4.4.4 must be encrypted

In order GETVPN use the Multicast address to distribute the Key, we should create an explicit Access-list, where the source is gotta be the KS and destination is the specified multicast address. Since GETVPN using UDP port 848, in This case we’d better use the default UDP port in the Multicast Address. I tried using the other port, but in my previous lab, the traffic is not getting encrypted (Wheather GNS problem or Config problem), since all the GM get the GDOI configuration normally. So the bottom line was, use the UDP default port!!! J

KS Configuration R3 ! ! crypto isakmp policy 1  encryption des  hash md5  authentication pre-share crypto isakmp key CISCO address 150.19.0.0 255.255.0.0 no-xauth ! ! crypto ipsec transform-set TS_DES_MD5 esp-des esp-md5-hmac ! crypto ipsec profile IPSEC_PROFILE  set transform-set TS_DES_MD5 ! ! ip access-list extended ACL_GETVPN_DATA  permit ip 150.19.8.0 0.0.0.255 150.19.7.0 0.0.0.255  permit ip 150.19.7.0 0.0.0.255 150.19.8.0 0.0.0.255  permit ip any host 239.4.4.4 ! ip access-list extended ACL_GETVPN_MCAST  permit udp host 150.19.3.3 eq 848 host 239.19.19.19 eq 848 ! ! crypto gdoi group GETVPN  identity number 29281  server local   rekey address ipv4 ACL_GETVPN_MCAST   rekey lifetime seconds 300   rekey retransmit 10 number 2   rekey authentication mypubkey rsa IOS_CA   registration interface Loopback0   sa ipsec 1    profile IPSEC_PROFILE    match address ipv4 ACL_GETVPN_DATA    replay time window-size 100   address ipv4 150.19.3.3 ! end

In this case I use the rsa label IOS_CA as my crypto rsa key J

GM Configuration R1,R2,R4 ! crypto isakmp policy 1  hash md5  authentication pre-share crypto isakmp key CISCO address 150.19.0.0  255.255.0.0    no-xauth ! crypto gdoi group GETVPN  identity number 29281  server address ipv4 150.19.3.3 ! crypto map CMAP local-address Loopback0 crypto map CMAP 1 gdoi  set group GETVPN ! Interface F0/0 (on R1 & R2)  Crypto map CMAP ! Interface virtual-template 34 (on R4)  Crypto map CMAP ! end

Verification

On KS Rack19R3#show crypto gdoi GROUP INFORMATION     Group Name               : GETVPN (Multicast)     Group Identity           : 29281     Crypto Path              : ipv4     Key Management Path      : ipv4     Group Members            : 3     IPSec SA Direction       : Both     Group Rekey Lifetime     : 300 secs     Group Rekey         Remaining Lifetime   : 281 secs     Rekey Retransmit Period  : 10 secs     Rekey Retransmit Attempts: 2     Group Retransmit         Remaining Lifetime   : 0 secs       IPSec SA Number        : 1       IPSec SA Rekey Lifetime: 3600 secs       Profile Name           : IPSEC_PROFILE       Replay method          : Time Based       Replay Window Size     : 100       SA Rekey          Remaining Lifetime  : 2942 secs       ACL Configured         : access-list ACL_GETVPN_DATA      Group Server list       : Local Rack19R3#show crypto gdoi ks Total group members registered to this box: 3 Key Server Information For Group GETVPN:     Group Name               : GETVPN     Group Identity           : 29281     Group Members            : 3     IPSec SA Direction       : Both     ACL Configured:         access-list ACL_GETVPN_DATA Rack19R3#show crypto gdoi ks rekey Group GETVPN (Multicast)     Number of Rekeys sent               : 48     Number of Rekeys retransmitted      : 48     KEK rekey lifetime (sec)            : 300         Remaining lifetime (sec)        : 231     Retransmit period                   : 10     Number of retransmissions           : 2     IPSec SA 1  lifetime (sec)          : 3600         Remaining lifetime (sec)        : 2892     Number of registrations after rekey : 1     Multicast destination address       : 239.19.19.19 Rack19R3#show crypto gdoi ks members Group Member Information : Number of rekeys sent for group GETVPN : 49 Group Member ID    : 150.19.1.1  GM Version: 1.0.4  Group ID          : 29281  Group Name        : GETVPN  Key Server ID     : 150.19.3.3 Group Member ID    : 150.19.2.2  GM Version: 1.0.4  Group ID          : 29281  Group Name        : GETVPN  Key Server ID     : 150.19.3.3 Group Member ID    : 150.19.4.4  GM Version: 1.0.4  Group ID          : 29281  Group Name        : GETVPN  Key Server ID     : 150.19.3.3

On GM Rack19R1#show crypto gdoi GROUP INFORMATION     Group Name               : GETVPN     Group Identity           : 29281     Crypto Path              : ipv4     Key Management Path      : ipv4     Rekeys received          : 50     IPSec SA Direction       : Both      Group Server list       : 150.19.3.3     Group member             : 150.19.1.1       vrf: None        Version               : 1.0.4        Registration status   : Registered        Registered with       : 150.19.3.3        Re-registers in       : 159 sec        Succeeded registration: 1        Attempted registration: 1        Last rekey from       : 150.19.3.3        Last rekey seq num    : 0        Multicast rekey rcvd  : 50        allowable rekey cipher: any        allowable rekey hash  : any        allowable transformtag: any ESP     Rekeys cumulative        Total received        : 50        After latest register : 50        Rekey Rcvd(hh:mm:ss)  : 00:00:35  ACL Downloaded From KS 150.19.3.3:    access-list   permit ip 150.19.8.0 0.0.0.255 150.19.7.0 0.0.0.255    access-list   permit ip 150.19.7.0 0.0.0.255 150.19.8.0 0.0.0.255    access-list   permit ip any host 239.4.4.4 KEK POLICY:     Rekey Transport Type     : Multicast     Lifetime (secs)          : 263     Encrypt Algorithm        : 3DES     Key Size                 : 192     Sig Hash Algorithm       : HMAC_AUTH_SHA     Sig Key Length (bits)    : 1024 TEK POLICY for the current KS-Policy ACEs Downloaded:   FastEthernet0/0:     IPsec SA:         spi: 0x5A2932B2(1512649394)         transform: esp-des esp-md5-hmac         sa timing:remaining key lifetime (sec): (2764)         Anti-Replay(Time Based) : 100 sec interval Rack19R1#show crypto gdoi gm rekey Group GETVPN (Multicast)     Number of Rekeys received (cumulative)       : 50     Number of Rekeys received after registration : 50     Multicast destination address                : 239.19.19.19 Rack19R1#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst             src             state          conn-id status 150.19.3.3      150.19.1.1      GDOI_IDLE         1001 ACTIVE 239.19.19.19    150.19.3.3      GDOI_REKEY        1053 ACTIVE

We can see that the Multicast routing table containing IP 239.19.19.19, which is being used for GDOI (Group domain of Interpretation) rekey process

Rack19R2#show ip mroute <…SNIP…> (*, 239.19.19.19), 01:09:40/00:02:45, RP 150.19.7.7, flags: SJCL   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.7   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 01:09:40/00:02:45 (150.19.3.3, 239.19.19.19), 01:09:13/00:02:15, flags: PLR   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.1   Outgoing interface list: Null (*, 239.4.4.4), 01:22:21/00:02:49, RP 150.19.7.7, flags: S   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.7   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 01:22:21/00:02:49 (*, 224.0.1.40), 01:24:57/00:02:05, RP 0.0.0.0, flags: DCL   Incoming interface: Null, RPF nbr 0.0.0.0   Outgoing interface list:     Loopback0, Forward/Sparse, 01:24:55/00:02:05

Let us verify the encryption process: I will do the ICMP traffic from

1. 10.19.4.8 --> 150.19.7.7, where we will not see the traffic encrypted

Rack19SW2#ping 150.19.7.7 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.19.7.7, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/76/104 ms

2. 150.19.8.8 --> 150.19.7.7 where we will see the traffic will be encrypted

Rack19SW2#ping 150.19.7.7 sou loop 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.19.7.7, timeout is 2 seconds: Packet sent with a source address of 150.19.8.8 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/133/160 ms

Rack19R4#show crypto ipsec sa interface: Virtual-Template34     Crypto map tag: CMAP, local addr 150.19.4.4    protected vrf: (none)    local  ident (addr/mask/prot/port): (150.19.7.0/255.255.255.0/256/0)    remote ident (addr/mask/prot/port): (150.19.8.0/255.255.255.0/256/0)    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     #pkts compressed: 0, #pkts decompressed: 0     #pkts not compressed: 0, #pkts compr. failed: 0     #pkts not decompressed: 0, #pkts decompress failed: 0     #send errors 0, #recv errors 0

 3. 150.19.2.2 à 239.4.4.4, where we will see the traffic will be encrypted

Rack19SW1#ping 239.4.4.4 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds: Packet sent with a source address of 150.19.7.7 Reply to request 0 from 10.19.4.4, 388 ms Reply to request 0 from 10.19.4.4, 528 ms

Rack19R2#show crypto ipsec sa interface: FastEthernet0/0     Crypto map tag: CMAP, local addr 150.19.2.2   protected vrf: (none) <…SNIP…>    local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)    remote ident (addr/mask/prot/port): (239.4.4.4/255.255.255.255/256/0)    current_peer 0.0.0.0 port 848      PERMIT, flags={}     #pkts encaps: 32, #pkts encrypt: 32, #pkts digest: 32     #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0     #pkts compressed: 0, #pkts decompressed: 0     #pkts not compressed: 0, #pkts compr. failed: 0     #pkts not decompressed: 0, #pkts decompress failed: 0     #send errors 0, #recv errors 0 <…SNIP…>

Summary:

GETVPN is quite powerful, it can use the Multicast to distribute the Key Rotation, which is very usefull when we have a lot of GMs (above 1000 for example). And GETVPN natively can encrypt the both Unicast and Multicast Traffic, this will reduce the CPU overhead for the process, since the Control Plane (Key calculation) process will be handled only by KS, so GM can focus on the Traffic Encryption.

GETVPN can simplify the Full-Mesh VPN Deployment in the Enterprise, with the drawback that this technology is Cisco proprietary , at least at the time of this writing.

I hope this would be Informative and I’d like to thank you for reading \(^0^)/