BGP best path selection

The complexity and the efficiency of BGP reside in the concept of route “attributes” and the way the protocol juggles them to determine the best path.

This is a quick guide (refresh of an old article), still very actual for those dealing with BGP design.
I hope the following Cisco BGP best path selection diagram will be of help:



Download the pdf version here


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.


  • 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

Click the picture below to browse the swf animation explaining GET-VPN interactions:

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


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


  • 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 ospf 2345 area 0!

interface FastEthernet0/0

ip address

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip


interface FastEthernet0/1

ip address

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip


interface FastEthernet1/0

ip address

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip


router ospf 2345


router bgp 2345

no synchronization

bgp router-id




neighbor remote-as 2345

neighbor route-reflector-client

neighbor remote-as 2345

neighbor route-reflector-client

neighbor remote-as 2345

neighbor route-reflector-client

no auto-summary


address-family vpnv4

neighbor activate

neighbor send-community extended

neighbor route-reflector-client

neighbor activate

neighbor send-community extended

neighbor route-reflector-client

neighbor activate

neighbor send-community extended

neighbor route-reflector-client


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


GET-VPN configuration:

Key server:

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

crypto isakmp key cisco address

crypto isakmp key cisco address


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


interface FastEthernet0/0

ip address


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!

crypto gdoi group gdoi-group1

identity number 91011

server address ipv4


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.


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
  • 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

Offline lab:

Click  the picture below to browse the flash app of the offline lab:



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:


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


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 


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
:: from (
Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced, best
2001:DB8:15::1 (metric 20) from 2001:DB8:15::1 (
Origin IGP, metric 0, localpref 100, valid, internal,

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



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


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 

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.


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 mask backdoor
R3(config-router)#net mask backdoor

R3(config-router)#net mask backdoor

R3(config-router)#net mask backdoor

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

clear ip bgp soft out
*Mar 1 22:46:20.954: BGP(0): send UPDATE (format), next, metric 0, path Local
*Mar 1 22:46:20.962: BGP(0): send UPDATE (prepend, chgflags: 0x0), next, metric 0, path Local

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

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


So R3 has advertised backdoor prefixes through eBGP…

We can verify this on R2:

R2 (config-router)#do sh ip route is subnetted, 3 subnets

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

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

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


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

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
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

*> 0 0 64014 i

*> 0 0 64014 i

*> 0 0 64014 i

*> 0 32768 i

*> 0 32768 i

*> 0 32768 i

*> 0 64014 i

*> 0 64014 i

*> 0 64014 i


No prefixes 30

R2#sh ip route is subnetted, 3 subnets

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

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

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


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 mask backdoor
R2(config-router)#net mask backdoor

R2(config-router)#net mask backdoor

Now let’s check again R2 BGP & RIB tables

R2#sh ip bgp

r> 0 64014 64030 i

r> 0 64014 64030 i

r> 0 64014 64030 i


R2#sh ip route is subnetted, 3 subnets

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

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

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


That’s exactly what we were looking for.

More detailed BGP inf.

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

Flag: 0x820

Not advertised to any peer

64014 64030 from (

Origin IGP, localpref 100, valid, external, best


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)


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

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=

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.


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.

Here is the link to the flash content:


%d bloggers like this: