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

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.

BGP link-bw & multipath Load Balancing


 

An autonomous system can be connected to another through multiple links and according to the company business and redundancy requirements different schemes can be used:

          Primary/secondary: where the second link is used only when the first link fails.

           Symmetric load-sharing: where the traffic is equally distributed among multiple links in the same time, which provides a high level of redundancy for the enterprise.

But, it’s not always possible to provide equal bandwidth links because of either financial limits or availability of such solution. So the need to engineer traffic through these links according to their  bandwidth  capacity.

Here comes the solution of BGP link bandwidth.

With the deployment of BGP multipath, generally the decision of using multiple path to deliver the traffic is performed inside the autonomous system by an iBGP according to multiple criteria excluding the eBGP link bandwidth.

BGP link-bw advertise bandwidth of an autonomous system exit link as extended community to iBGP.

Some requirements are to be considered:

          Only between directly connected eBGP peers.

          BGP extended community should be enabled between iBGP.

          CEF should be enabled everywhere.

Figure 1 illustrates the lab topology used to implement BGP link-bw

Figure1: Topology

Inside AS 64540, R1, R2 and R3 establish full mesh iBGP sessions, the same for AS 64550: R4, R5, R6 and R7 establish full mesh iBGP sessions.

Links R2-R4, R5-R3, R6-R3 are direct eBGP sessions using interfaces ip addresses as sources and destinations.

 

Network default behavior

The network default configuration is as follow:

AS 64540:

R1:

R1(config-router)#do sh ip bgp

BGP table version is 3, local router ID is 10.10.10.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.10.10.0/24    0.0.0.0                  0         32768 i

* i70.70.70.0/24    3.3.3.3                  0    100      0 64550 i

*>i                 2.2.2.2                  0    100      0 64550 i

R1(config-router)#

 

R1(config-router)#do sh ip bgp 70.70.70.0

BGP routing table entry for 70.70.70.0/24, version 3

Paths: (2 available, best #2, table Default-IP-Routing-Table)

  Not advertised to any peer

  64550

    3.3.3.3 (metric 2297856) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 0, localpref 100, valid, internal

  64550

    2.2.2.2 (metric 2297856) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 0, localpref 100, valid, internal, best

R1(config-router)#

the default path chosen is through R2-R4:

R1(config-router)#do traceroute 70.70.70.1 source 10.10.10.1

 

Type escape sequence to abort.

Tracing the route to 70.70.70.1

 

  1 192.168.12.2 24 msec 320 msec 452 msec

  2 192.168.24.2 1004 msec 716 msec 484 msec

  3 192.168.47.2 292 msec *  556 msec

R1(config-router)#

So the traffic from R1 to R7 takes the path R1-R2-R7

 Table1: best path selection for 70.70.70.1/24 from R1

 

Attribute

Path1

Path2

1

weight

0

0

2

local preference

100

100

3

originated locally

No

No

4

AS_PATH

64550

64550

5

ORIGIN

i

i

6

MED

0

0

7

eBGP<>iBGP

iBGP

iBGP

8

Best IGP metric to NEXT-HOP

2297856

2297856

9

Multipath

No

No

10

oldest path

No

No

11

Lowest neighbor router-ID

3.3.3.3

2.2.2.2  <<<

 

AS 64550:

R7:

R7(config-router)#do sh ip bgp

BGP table version is 3, local router ID is 70.70.70.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

* i10.10.10.0/24    5.5.5.5                  0    100      0 64540 i

*>i                 4.4.4.4                  0    100      0 64540 i

* i                 6.6.6.6                  0    100      0 64540 i

*> 70.70.70.0/24    0.0.0.0                  0         32768 i

R7(config-router)#

 

R7(config-router)#do traceroute 10.10.10.1 source 70.70.70.1

 

Type escape sequence to abort.

Tracing the route to 10.10.10.1

 

  1 192.168.47.1 8 msec 268 msec 104 msec

  2 192.168.24.1 164 msec 348 msec 136 msec

  3 192.168.12.1 276 msec *  260 msec

R7(config-router)#

So the traffic from R7 to R1 takes the path R7-R4-R2-R1

R7(config-router)#do sh ip bgp 10.10.10.0

BGP routing table entry for 10.10.10.0/24, version 3

Paths: (3 available, best #2, table Default-IP-Routing-Table)

  Not advertised to any peer

  64540

    5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)

      Origin IGP, metric 0, localpref 100, valid, internal

  64540

    4.4.4.4 (metric 2297856) from 4.4.4.4 (4.4.4.4)

      Origin IGP, metric 0, localpref 100, valid, internal, best

  64540

    6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)

      Origin IGP, metric 0, localpref 100, valid, internal

