Enterprise Core Routing Design Models with BGP

Reading through the well-written CCDE Study Guide book by Marwan Al-shawi, came to a section about having BGP as the Enterprise Core Routing Protocol and its possible Design models.

To make it a little bit brighter to myself, I’m gonna explain them in a different way with different diagrams and matrix based on my own design experience with these models.

Disclaimer: Please have in mind that the number of routers drawn, doesn’t reflect the reality of the design, and is just been this way for the sake of simplicity; obviously there would be redundant routers in real World, and also the Core could span different PoPs.
Besides, the bigger border routers could reflect two separate ones, one on Core, and one on Branch side.

Design Model 1

BGP-as-Enterprise-Core-Routing-Design-Model-1

This model is suitable when least Administrative Domain Control is required; though it still overcomes an end-to-end IGP design, providing better management between remote campuses.

Core IGP is mainly used to provide Next-hop reachability for iBGP speakers. Please note that this is applicable to all models where iBGP is used in the Core.

The downside to this design is moderate operation complexity; which could arise i.e. by IGP-into-BGP Redistribution and iBGP full-mesh/RR/Confederation management in the Core. Continue reading “Enterprise Core Routing Design Models with BGP”

Share this!

BGP – Controlling the Entry Point (HLD)

From the BGP Design point of view (HLD), there are four options to manipulate the inbound traffic, MED, AS-path prepending, using communities, and breaking aggregated routes.

MED

This is not really useful, as it has to meet some conditions:

  • The AS-path of learned routes should be identical. Thus, this could be only useful when multihoming to the same AS.
  • The BGP peer might use Local-Preference in the Path Selection process.
  • Usually, Service Providers reset or strip received MED.

AS-Path Prepending

It’s not always helpful.

Continue reading “BGP – Controlling the Entry Point (HLD)”

Share this!

Advanced Cisco BGP features: Selective Next-hop

Below topology was used for this post, and all the configuration happened on two Cisco CSR1000v

topo-2routers-dual-link

BGP Selective Next-hop Route filtering

Imagine that you want to accept routes only from peers, which the route covering the next-hop passes specific conditions, such as prefix-length, or protocol.

In the following configuration I will only accept routes from peers, which the route covering the next-hop has a mask of less-equal to 24:

Let’s see the current BGP table:

Continue reading “Advanced Cisco BGP features: Selective Next-hop”

Share this!

Advanced Cisco BGP features: NSF

Below topology was used for this post, and all the configuration happened on two Cisco CSR1000v

topo-2routers-dual-link

BGP Nonstop Forwarding

  • During normal NSF operation, CEF on the active RP synchronizes its current FIB and adjacency databases with the FIB and adjacency databases on the standby RP
  • While switching over, the traffic is depended on CEF, once the routing protocol is converged, FIB will be updated
  • RIB repopulating happens prefix-by-prefix, thus the same for FIB and adjacency table
  • For BGP NSF, graceful-restart needs to be configured on both ends of a BGP session. Although one end could be only NSF-aware (not SSO capable)
  • BFD can’t be enabled simultaneously with NSF for BGP
  • SSO is not integrated into EIGRP, hence only NSF awareness is supported

Continue reading “Advanced Cisco BGP features: NSF”

Share this!

Advanced Cisco BGP features: BFD

Below topology was used for this post, and all the configuration happened on two Cisco CSR1000v

topo-2routers-dual-link

Bidirectional Forwarding Detection for BGP

I have just one note here. BFD can’t be enabled simultaneously with NSF for BGP. Even for other protocols, extreme care should be taken while implementing BFD with NSF. Depending on the platform, there may be enough of a traffic outage during the switchover to cause BFD to prematurely signal a link failure. When BFD is running on the RP, some platforms are not able to detect a switchover before the BFD protocol times out; these platforms are referred to as slow switchover platforms. Continue reading “Advanced Cisco BGP features: BFD”

Share this!