GET VPN, it is all about group.


GET VPN uses a group security paradigm comparing to the traditional point-to-point security paradigm like DMVPN, GRE IPSec or SSL. Do not confuse with any-to-any mesh which is the result of n(n-1)/2 point-to-point security associations between n peers.

We are talking about group security association (SA), group states and group keys.

Because each group member doesn’t know in advance about other group members, a central entity named key server (KS) need to manage GET VPN control plane: group member registration, distribute group keys and do the rekeys (updating security policy and group keys).

Once a group member has registered with the KS to a group, it can take care of the data plane encrypted communication with any of the other group members using the received group key and group security policy.

GET VPN doesn’t create the VPN perimeter (like Frame Relay for example), all group members and the key server are supposed to be already in the same VPN.

This lab is not supposed to be a comprehensive GET-VPN reference. Because it is all about a stories and process dynamics, I opted for a more visual approach: less words, more pictures.

I included a table summarizing the key characteristics of GET-VPN comparing with traditional IPSec, followed by a step-by-step animation of the main processes of GET-VPN.

Only then, I provide some configurations of the core MPLS-VPN and GET-VPN key server and group member.

And finally the offline lab with a myriad of useful commands collected during a running session.

By rushing to the CLI, you can easily drown yourself in a cup of water 🙂 Better take the time to understand the overall process, then configuration and troubleshooting will be straightforward and more instructive.

Outline:

  • Comparison of GETVPN vs traditional IPSec.
  • Summary of the main concepts
  • Step-by-step GETVPN process
  • Lab details
    • MPLS-VPN configuration
      • Core
      • PE_CE
    • GET VPN configuration
      • Basic Group member template
      • Basic key server
  • Offline lab
  • Troubleshooting

Comparison table (IPSec <> GET vpn)

IPSec Crypto GET Crypto
Main concept Per link point-to-point security paradigm: each pair of devices establishes a separate security association.(figure3) Group-based security paradigm: allows a set of network entities to connect through a single group security association.
Encapsulation Requires the establishment of tunnel to secure the traffic between encrypting gateways.- a new header is added to the packet (figure4).- Limited QoS preservation (only ToS). Tuneless: does not use tunnels and preserves the original src/dst IP in the header of the encrypted packet for optimal routing (figure6).- Preserve same established routing path.- Preserve entire QoS parameter set.
Multicast – Traditional IPSec encapsulate multicast into encrypted PTP unicast GRE tunnels.- Alternatively, inefficient multicast replication at the HUB using DMVPN with many multicast deployment restrictions (RP, MA and multicast source location at the HUB). GET VPN is particularly suited for multicast traffic encryption with native support. The WAN multicast infrastructure is used to transport encrypted GET-VPN multicast traffic.
Infrastructure IPSec creates Overlay VPN and secures it over the Internet. • Relies on MPLS/VPLS Any-to-Any VPN.• Direct Flows between all CE.• Leverages Existing VPNs.- GET VPN suited for enterprises running over MPLS private networks.- GET-VPN ONLY secure an already established VPN (MPLS-VPN), it doesn’t create it
Management – Per-link security management: Each pair holds a security association for each other.- Resource consumption.- Alternative centralized HUB-based management with DMVPN though heterogeneous protocol suite (mGRE, NHRP)- Less scalable. – Full mesh direct communications between sites.Same group members hold a single security association; don’t care about others on the group.- Relies on centralized membership management through key servers :A centralized entity (Key Server manage the control plane) and not involved in the data plane communication.Data plane communications don’t require transport through a hub HUB entity.- Low latency/jitter.

– More scalable.

Security Perimeter Per-link All Sites within the same group.
Routing Two routing levels(figure5a):Core routing+Overlay routing between encrypting gateways Single end-to-end routing level with MPLS-VPN as the underlying VPN infrastructure(figure6a).
Traditional IPSec PTP SAs between GMs

Figure3- Traditional IPSec PTP SAs between GMs

Figure4- Traditional IPSec PTP Packet

Figure4- Traditional IPSec PTP Packet

 

Figure5a-Traditional IPSec routing overlay

Figure5a-Traditional IPSec routing overlay

 

Figure6- Get-VPN IPSec PTP Packet + TEK

Figure6- Get-VPN IPSec PTP Packet + TEK

 

Figure6a- GETVPN end-to-end routing

Figure6a- GETVPN end-to-end routing

 

 Summary of the main concepts

The key server manages the control operations (group member registration and rekey and policy distribution) on a different plane, initially, under the protection of IKE, after that, protected by a common key (KEK) (figure7/8).

Rekey process can be done using unicast (default) or multicast.

Any-to-any GM communications are performed on a separate data plane using the received TEK (Traffic Encryption Key) (figure9).

COOP (Co-operative key server protocol)

  • A Key Server redundancy feature allowing key server communication to synchronize the keying information.