R7(config-router)#

 

R4-R2 link is chosen as the best path to reach the prefix 10.10.10.1/24:

Table2: best path selection for 10.10.10.1/24 from R7

 

Attribute

Path1

Path2

Path3

1

weight

0

0

0

2

local preference

100

100

100

3

originated locally

No

No

No

4

AS_PATH

64540

64540

64540

5

ORIGIN

i

i

i

6

MED

0

0

0

7

eBGP<>iBGP

iBGP

iBGP

iBGP

8

Best IGP metric to NEXT-HOP

2297856

2297856

2297856

9

Multipath

No

No

No

10

oldest path

No

No

No

11

Lowest neighbor router-ID

5.5.5.5

4.4.4.4  <<<

6.6.6.6

 

BGP Link-BW deployment

The best way to utilize BW resources is to load-share the traffic among the three eBGP link according to their BW:

let’s recall the requirements for using BGP link BW:

– Requires BGP multipath configured.

– Enable BGP ext. community between iBGP.

– Enable CEF everywhere.

General configuration:

On each iBGP speaker with multilink ramification, enable iBGP multipath

router bgp <ASnbr>

 maximum-paths <n>

 maximum-paths ibgp <n>

 

router bgp <ASnbr>

 address-family ipv4

 neighbor <iBGP_peer> activate

 neighbor <iBGP_peer> send-community extended

!iBGP peer to which extended community is to be send.

 

 neighbor <eBGP_peer> activate

 neighbor <eBGP_peer> dmzlink-bw

!Allow eBGP bandwidth to be propagated through link-bw extended community

 

 bgp dmzlink-bw

!‚Äúbgp dmzlink-bw‚ÄĚ is configured on any router whose eBGP link bandwidth !will be used for load-balancing.

 exit-address-family

 

As 65540:

R1(iBGP):

router bgp 64540

 address-family ipv4

 neighbor 2.2.2.2 activate

 neighbor 3.3.3.3 activate

 

 maximum-paths 3

 maximum-paths ibgp 3

 

 exit-address-family

eBGP speaker R2:

router bgp 64540

 address-family ipv4

 neighbor 1.1.1.1 activate

 neighbor 1.1.1.1 send-community extended

 neighbor 1.1.1.1 next-hop-self

 

 neighbor 3.3.3.3 activate

 neighbor 3.3.3.3 next-hop-self

 

 neighbor 192.168.24.2 activate

 neighbor 192.168.24.2 dmzlink-bw

 bgp dmzlink-bw

 exit-address-family

eBGP speaker R3:

router bgp 64540

 

 address-family ipv4

 neighbor 1.1.1.1 activate

 neighbor 1.1.1.1 send-community extended

 neighbor 1.1.1.1 next-hop-self

 

 neighbor 2.2.2.2 activate

 neighbor 2.2.2.2 next-hop-self

 

 neighbor 192.168.35.2 activate

 neighbor 192.168.35.2 dmzlink-bw

 

 neighbor 192.168.36.2 activate

 neighbor 192.168.36.2 dmzlink-bw

 

 maximum-paths 2

 maximum-paths ibgp 2

 

 bgp dmzlink-bw

 

 exit-address-family

 

Verification:

R1#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

       D РEIGRP, EX РEIGRP external, O РOSPF, IA РOSPF inter area

       N1 РOSPF NSSA external type 1, N2 РOSPF NSSA external type 2

       E1 РOSPF external type 1, E2 РOSPF external type 2

       i РIS-IS, su РIS-IS summary, L1 РIS-IS level-1, L2 РIS-IS level-2

       ia РIS-IS inter area, * Рcandidate default, U Рper-user static route

       o РODR, P Рperiodic downloaded static route

 

Gateway of last resort is not set

 

     192.168.12.0/30 is subnetted, 1 subnets

C       192.168.12.0 is directly connected, Serial1/0

     1.0.0.0/32 is subnetted, 1 subnets

C       1.1.1.1 is directly connected, Loopback0

     192.168.13.0/30 is subnetted, 1 subnets

C       192.168.13.0 is directly connected, Serial1/1

     2.0.0.0/32 is subnetted, 1 subnets

