the slide with the requirements and proposed solution are eloquent:
MPLS for the masses
giovedì 11 maggio 2023
BGP is the answer, what is the question ?
the slide with the requirements and proposed solution are eloquent:
mercoledì 27 aprile 2022
modern bgp design
The Wholesale Winery Tour 2022 was an opportunity to meet old and new friends, and to present something new.
"modern bgp design" is a talk on how to overcome the stereotypes of traditional bgp design and combine new features using BGP as a real control-plane protocol.
The target of the presentation are small and medium-sized service providers and the will is to rationalize network resources and simplify infrastructure and configurations. It is then used what I use to call a "dual stage lookup" for upstream traffic, distributing only the default route within the POPs and DCs, and keeping the Full Internet Routing Table only within the core devices.
A single pair of RR is used for the entire infrastructure, exploiting a combination of ADD-PATH [rfc7911] and ORR [rfc9107] (Optimized Route Reflection) to distribute in a targeted manner the only information necessary to maintain optimal routing and guarantee load-balancing or even just High Availability based on a local convergence.
this is the full Presentation
venerdì 29 maggio 2020
Switch as Internet Border Router - FIRT with selective FIB install
lunedì 3 dicembre 2018
The need for simplicity and standardization, at least in networking (The wheel has already been invented)
- Made by experts and based on their greater experience
- Born to guarantee interoperability between different vendors
- Continuously verified to guarantee compatibility with the new releases of AOS and vendors.
lunedì 7 novembre 2016
evpn control-plane for overlay networks
I talked about the use EVPN as control plane for overlay networks, and how to exploit them to create distributed services between different datacenters.
I also mentioned the use of EVPN type-5 with proxy-arp to reduce distribution of mac-address routes and completely eliminate layer-2, while maintaining compatibility with current clustering and HA solutions based on layer-2 but now distributed in multiple datacenters.
this is the full presentation.
lunedì 20 agosto 2012
BGP Diverse-Path for a faster convergence
The BGP implementation in Junos is event-driven while in IOS is timer based and require that the scan process goes trough the BGP Table and select the best path to put into the RIB. The BGP scan-time command control this interval, with a default value of 60 sec.
In a large scale bgp scenario where usually route reflectors are involved, this mean that in the worst case the convergence time can be up to 120 sec because the route-reflector convergence and bgp update is required before the client can have a consistent BGP table and compute the new best path updating the RIB.
This is because Route Reflectors distribute to the clients only the best path.
In layer-3 MPLS VPN scenario this problem is solved using different Route-Distinguisher that create not comparable entry on route reflectors allowing reflection of both routes to all clients. This action moves the best-path selection process to all clients, eliminating the intermediate covergence step of route-reflectors.
But how to solve the problem in global routing table ?
Different approach are proposed, and a wonderful discussion can be reached here:
http://blog.ine.com/2010/11/22/understanding-bgp-convergence/
I already use the Add-Path ( http://tools.ietf.org/html/draft-ietf-idr-add-paths-07 ) extension that permit multiple next-hop for the same prefix, this allows load-balancing in addition to the fast convergence due to the direct next-hop tracking, but this approach require the support of this new bgp capability and usually MPLS encapsulation on the backbone to prevent ip lookups and possible routing loops on transit nodes.
BGP Diverse-Path ( http://tools.ietf.org/html/draft-ietf-grow-diverse-bgp-path-dist-08 ) it's not a new capability, but comes from the knowledge of the topology and uses existing attributes of a typical RR BGB Cluster. One cluster member are selected as a "shadow" route-reflector and instead of reflect the best path ( that is reflected by the others route reflector in the cluster ) it's announce the backup path to his clients. It's also important to note that like all other routers in the backbone, it still install the best path into it's own RIB for traffic forwarding.
Now all backbone routers has at least two iBGP peering session to the RR Cluster, the first to the regular route-reflector and the other to the shadow RR.
BGP topology on the RR clients now contain the best and the backup path, allowing a local calculation of the best path. This step eliminates the need of convergence of the route-reflector, halving the total convergence time removing the convergence requirement of the route reflector.
The complete addressing and IGP configuration of R2 looks like:
R1 is chosen as the shadow route reflectors.
To configure the BGP Diverse Path on the shadow router 4 steps are required:
1) Disable the IGP bestpath igp-metric tie-break ( optional and topology depended )
bgp bestpath igp-metric ignore
2) Allow the identification of the backup path
bgp additional-paths select backup
3) Permit the backup path announcement
bgp additional-paths send
4) select the route-reflection clients enabled for the update ( the Clients peer-group )
neighbor Clients advertise diverse-path backup
The complete BGP configuration of the shadow RR ( R1 )
check the BGP status:
The bgp table identify the best path for for "FD00:5::/64" trough R2 ( and install into the RIB ) and the possible "backup-path" trough R4:
This backup path is now sent to R3:
on R3 the nexthop trigger is enabled with a timeout of 1 sec for the IPv6 address-family
on R3 two exit point for FD00:5::/64 are now present, and the best path still select R2 as the primary, but the backup path is already present in the BGP table
A traceroute confirm the complete path correctness:
As a simple test, during a continuous ping to R5 from R3, the R2 loopback was forced down, triggering the backup path selection without any packet loss.
Conclusion
Whit this solution the convergence time of bgp is now comparable to the IGP also with route reflectors.
BGP add-path is obviously the more powerful options but require the specific capability in most of the BGP speaker, and then recommended for new solutions, while diverse-path can help to improve the global convergent time without requiring any new capability on legacy device. MPLS is not always required for both solutions, but take my advice and adopt it always.
Feature availability:
This feature is primary available in IOS XR and recently implemented in IOS 15.2(3)T and 15.2(4)S
The complete lab configuration are here