GDOI protocol (Group Domain of Interpretation)

  • Used for policy & key deployment with group members.

Make sure to differentiate between registration vs rekey and between authentication vs authorization processes.

A-Registration process:

1- There is two types of KS-GM authentications):

  • Shared key (deployed on the lab): a simple secret key shared (hopefully out-of-band) by the KS and all GMs (or per-pair).
  • RSA (CA-based authentication): uses asymmetric encryption with public/private key pair and requires PKI infrastructure:
    • Enrollment phase:
      • Client (GM) gets CA certificate (CA public key signed with CA private key)
      • Client enrollment with CA
        • Client sends its own certificate (client public key signed with client private key)
        • CA signs the client certificate with its own (CA) public key and sends it to the client.
    • Peer-to-peer (GM-to-KS) authentication:
      • Peers exchanges and verify each other signatures using CA public key.

2- Authorization (during registration):

  • KS verifies the group id number of the GM: If this id number is a valid and the GM has provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA policy and the Keys to the group member.

B-Rekey process (after registration): uses asymmetric encryption with public/private key pair:

  • The Primary KS uses the private & public keys (asymmetric) generated before the registration and export them to other secondary KSs.
  • Primary KS generates Group control / data plane keys, TEK and KEK (symmetric keys)
  • The KS signs TEK/KEK + policy with its own private key and sends them to GMs(figure7/8/9)
  • The KS distributes public key to all GMs.
  • GMs check the rekeys with the received KS public key

 

Figure7- Control plane: GM registration

Figure7- Control plane: GM registration

Figure8- Control plane: rekey using KEK key

Figure8- Control plane: rekey using KEK key

 

Figure9- GM data plane communications using TEK key

Figure9- GM data plane communications using TEK key

 

 

Step-by-step GET-VPN process

Lab details

Here is the lab topology, pretty straight forward, three group members and one key server with MPLS-VPN as the underlying VPN infrastructure.

 

Figure1- High-level lab topology

Figure1- High-level lab topology

Figure2- Low-level lab topology

Figure2- Low-level lab topology

 

GET VPN:

  • Customer equipments (CE) R9, R10 and R12 play the role of GETVPN group members (GM),
  • R11 plays the role of the key server.

MPLS_VPN:

  • R2, R3 and R5 are the MPLS-VPN PEs (Provider Edge equipment)

MPLS-VPN configuration:

Make sure the underlying MPLS-VPN topology works fine and all connectivity are successful before touching GET VPN.

For the sake of simplicity, a single MPLS core router (label switching router) R4 is used and static routing between CE_PE.

 

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

 

MPLS-VPN basic configuration with PE-CE static routing

  • R4 the MPLS core router (LSR) is configured as BGP route reflector.
  • Make sure PE equipments (wan interfaces and loopback rid’s) are reachable though MPLS core OSPF.
  • Enable MPLS on the interfaces facing PE’s.
  • Each PE (R2, R3 and R5) has similar configuration and a template can be used to scale client numbers.

Because this lab is not focused on MPLS-VPN, a simple PE-CE static routing is deployed. Each client has its interface and static route in the appropriate VRF. Generally multiple clients (VRFs) separately coexist in a single PE and the core transport is done through vpnv4 to and from other PE’s (figure2a)

 

Figure2a- MPLS-VPN PE Virtual Router Forwarding

Figure2a- MPLS-VPN PE Virtual Router Forwarding

With PE-CE static routing, only one-side redistribution is done, from static to vpnv4 address family.

You will find all details in the offline lab.

R4 (MPLS LSR router)

interface Loopback0ip address 10.0.0.4 255.255.255.255ip ospf 2345 area 0!

interface FastEthernet0/0

ip address 192.168.45.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

interface FastEthernet0/1

ip address 192.168.24.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

interface FastEthernet1/0

ip address 192.168.34.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

router ospf 2345

!

router bgp 2345

no synchronization

bgp router-id 4.4.4.4

network 192.168.24.0

network 192.168.34.0

network 192.168.45.0

neighbor 10.0.0.2 remote-as 2345

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 remote-as 2345

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 remote-as 2345

neighbor 10.0.0.5 route-reflector-client

no auto-summary

!

address-family vpnv4

neighbor 10.0.0.2 activate

neighbor 10.0.0.2 send-community extended

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 activate

neighbor 10.0.0.3 send-community extended

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 activate

neighbor 10.0.0.5 send-community extended

neighbor 10.0.0.5 route-reflector-client

exit-address-family

R4#sh ip bgp summBGP router identifier 4.4.4.4, local AS number 2345…10.0.0.2 4 2345 134 137 4 0 0 02:09:53 0

10.0.0.3 4 2345 134 137 4 0 0 02:09:43 0

10.0.0.5 4 2345 136 137 4 0 0 02:09:52 0