D       2.2.2.2 [90/2297856] via 192.168.12.2, 03:20:35, Serial1/0

     70.0.0.0/24 is subnetted, 1 subnets

B       70.70.70.0 [200/0] via 3.3.3.3, 01:11:12

                   [200/0] via 2.2.2.2, 01:11:12

     3.0.0.0/32 is subnetted, 1 subnets

D       3.3.3.3 [90/2297856] via 192.168.13.2, 03:20:29, Serial1/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.10.10.0 is directly connected, Loopback1

R1#

 

R1#sh ip route 70.70.70.1

Routing entry for 70.70.70.0/24

¬† Known via “bgp 64540”, distance 200, metric 0

  Tag 64550, type internal

  Last update from 2.2.2.2 01:08:48 ago

  Routing Descriptor Blocks:

    3.3.3.3, from 3.3.3.3, 01:08:48 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

      Route tag 64550

  * 2.2.2.2, from 2.2.2.2, 01:08:48 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

      Route tag 64550

 

R1#

R1:

R1#sh ip bgp 70.70.70.1

BGP routing table entry for 70.70.70.0/24, version 7

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Multipath: eBGP iBGP

  Not advertised to any peer

  64550

    3.3.3.3 (metric 2297856) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 0, localpref 100, valid, internal, multipath

      DMZ-Link Bw 1443 kbytes

  64550

    2.2.2.2 (metric 2297856) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 0, localpref 100, valid, internal, multipath, best

      DMZ-Link Bw 12500 kbytes

R1#

Note the proportion of the link BW of path 2 (through 2.2.2.2) against link BW of path 1 (through 3.3.3.3).

 Table3: best path selection for 70.70.70.1/24 from R1 after BGP Link-bw

 

Attribute

Path1

Path2

1

weight

0

0

2

local preference

100

100

3

originated locally

No

No

4

AS_PATH

64550

64550

5

ORIGIN

i

i

6

MED

0

0

7

eBGP<>iBGP

iBGP

iBGP

8

Best IGP metric to NEXT-HOP

2297856

2297856

9

Multipath

2 <<<<

2 <<<<

10

oldest path

No

No

11

Lowest neighbor router-ID

3.3.3.3

2.2.2.2 

 

R3:

R3#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

       D РEIGRP, EX РEIGRP external, O РOSPF, IA РOSPF inter area

       N1 РOSPF NSSA external type 1, N2 РOSPF NSSA external type 2

       E1 РOSPF external type 1, E2 РOSPF external type 2

       i РIS-IS, su РIS-IS summary, L1 РIS-IS level-1, L2 РIS-IS level-2

       ia РIS-IS inter area, * Рcandidate default, U Рper-user static route

       o РODR, P Рperiodic downloaded static route

 

Gateway of last resort is not set

 

     192.168.12.0/30 is subnetted, 1 subnets

D       192.168.12.0 [90/2681856] via 192.168.13.1, 03:21:04, Serial1/0

     1.0.0.0/32 is subnetted, 1 subnets

D       1.1.1.1 [90/2297856] via 192.168.13.1, 03:21:04, Serial1/0

     192.168.13.0/30 is subnetted, 1 subnets

C       192.168.13.0 is directly connected, Serial1/0

     2.0.0.0/32 is subnetted, 1 subnets

D       2.2.2.2 [90/2809856] via 192.168.13.1, 03:21:04, Serial1/0

     70.0.0.0/24 is subnetted, 1 subnets

B       70.70.70.0 [20/0] via 192.168.35.2, 01:11:47

                   [20/0] via 192.168.36.2, 01:11:47

     3.0.0.0/32 is subnetted, 1 subnets

C       3.3.3.3 is directly connected, Loopback0

     10.0.0.0/24 is subnetted, 1 subnets

B       10.10.10.0 [200/0] via 1.1.1.1, 01:18:16

     192.168.36.0/30 is subnetted, 1 subnets

C       192.168.36.0 is directly connected, Serial1/1

     192.168.35.0/30 is subnetted, 1 subnets

C       192.168.35.0 is directly connected, Ethernet0/0

R3#

 

R3#sh ip route 70.70.70.1

Routing entry for 70.70.70.0/24

¬† Known via “bgp 64540”, distance 20, metric 0

  Tag 64550, type external

  Last update from 192.168.36.2 01:09:28 ago

  Routing Descriptor Blocks:

  * 192.168.35.2, from 192.168.35.2, 01:09:28 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

      Route tag 64550

    192.168.36.2, from 192.168.36.2, 01:09:28 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

      Route tag 64550

 

