Raymond P. Burkholder - Things I Do - BGP

BGP Local Preference vs MED

nospam@example.com (Raymond P. Burkholder) — Fri, 01 Apr 2022 03:52:48 +0000

Seen on a mailing list, some comments regarding local preference vs MED.

Unfortunately, the reason crazy-long prepends actually propagate so widely in the internet core is because most of those decisions to prefer your peer's customers are done using a relatively big and heavy hammer.
> IOW if your peer or customer has prepended 5 times or more, dont LOCAL_PREF or maybe even de-LOCAL_PREF it
LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most of the networks out there seem to have settled on, to the point of having published BGP communities to use for controlling the LOCAL_PREF setting on received routes: https://onestep.net/communities/
I've long practiced, and advocated for, the use of MEDs or tweaking origin codes as a better way to nudge traffic towards customers, peers, customers of peers, etc., because it still allows as-path to be a factor in nudging traffic away. Prepend inbound 3 times on routes learned from your transit provider, but not on your peers, listen to MEDs from your peers, and enable always-compare-med and deterministic-med to allow values to be compared across different pathways.
That way, someone trying to say "don't use this path" can do a simple triple-prepend, and see their traffic shift. In our current world of using LOCAL_PREF, however, the poor customer keeps prepending more and more, and never sees their traffic shift. In desperation, they prepend the maximum number of times allowed, hoping that maybe this will somehow do the trick...not understanding that no matter what they do in the prepend realm, so long as their upstreams are using the LOCAL_PREF hammer, their prepends will fall on deaf ears.
For the most part--if you think LOCAL_PREF is the right knob to use for moving traffic, it probably means you need to go back and rethink your traffic engineering approach.

EVPN Reading Material

nospam@example.com (Raymond P. Burkholder) — Mon, 21 Aug 2017 14:03:00 +0000

With the release of FRRouting Protoocol Suite, a wide range of networking abilities become possible. Some MPLS/LDP capabilities become available. But problem FRR's power comes with it's implementation of EVPN based upon BGP MPLS-Based Ethernet VPN. This RFC refers to Requirements for Ethernet VPN (EVPN).

The FRR implementation of EVPN uses VXLAN as the underlying encapsulation mechanism.

The first details I saw of EVPN in FRR was from RIPE 74 Presentations site. Slides 15 through 18 discuss some features. EVPN route types 2, 3 (L2 EVPN overlay), and 5 (segment routing) are supported.

Major Changes as listed on the FRR github wiki.
EVPN: Intro to next gen L2VPN has some L2VPN comparisons, provides some terminology, and some high level examples for split horizon, multicast, and aliasing.
BGP EVPN VXLAN from Cumulus, a good high level review with some console examples
Vincent Bernat: VXLAN BGP EVPN with Cumulus covers some interop examples with Juniper and GoBGP. The same thing on Vincent Bernat's Website.
MC-LAG is dead, Long Live EVPN Multi-Homing is an article from Juniper describing how the ESI attribute of EVPN is used to multi-home a CPE to two or more devices. I wonder if that works in FRR? Some more related material, with extracts from the RFC can be found at EVPN Technologies.
FRR VRF: in issue 483, a small example for MP-BGP and VRF-lite. Some mailing list talk on BGP VRF processing handling.
VRF Docs in the kernel doc directory.
Sam Russell MPLS Test Bed on kernel 4.3
Rick Mur's take on RFC 7432 from a Juniper perspective.
Patch Work version of the BGP VRF processing handling discussion. Patchwork has been replaced by github.
Using EVPN in Very Small Data Center Fabrics - ipspace says not in a yes kinda way

Segment Routing ipv6 introduced in kernel v4.10.
Implementing IPv6 Segment Routing in the Linux Kernel: linked from IP Networking Lab.
Kernel Implementation: more info

BGP Default-Information Originate

nospam@example.com (Raymond P. Burkholder) — Fri, 07 Dec 2012 20:37:49 +0000

A brief note on the rules for originating a default route into BGP (copied from a posting made by Mohammed Mahmoud):

default-information originate + redistribute static (or any dynamic routing protocol having the default route - you may filter only the default route)
network command but must make sure the default route is present in the routing table
issuing the neighbor default-originate command. This method does not require the presence of the 0.0.0.0/0 network in the routing table of the advertising router

Additional notes: The configuration of the default-information originate command in BGP is similar to the configuration of the network (BGP) command. The default-information originate command, however, requires explicit redistribution of the route 0.0.0.0. The network command requires only that the route 0.0.0.0 is present in the Interior Gateway Protocol (IGP) routing table. For this reason, the network command is preferred.

Real Time Black Holing (RTBH)

nospam@example.com (Raymond P. Burkholder) — Sat, 12 Jun 2010 18:44:28 +0000

Here are some notes to self regarding real time blackholing configurations for dropping / analyzing packets that 'do not belong'.

BGP Security Techniques (pdf)
Inferring Internet Denial-of-Service Activity (pdf)
Cisco Paper: Remotely Triggered Black Hole Filtering -- Destination Based and Source Based (pdf), with a note at NSP ARchives that disable-connected-check needs to be added to the peer's bgp configuration.
IPv6Canada: S/RTBH Example
PacketLife: RTBH Routing

From the c-nsp list, RTBH commonly used next hops are RFC based Test Networks:

IPv4 RFC3330 192.0.2.0/24
IPv6 RFC5156 2001:db8::/32

Routing Within An ISP

nospam@example.com (Raymond P. Burkholder) — Sun, 03 May 2009 21:56:38 +0000

Many ISP's I've seen have had two routing protocols implemented: BGP to talk to the 'internet' with the external /24 and shorter prefixes, and an internal routing protocol such as EIGRP or OSPF to handle the internal /24 and longer prefixes. The internal protocol would be running on all ISP devices and would handle all infrastructure devices and customer links. For a multi-homed ISP, BGP would need to be running on all internal devices that form internal paths from one external link to another. This provides an ability to choose an appropriate exit point for any traffic generated from within an ISP destined for the external network. Some ISP's 'cheat' by generating default routes to the nearest exit and having BGP reside only on edge devices. Some optimum paths will be missed using this simplified arrangement, particularily if an ISP is connected to non-transit neighbors.

Current best practices make expanded use of BGP. BGP, known as IBGP, is used extensively within the ISP to carry customer prefixes. The internal routing protocol such as OSPF or EIGRP is used simply for carrying infrastructure routes such as loopback addresses and link addresses.

With this arrangement, it is then easy to make use of MP-BGP (Multi-Protocol BGP) to handle the various requirements for carrying MPLS links.

One presentation at RIPE shows some basics of BGP Best Practices.