R4#

GET-VPN configuration:

Key server:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2!crypto isakmp key cisco address 192.168.103.10

crypto isakmp key cisco address 192.168.29.9

crypto isakmp key cisco address 192.168.125.12

!

crypto ipsec transform-set transform128 esp-aes esp-sha-hmac

!

crypto ipsec profile profile1

set security-association lifetime seconds 7200

set transform-set transform128

!

crypto gdoi group gdoi-group1

identity number 91011

server local

rekey algorithm aes 128

rekey retransmit 10 number 2

rekey authentication mypubkey rsa rekey-rsa

rekey transport unicast

sa ipsec 1

profile profile1

match address ipv4 getvpn-acl

address ipv4 192.168.115.11

!

interface FastEthernet0/0

ip address 192.168.115.11 255.255.255.0

!

ip access-list extended getvpn-acl

deny icmp any any

deny udp any eq 848 any eq 848

deny tcp any any eq 22

deny tcp any eq 22 any

deny tcp any any eq tacacs

deny tcp any eq tacacs any

deny tcp any any eq bgp

deny tcp any eq bgp any

deny ospf any any

deny eigrp any any

deny udp any any eq ntp

deny udp any eq ntp any

deny udp any any eq snmp

deny udp any eq snmp any

deny udp any any eq snmptrap

deny udp any eq snmptrap any

deny udp any any eq syslog

deny udp any eq syslog any

permit ip any any