R3#

 

R3#sh ip bgp 70.70.70.1

BGP routing table entry for 70.70.70.0/24, version 6

Paths: (3 available, best #1, table Default-IP-Routing-Table)

Multipath: eBGP iBGP

  Advertised to update-groups:

     1          2          3

  64550

    192.168.35.2 from 192.168.35.2 (5.5.5.5)

      Origin IGP, localpref 100, valid, external, multipath, best

      DMZ-Link Bw 1250 kbytes

  64550

    2.2.2.2 (metric 2809856) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 0, localpref 100, valid, internal

  64550

    192.168.36.2 from 192.168.36.2 (6.6.6.6)

      Origin IGP, localpref 100, valid, external, multipath

      DMZ-Link Bw 193 kbytes

R3#

Note the proportion of the link BW of path 1 (through 192.168.35.2) against link BW of path 1 (through 192.168.36.2).

AS 64550:

The same configuration can be done for AS 64550 to have a symmetric traffic flow between the two ASs:

R4:

R4#bgpcf

router bgp 64550

 address-family ipv4

 neighbor 5.5.5.5 activate

 

 neighbor 6.6.6.6 activate

 

 neighbor 7.7.7.7 activate

 

 neighbor 7.7.7.7 send-community extended

 

 neighbor 192.168.24.1 activate

 

 neighbor 192.168.24.1 dmzlink-bw

 

 bgp dmzlink-bw

 exit-address-family

R5:

bgp 64550

 address-family ipv4

 neighbor 4.4.4.4 activate

 

 neighbor 6.6.6.6 activate

  

 neighbor 7.7.7.7 activate

 

 neighbor 7.7.7.7 send-community extended

 

 neighbor 192.168.35.1 activate

 

 neighbor 192.168.35.1 dmzlink-bw

 

 bgp dmzlink-bw

 

 exit-address-family

R6:

router bgp 64550

 address-family ipv4

 neighbor 4.4.4.4 activate

  

 neighbor 5.5.5.5 activate

 

 neighbor 7.7.7.7 activate

 neighbor 7.7.7.7 send-community extended

  

 neighbor 192.168.36.1 activate

 

 neighbor 192.168.36.1 dmzlink-bw

 

 bgp dmzlink-bw

 

 exit-address-family

R7:

router bgp 64550

 address-family ipv4

 neighbor 4.4.4.4 activate

 neighbor 5.5.5.5 activate

 neighbor 6.6.6.6 activate

  

 maximum-paths 3

 maximum-paths ibgp 3

 

 exit-address-family

 

R7#sh ip bgp 10.10.10.1

BGP routing table entry for 10.10.10.0/24, version 9

Paths: (3 available, best #3, table Default-IP-Routing-Table)

Multipath: eBGP iBGP

Flag: 0x800

  Not advertised to any peer

  64540

    5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)

      Origin IGP, metric 0, localpref 100, valid, internal, multipath

      DMZ-Link Bw 1250 kbytes

  64540

    6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)

      Origin IGP, metric 0, localpref 100, valid, internal, multipath

      DMZ-Link Bw 193 kbytes

  64540

    4.4.4.4 (metric 2297856) from 4.4.4.4 (4.4.4.4)

      Origin IGP, metric 0, localpref 100, valid, internal, multipath, best

      DMZ-Link Bw 12500 kbytes

R7#

 

Table4: best path selection for 10.10.10.1/24 from R7 after configuring BGP link-bw

 

Attribute

Path1

Path2

Path3

1

weight

0

0

0

2

local preference

100

100

100

3

originated locally

No

No

No

4

AS_PATH

64540

64540

64540

5

ORIGIN

i

i

i

6

MED

0

0

0

7

eBGP<>iBGP

iBGP

iBGP

iBGP

8

Best IGP metric to NEXT-HOP

2297856

2297856

2297856

9

Multipath

3 <<<<

3 <<<<

3 <<<<

10

oldest path

No

No

No

11

Lowest neighbor router-ID

5.5.5.5

4.4.4.4

6.6.6.6

 

CONCLUSION

BGP link-bw provides an optimal way to use link bandwidth resources between autonomous systems, make sure CEF is enabled (enabled by default), iBGP multipath is already configured and enable the propagation of the extended community to iBGP neighbors.

%d bloggers like this: