Group Encrypted Transport VPN is used to encrypt traffic going through unsecured networks. It uses IPSEC to enforce integrity and confidentiality of data.
Deployment consists of a Key Server router (KS) and Group Member routers (GM).
The KS creates, and maintains, and sends policies to GMs. KSs also generate encryption keys:
- Transport Encryption Key (TEK): This key is used by GMs to encrypt data
- Key encryption Key (KEK): This key is used to encrypt the connection between the KS and the GM
Policies provide information regarding what traffic should be encrypted and what encryption algorithms to use.
There is never an actual IPSEC tunnel between KS and GMs, instead GMs simply receive the policy from the KS and encrypt the specific traffic defined the the policy as needed. When traffic enters the GM that matches the policy, it’s encapsulated in ESP and sent out with Source and Destination IPs preserved.
The KS requires RSA keys to be used for the Rekeying process. The KS sends out a new TEK before the original TEK expires (3600 seconds). The Rekey phase is authenticated and secured via ISAKMP SA between the KS and the GM.
The ISAKMP uses Group Domain of Interpretation (GDOI) messages to build an SA and encrypts GM registration.
GDOI uses UDP 848 as opposed to IKEs UDP 500 to establish SAs.
VPLS is a layer 2 service that allows two geographically separate LANs to be interconnected as a single bridged domain over an MPLS network.
VPLS over GRE allows VPLS across an IP network.
VPLS instances must be configred on each PE router.
Laye 2 VPNs are not a focus of the CCIE so there is limited documentation surrounding this technology in the study guide.
Any Transport over MPLS allows the establishment of layer 2 adjacencies between geographically isolated sites.
xconnect is the command used to create a bridged connection with the specified destination. The command is broken down with the xconnect keyword followed by the peering router address and the unique virtual circuit ID (VCID). This VCID must match on both ends of the connection. The encapsulation can be L2TPv2, L2TPv3, or MPLS.
Always remember there must always be a unique address on each router in order for this to work.
Layer 2 pseudowires have two segments, Segment 1 for the customer facing port and segment 2 for the core configuration.
L2VPNs featured an expansion with the Layer 2 Tunneling Protocol version 3 feature. L2TPv3 provides enhancements to L2TP to tunnel any L2Payload over L2tP by defining how L2TP tunnels L2 payloads over an IP core by using L2VPNs.
L2TPv3 uses protocol ID 115.
In order for L2TPv3 to work you must have CEF enabled and that the loopback interface has a valid IP address that is reachable from remote PE devices at the other end of an L2TPv3 control channel
This mode references 802.1Q tags across L2VPN pseudowires. These tags are only significant to local and endpoint devices. Service providers must preserve the original VLAN Tag IDs passed to them from the local endpoint to the remote endpoint.
Tagged mode pseudowires have a type 0x0004, and every frame sent across a PW must have a unique VLAN for each customer. this is called the service delimiting VLAN tag.
If a frame is received from the attachment circuit and its missing a service-delimiting VLAN the PE must prepend the frame with a dummy VLAN tag before sending the frame on the PW.
In Raw mode pseudowires, the service delimiting tag has no significance. This mode has pseudowire type 0x0005, Raw mode dictates that any service delimiting tags must be removed before being transported across the L2VPN PW.
This service offered by ISPs allows two remote locations to be logically connected to each other across a layer 2 connection over a carriers network. This is typically used for customers to manage their own network as L2VPN is the simplest solution where a client wants to manage their own protocols, IP management, QoS, everything.
L2VPN solutions are referred to as pseudowire connections.
Ethernet Pseudowires allow ethernet frames to traverse MPLS clouds. the service provider extends layer 2 adjacency between sites, allowing spanning tree to run across links. This is referred to as Emulated Sevice.
Ethernet pseudowires has two modes:
Intra-Site automatic Tunnel addressing Protocol (ISATAP) like 6to4 treats underlying IPv4 networks as NBMA cloud. Making ISATAP tunnels support point to multipoint operation natively and determines destination on a per packet basis.
ISATAP Addressing uses the following format
[64 bit link local or global unicast pefix]:0000:5EFE:[IPv4 address of ISATAP link]
Configuration for the most part is the same except for a different tunnel mode
tunnel-mode ipv6ip isatap
IPv6 address must be derived from EUI-64 addressing in a tunnel interface, the EUI-54 address of a tunnel interface has the lower 32bit address based off the tunnel interfaces source IPv4 address
Router Advertisements are needed for neighbor auto discovery, however when tunnels are enabled this DISABLES Router advertisements. Enable RAs using the following command:
no ipv6 nd suppress-ra
6to4 tunnels are inherently multipoint by nature, these tunnels treat IPv4 networks as NBMA cloud. In 6to4 tunnels, the tunnel itself operates on a per packet basis to encapsulate traffic to the correct destination. These tunnels determine the appropriate destination address by combining the IPv6 prefix with the globally unique destination 6to4 border routers IPv4 address, beginning with 2002::/16 prefix
The method leaves 16 bits in the 64bit prefix for numbering networks at each site.
IOS supports only one auto 6to4 tunnel on a given router. Configuratoin is exactly the same as before except for the tunnel mode type:
tunnel mode ipv6ip 6to4
Tunnel destination is also not explicitly configured because of the automatic nature of the per packet destination method this tunnel type uses.
Routing over this tunnel type is also required, this is typically done using static routing.
GRE tunnels encapsulate passenger protocol traffic, With IPv6 as the passenger protocol this is usually installed at edge routers connecting two remote IPv6 sites across an IPv4 backbone. The configuration is identical to he manual tunneling except the difference in the tunnel mode selected.
tunnel mode gre ipv6
This kind of tunnel uses IPv4 compatible IPv6 addresses for tunnel interfaces. These addresses are taken from /96 address comprised of the first 96 bits containing all zeros and the last 32 bits are derived from the IPv4 address.
These addresses are written as:
0:0:0:0:0:0:A.B.C.D or ::A.B.C.D
This is not a scalable solution and this method of addressing is not supported globally, Cisco recommends using ISATAP tunnels instead when considering this kind of solution..