You can recognize usual IPSec components: crypto policy, shared keys, transform-sets wrapped in an ipsec profile, followed by GETVPN GDOI group policy ( ipsec profile and group policy (group-id, symm. encr. Algorithm, asymmetric keys to use during rekey authentication and getvpn acl)

The GETVPN ACL defines what will not be encrypted; consider your own topology needs:

  • Exclude already encrypted traffic (https, ssh, etc.)
  • Exclude PE-CE routing protocols.
  • Exclude GETVPN control plane protocols( gdoi udp 848, tacacs, radius, etc.)
  • Exclude Management/monitoring protocols (snmp. syslog, device remote access, icmp, etc.)

Group member template:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2crypto isakmp key cisco address 192.168.115.11!

crypto gdoi group gdoi-group1

identity number 91011

server address ipv4 192.168.115.11

!

crypto map map-group1 10 gdoi

set group gdoi-group1

!

interface FastEthernet0/0

crypto map map-group1

All control plane parameters are controlled by the KS, GMs are dumb devices. All they have to know is how to initiate IKE phase1 for preshared or RSA authentication with the KSs to register and get the keys, which groups they want to join, to which KS they will talk (if many configured) and finally, the get crypto-map assigned to the outbound interface.

Troubleshooting:

When practicing or during tenacious data plane issues, a good idea is to use ESP-NULL, the null encryption, where the encryption process is engaged, but packets are not encrypted.

This will make much easier the packet content inspection and marking between GMs.

To facilitate the deployment and the troubleshooting, think about the topology in terms of separate technology sub-domains; make sure everything works fine before moving to the next sub-domain.

  • Layer2 MPLS
  • MPLS-VPN
  • Core routing
  • PE-CE routing
  • Core SSM multicast (if not unicast rekey)
  • CA infrastructure (if you are not using shared keys to authenticate GMs to the KS)
Possible issues Possible causes
key servers doesn’t exchange all announcements Bad buffer – default buffer is not enough for large nbr of gm
Reassembly timed out Some announcement fragments are dropped or lostICMP (packet too big) denied in the pathNo fragmentation because df bit setPresence of MTU bottlenecks, multipaths, firewalls.Not tuned tcp mss “ip tcp adjust-mss”
ike failure- failed negotiation Preshared key mismatchIKE parameters mismatchTransport issues between GMs and KSs
Nothing works just after GM registration. GETVPN acl policy cause routing traffic encryption: traffic not symmetrically excluded
KS not synchronizing Check KS-KS transport: avoid making KS-KS communications dependent on GET-VPN successful transport.Keys not exported or not imported
Rekey not delivered Issue with multicast infrastructure.Issue with mVPN service.

For more detailed GETVPN troubleshooting, I urge you to watch the excellent CiscoLive session by Wen Zhang https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

Offline lab:

References:

http://www.cisco.com/c/en/us/products/security/group-encrypted-transport-vpn/index.html

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

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Aug2013/CVD-GETVPNDesignGuide-AUG13.pdf

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=7907&backBtn=true

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t11/htgetvpn.html

http://tools.ietf.org/html/rfc3547

http://tools.ietf.org/rfc/rfc4534.txt

6VPE (IPv6 VPN Provider Edge Router)


6VPE is an easy solution to connect IPv6 customers through an existing stable IPv4 MPLS infrastructure.

All clients have to do is to connect to a Provider Edge (configured with IPv6 VRFs) using IPv6.

6VPE MPLS

I hope this post will provide you with a brief and concise explanation about 6VPE.

Let’s start with a short animation resuming the 6VPE forwarding process:

Following the main configuration steps.

Lab topology

6VPE lab topology

Core IGP

For the sake of backbone stability, we need to configure the Core IGP (OSPF) to use loopback interfaces (always UP/UP) on all P and PE routers. {2.2.2.2, 3.3.3.3, 4.4.4.4}

22.2.2.2, 33.3.3.3, 44.4.4.4 loopback interfaces are used for MPLS router-id and need to be advertised through Core OSPF.

22.22.2.2, 44.4.4.4 loopback interfaces are used for MP-iBGP neighbor relationships and need to be advertised through Core OSPF.

By default OSPF will not advertise a 32-bit loopback mask. We need to configure the interface to be an OSPF network type point-to-point. For more details refer to this post…

6VPE2

interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
!
interface Loopback2
ip address 44.4.4.4 255.255.255.0
!
!
interface Loopback3
ip address 44.44.4.4 255.255.255.255
ip ospf network point-to-point
!
router ospf 234
router-id 4.4.4.4
network 44.4.4.4 0.0.0.0 area 0
network 44.44.4.4 0.0.0.0 area 0
network 192.0.0.0 0.255.255.255 area 0

Core

interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
router ospf 234
router-id 3.3.3.3
network 33.3.3.3 0.0.0.0 area 0
network 192.0.0.0 0.255.255.255 area 0

6VPE1

interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
!
interface Loopback2
ip address 22.2.2.2 255.255.255.255
!
!
interface Loopback3
ip address 22.22.2.2 255.255.255.255
ip ospf network point-to-point
!
mpls ldp router-id Loopback2 force
!
router ospf 234
router-id 2.2.2.2
network 22.2.2.2 0.0.0.0 area 0
network 22.22.2.2 0.0.0.0 area 0
network 192.0.0.0 0.255.255.255 area 0

MPLS-LDP

MPLS-LDP establishes back-to-back sessions for label exchange in the control plane and label swapping in the forwarding plane.

Just configure MPLS LDP the appropriate interfaces and force a loopback interface for MPLS LDP router-id.

Core

interface FastEthernet0/0
ip address 192.168.23.3 255.255.255.0
mpls label protocol ldp
mpls ip
!
interface FastEthernet0/1
ip address 192.168.34.3 255.255.255.0
mpls label protocol ldp
mpls ip
!
mpls ldp router-id Loopback2 force

6VPE1

interface FastEthernet1/0
ip address 192.168.23.2 255.255.255.0
mpls label protocol ldp
mpls ip
!
mpls ldp router-id Loopback2 force

6VPE2

interface FastEthernet1/0
ip address 192.168.34.4 255.255.255.0
mpls label protocol ldp
mpls ip
!
mpls ldp router-id Loopback2 force

Provider Edge VRFs

Make sure IPv6 routing and IPv6 CEF are enabled.

6VPE1

vrf definition west-c1
rd 100:100
!
address-family ipv6
route-target export 100:100
route-target import 100:100
exit-address-family
interface FastEthernet0/0
vrf forwarding west-c1
ipv6 address FE80::12:2 link-local
ipv6 address 2001:DB8:12::2/64
router bgp 65234
no synchronization
bgp router-id 22.2.2.2
bgp log-neighbor-changes
!
address-family ipv6 vrf west-c1
redistribute connected
no synchronization
neighbor 2001:DB8:12::1 remote-as 65010
neighbor 2001:DB8:12::1 activate
exit-address-family

West6

router bgp 65010
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 2001:DB8:12::2 remote-as 65234
!
address-family ipv6
neighbor 2001:DB8:12::2 activate
network 2001:DB8:10::/64
network 2001:DB8:12::/64
exit-address-family

6VPE2

vrf definition east-c1
rd 100:100
!
address-family ipv6
route-target export 100:100
route-target import 100:100
exit-address-family
interface FastEthernet0/0
vrf forwarding east-c1
ipv6 address FE80::45:4 link-local
ipv6 address 2001:DB8:45::4/64
router bgp 65234
no synchronization
bgp router-id 44.4.4.4
bgp log-neighbor-changes
!
address-family ipv6 vrf east-c1
redistribute connected
no synchronization
neighbor 2001:DB8:45::5 remote-as 65050
neighbor 2001:DB8:45::5 activate
exit-address-family

Note: With BGP used as customer protocol redistribution is not needed between PE-CE routing protocol (BGP) and MP-BGP

East6

router bgp 65050
bgp router-id 5.5.5.5
bgp log-neighbor-changes
neighbor 2001:DB8:45::4 remote-as 65234
!
address-family ipv6
neighbor 2001:DB8:45::4 activate
network 2001:DB8:45::/64
network 2001:DB8:50::/64
exit-address-family

Provider Edge-to-Provider Edge VPNv6

To understand the difference between PE-PE and PE-CE interactions, think about the difference between a routing protocol and a routed protocol:

  • BGP, OSPF, EIGRP, RIP are routing protocols.
  • IPv4, IPv6, IPX, AppleTalk are routed protocol.

So routing protocols exchange routed protocol information. In our particular case:

  • PE-CE routing protocol is BGP and PE-CE routed protocol is IPv6.
  • PE-PE routing protocol is MP-BGP and PE-PE routed protocol is vpnv6.
  • Core routing protocol is OSPF and the routed protocol is IPv4.

Vpnv4 = RD + VRF IPv4 prefix

Vpnv6 = RD + VRF IPv6 prefix

RD (Route Distinguisher) uniquely identifies the VRF on the PE and allows having multiple customer VPNs with overlapping address schemas.

RT is a BGP extended community attribute (need to be enabled) used to control the installation of exchanged routes between PEs into the correct VRF.

PE-PE (MP-BGP) updates containing MP_BGP_NLRI information:

vpnv4 + (BGP attributes+ RT extended attribute) + Label

VPNv6 route exchange (using MP-BGP)

MPLS network autonomous system 65234 transits traffic between customer autonomous systems 65010 and 65040.

In our case all MPLS routers (P and PE) belong to the same AS. Therefore we need to configure next-hop-self on each PE; otherwise customer prefixes will be visible in BGP table with unreachable next-hops.

Another solution is to enable MPLS IP on interfaces facing clients to include them in MPLS updates, then don’t forget to filter LDP(UDP 646),TDP(TCP 711) traffic with the clients .

6VPE1

router bgp 65234
no synchronization
bgp router-id 22.2.2.2
neighbor 44.44.4.4 remote-as 65234
neighbor 44.44.4.4 update-source Loopback3
neighbor 44.44.4.4 next-hop-self
no auto-summary

The address-family vpnv4 is used to exchange customer IPv4 prefixes between PEs (through IPv4 core)

The address-family vpnv6 is used to exchange customer IPv6 prefixes between PEs (through IPv4 core)

router bgp 65234
address-family vpnv4
neighbor 44.44.4.4 activate
neighbor 44.44.4.4 send-community extended
exit-address-family
!
address-family vpnv6
neighbor 44.44.4.4 activate
neighbor 44.44.4.4 send-community extended
exit-address-family

6VPE2

router bgp 65234
no synchronization
bgp router-id 44.4.4.4
neighbor 22.22.2.2 remote-as 65234
neighbor 22.22.2.2 update-source Loopback3
neighbor 22.22.2.2 next-hop-self
no auto-summary
router bgp 65234
address-family vpnv4
neighbor 22.22.2.2 activate
neighbor 22.22.2.2 send-community extended
exit-address-family
!
address-family vpnv6
neighbor 22.22.2.2 activate
neighbor 22.22.2.2 send-community extended
exit-address-family

And a small QUIZ to check the very basic

The offline lab provides you with more information about the network behavior and its states in different test cases.

An extensive range of commands is provided.

I hope you will find it useful. Suggestions and critics are welcome.

IPv6 BGP synchronization


If you have been dealing with BGP under IOS < 12.0, you know something about BGP synchronization.

This post is driven by three reasons…nostalgia is not one of them : )

  1. BGP synchronization illustrates the difference of BGP with the traditional concept of interior routing protocols like OSPF, RIP or EIGRP.
  2. With ever-growing transition to IPv6, I wanted to test the concept of synchronization with IPv6.
  3. You need to work out your brain muscles and be ready to deal with anything in the CCIE exam where your problem-solving skills will be tested more than your knowledge of best practices.

So let’s brush up our knowledge of the concept with a brief definition of BGP:

BGP is used to advertise NLRI (Network Layer reachability information) between ASs (Autonomous Systems) and it relies on TCP (179) for reliability of the communications. BGP is an attribute-based path-vector protocol.

BGP synchronization states that, if your autonomous system passes traffic from another AS to a third AS (transit), eBGP speaker should not advertise a route before all the routers in your AS have learned about the NLRI via IGP. So BGP will wait until IGP has propagated the route within the AS.

If not done properly, the transit AS will turn into a route black hole.

Here is a small animation illustrating the concept:

Animation

The solution is mutual redistribution of routes between BGP and the IGP.

Nowadays, BGP is running on all routers in autonomous system transit paths, so synchronization is disabled by default.

This allows you to carry fewer routes in your IGP and allow BGP to converge more quickly.

IPv6 configuration

Topology

Router R1:

Redistribution from OSPF TO BGP

router bgp 65012
address-family ipv6 unicast
 redistribute ospf 125
!
route-map RM6_OSPF_TO_BGP match external 2
route-map RM6_OSPF_TO_BGP
permit 10 match ipv6 address ACL6_OSPF_TO_BGP
!
ipv6 access-list ACL6_OSPF_TO_BGP
permit ipv6 2001:db8:209::/64 any log
permit ipv6 2001:db8:23::/64 any log

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ip address ACL6_BGP_TO_OSPF
!
ip access-list standard ACL6_BGP_TO_OSPF
permit ipv6 2001:db8:14::/64 any log
!
ipv6 router ospf 125
redistribute bgp 65012 subnets route-map RM6_BGP_TO_OSPF

Redistribution from BGP to OSPF

R1# sh ipv6 route
IPv6 Routing Table - 8 entries
…
C   2001:DB8:14::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:14::1/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::1/128 [0/0]
via ::, FastEthernet0/0
O   2001:DB8:25::/64 [110/20]
via FE80::15:5, FastEthernet0/0
B   2001:DB8:40::/64 [20/0]
via FE80::14:4, FastEthernet0/1
OE2 2001:DB8:209::/64 [110/1] via FE80::15:5, FastEthernet0/0
L FF00::/8 [0/0] via ::, Null0 
R1#

R2:

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ipv6 address ACL6_BGP_TO_OSPF
!
ipv6 access-list  ACL6_BGP_TO_OSPF
permit 2001:db8:209::/64 any log
permit 2001:db8:23::/64 any log
!
ipv6 router ospf 125
redistribute bgp 65012 route-map RM6_BGP_TO_OSPF

Redistribution from OSPF to BGP

router bgp 65012
address-family ipv6 unicast
redistribute ospf 125 route-map RM6_OSPF_TO_BGP match external 2
route-map RM6_OSPF_TO_BGP permit 10

match ipv6 address ACL6_OSPF_TO_BGP 

!

ipv6 access-list ACL6_OSPF_TO_BGP permit 2001:db8:14::/64 any log

The presence of prefix 2001:DB8:40::/64 originated in AS 65040 (iBGP administrative distance = 200) in the IGP table (OSPFv3 administrative distance =110) means that the core IGP has synchronized the prefix.

R2#sh bgp ipv6 unicast  2001:DB8:40::/64
BGP routing table entry for 2001:DB8:40::/64, version 4
Paths: (2 available, best #1, table Global-IPv6-Table)
Advertised to update-groups:
1    2
Local
:: from 0.0.0.0 (2.2.2.23)
Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced, best
65040
2001:DB8:15::1 (metric 20) from 2001:DB8:15::1 (1.1.1.14)
Origin IGP, metric 0, localpref 100, valid, internal,
synchronized
R2#



R2# sh ipv6 route
IPv6 Routing Table - 8 entries
…
O   2001:DB8:15::/64 [110/20]
via FE80::25:5, FastEthernet0/0
C   2001:DB8:23::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:23::2/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:25::2/128 [0/0]
via ::, FastEthernet0/0
OE2 2001:DB8:40::/64 [110/1]
via FE80::25:5, FastEthernet0/0

B 2001:DB8:209::/64 [20/0]

via FE80::23:3, FastEthernet0/1

L FF00::/8 [0/0]

via ::, Null0

R2#

 

From R5 core IGP router you can notice that OSPFv3 is synchronized with transit route prefixes from AS 64030 and AS 64040.

R5:

R5#sh ipv6 route
IPv6 Routing Table - 7 entries
…
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::5/128 [0/0]
via ::, FastEthernet0/0
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:25::5/128 [0/0]
via ::, FastEthernet0/1
OE2 2001:DB8:40::/64 [110/1] via FE80::15:1, FastEthernet0/0 OE2 2001:DB8:209::/64 [110/1] via FE80::25:2, FastEthernet0/1
L FF00::/8 [0/0] via ::, Null0 
R5#

Offline lab

With the offline lab you will have an idea about the network behavior its states in different test cases.

An extensive range of commands is provided. Both IPv6 and IPv4 BGP synchronization are configured in the offline lab.

I hope you will find it useful. Suggestions and critics are welcome.

BGP Backdoor


In this post I would like to share with you my experience with BGP backdoors along with some interesting observations related to the configuration.

Picture 1: lab topology

Our lab topology (picture1) illustrates two client autonomous systems connected to a backbone through eBGP (external).

The backdoor link will be the direct connection between AS 64030 and AS 64023

Backdoors can be motivated by some business needs like merging, acquisition, temporary collaboration between companies or technical needs like backup for example.

Due to the transient nature of these links they are routed using an internal routing protocol, in our case it is EIGRP.

Recall notes:

To understand the issue that lurks behind backdoors we need to understand some routing concepts.

BGP is a routing protocol used to route between Autonomous Systems. So BGP is not intended to ensure prefix connectivity, this is the role of IGP (internal routing protocols like OSPF, EIGRP or RIP).

In the case the same prefix is advertised through multiple routing protocols an election will take place to choose the best protocol.

Here where Administrative Distances are called into play to set a priority or preference for each protocol. The higher the Administrative Distance the less preferable is the protocol.

unreachable => 255Internal BGP (iBGP) => 200External EIGRP => 170

RIP => 120

OSPF => 110

Internal EIGRP => 90

External BGP (eBGP) = 20

Summary EIGRP => 5

Static route => 1

Directly connected => 0

The key concept behind that particular distribution of AD is that there is a big difference between routing internal prefixes inside a single domain and routing external prefixes (between different routing domain)

The same concept is valid for a single protocol (or should be).

We know that a prefix announced internally is more preferable that the same prefix coming from redistribution.

This is made easy in EIGRP by having different Administrative Distances, partially in OSPF by having preference for internal then inter-area then inter-domain, but needs to be done manually for RIP.

For example BGP understand that it is not the most qualified to talk about internal connectivity, that’s why iBGP prefixes have an AD of 200 (which is worse than any other IGP)

In the same time the Administrative Distance of external BGP = 20, better than any other IGP because BGP is the king, the champion of inter Autonomous system routing.

And for the same reasons OSPF do NOT redistribute by default external type1/type2 prefixes to BGP and by default BGP redistribute ONLY eBGP (external BGP) prefixes to other IGP.

In our case the border routers R2 and R3 will receive prefixes from External BGP (eBGP) = 20 and Internal EIGRP => 90

So if the prefixes 30 are advertised through both protocols, eBGP will be selected to be installed in the RIB.

Picture2: prefix installation in RIB between BGP and EIGRP

Picture 3: prefixes 30 at the Border router R2:

So far everything works according to the previously mentioned concepts, and namely that’s the issue.

Whatever the reason behind this backdoor link the goal is to make the traffic for prefixes 30 take the direct back-to-back connection between AS 64030 and 64023.

So what we need to do is to create an exception to the rule:

Theoretically there are 2 solutions:

A – Manually
    1- Making the originator router R3 not advertising backdoor prefixes
    2- Play with AD at R2 to make backdoor more preferable. This NOT recommended except when you are asked to do so (strict routing policies or CCIE exam P-:))

B- Using IOS BGP backdoor feature.

Looks like distinct solutions? Let’s see!

Enough of concepts, let’s go to the lab for more details.

Configuration:

Backdoor command: network <X.X.X.X> mask <Y.Y.Y.Y> backdoor

That’s all!

Let’s begin by applying the command on the border router R3 for prefixes 30

R3(config)#router bgp 64023
R3(config-router)#net 30.0.0.0 mask 255.255.255.0 backdoor
R3(config-router)#net 30.0.1.0 mask 255.255.255.0 backdoor

R3(config-router)#net 30.0.2.0 mask 255.255.255.0 backdoor

R3(config-router)#net 30.0.3.0 mask 255.255.255.0 backdoor

And I will trigger an on-demand outbound advertisement using soft reset

clear ip bgp 4.4.4.4 soft out
R3#
*Mar 1 22:46:20.954: BGP(0): 4.4.4.4 send UPDATE (format) 30.0.2.0/24, next 3.3.3.3, metric 0, path Local
*Mar 1 22:46:20.962: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 30.0.1.0/24, next 3.3.3.3, metric 0, path Local

*Mar 1 22:46:20.966: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 30.0.0.0/24, next 3.3.3.3, metric 0, path Local

*Mar 1 22:46:21.070: BGP(0): updgrp 1 – 4.4.4.4 updates replicated for neighbors:

R3#

So R3 has advertised backdoor prefixes through eBGP…

We can verify this on R2:

R2 (config-router)#do sh ip route

30.0.0.0/24 is subnetted, 3 subnets

B 30.0.2.0 [20/0] via 1.1.1.1, 00:00:31

B 30.0.0.0 [20/0] via 1.1.1.1, 00:00:31

B 30.0.1.0 [20/0] via 1.1.1.1, 00:00:31

R2(config-router)#

That’s not what Cisco states in the documentation??!?!?!

http://www.cisco.com/en/US/docs/ios/iproute_bgp/configuration/guide/irg_basic_net_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1117226

Interestingly enough, only if I reboot R3 the router will not advertise these prefixes and R2 will receive only EIGRP prefixes and the issue is resolved. (Solution A-1)

(The following RIB and BGP tables are the result of configuring backdoor on R3 and rebooting it)

R2#sh ip bgp
BGP table version is 10, local router ID is 20.0.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 1.1.1.1 0 0 64014 i

*> 10.0.1.0/24 1.1.1.1 0 0 64014 i

*> 10.0.2.0/24 1.1.1.1 0 0 64014 i

*> 20.0.0.0/24 0.0.0.0 0 32768 i

*> 20.0.1.0/24 0.0.0.0 0 32768 i

*> 20.0.2.0/24 0.0.0.0 0 32768 i

*> 40.0.0.0/24 1.1.1.1 0 64014 i

*> 40.0.1.0/24 1.1.1.1 0 64014 i

*> 40.0.2.0/24 1.1.1.1 0 64014 i

R2#

No prefixes 30

R2#sh ip route

30.0.0.0/24 is subnetted, 3 subnets

D 30.0.2.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2

D 30.0.0.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2

D 30.0.1.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2

R2#

Now, let’s go further and configure backdoor feature on R2 even though networks 30 are not connected.

R2(config)#router bgp 64023
R2(config-router)#net 30.0.0.0 mask 255.255.255.0 backdoor
R2(config-router)#net 30.0.1.0 mask 255.255.255.0 backdoor

R2(config-router)#net 30.0.2.0 mask 255.255.255.0 backdoor

Now let’s check again R2 BGP & RIB tables

R2#sh ip bgp

r>
30.0.0.0/24 1.1.1.1 0 64014 64030 i

r>
30.0.1.0/24 1.1.1.1 0 64014 64030 i

r>
30.0.2.0/24 1.1.1.1 0 64014 64030 i


R2#

R2#sh ip route

30.0.0.0/24 is subnetted, 3 subnets

D 30.0.2.0 [90/2297856] via 172.16.23.3, 00:00:13, Serial1/2

D 30.0.0.0 [90/2297856] via 172.16.23.3, 00:00:19, Serial1/2

D 30.0.1.0 [90/2297856] via 172.16.23.3, 00:00:16, Serial1/2

R2#

That’s exactly what we were looking for.

More detailed BGP inf.

R2#sh ip bgp 30.0.0.0
BGP routing table entry for 30.0.0.0/24, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))

Flag: 0x820

Not advertised to any peer

64014 64030

1.1.1.1 from 1.1.1.1 (1.1.1.1)

Origin IGP, localpref 100, valid, external, best

R2#

Note the RIB-failure

This is when BGP fail to install its best selection into the routing table (or maximum prefix number is configured or even in some cases IOS failure)

In our case it is caused by a better routing protocol, and knowing that EIGRP AD = 90 and eBGP =90 we can conclude that IOS manipulated them accordingly to make EIGRP the winner. (Solution A-2)

Conclusion:

We have seen that backdoor feature (solution B) accomplishes the work in 2 different ways:

1- Not advertise prefixes through eBGP (solution A-1) if configured only on the originating router and this last is rebooted.

2- Continue to advertise prefixes and manipulate Administrative distances if configured on both Border routers delimiting the backdoor connection (solution A-2).

BGP Conditional advertisement


This tutorial describes the process of BGP conditional adveretisement of prefixes, the configuration and the verification in Cisco IOS.

Check your regular expression mastery


You want to test your BGP regular expression mastery, the following QUIZ is for you!
It is a ten-question test randomly generated from a database of 41 questions :
2 basic
5 intermediate
3 advanced

http://hpnouri.free.fr/regexp.htm

I will feed it regularly with interesting questions, any contribution is welcome.

Below an attempt to embedd the flash content locally.
[gigya width=”800″ height=”600″ src= http://hpnouri.free.fr/regexp.swf%5D

Interactive BGP troubleshooting


As you probably know, one of the major changes in CCIE R&S (4.0) is the troubleshooting section, 10 tickets to troubleshoot in 2 hours, a new challenge to face for CCIE candidates.

Of course troubleshooting has always been an inherent part of the exam, which depends on the task difficulty, the candidate level of preparation and personal experience.

Less experienced or not very prepared candidates will have heuristic oriented approach to troubleshooting: using “trial and error”, rely more on “show running-config” and the memory of how the configuration “should look like”.

More experienced and well prepared candidates, will rely more on systematic and organized approach based on careful investigation and diagnosis: analysis of configuration parameters and an accurate interpretation of the appropriate “show” commands.

So the idea of this post, inspired from the comprehensive, but not very comfortable to read (at least for me:-P) ) BGP troubleshooting flowchart of Cisco (picture1). A regular usage of such approach will help acquire and consolidate a systematic method of troubleshooting.

Picture1


I turned the flowchart into an interactive flash (picture2) using Adobe Captivate, I hope making it easier and more comfortable to read. (click picture2 to browse it)

I hosted the “swf” at a third-party site, because unfortunately wordpress doesn’tb allow them, you can also download it to browse offline

Of course, it is subject to changes and modifications, so please don’t hesitate to leave your comments and suggestions.

A similar work for OSPF, EIGRP, MPLS, MPLS VPN troubleshooting will follow.

Below an attempt to embedd the flash content locally, I need to find a way to resize it.

%d bloggers like this: