From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

NMC DOiT Vol.2 Scenario 4 Day 3-1 – BGP Prepending + AS-Path Matching + Confederation

701 Words. Plan about 4 minute(s) to read this.

I was happy to have nailed the BGP section on this lab. Not that the section was that hard, but it was gratifying to have analyzed the requirements critically enough to see all of the issues and design appropriately for them. Again, a small sign that I’m making progress. The BGP section in this scenario contained requirements needing prepending, as-path matching and confederations to satisfy.

In BGP, a “prepend” is when you make an AS-path look less desirable by inserting extra as hops into the as-path attribute before sending the BGP advertisement to a neighbor. In the context of the Internet backbone, my understanding is that not all providers pay attention to prepends. Nonetheless, I’ve used prepending on stub AS’s to achieve a better balance of incoming traffic when one provider is higher tier than another. So take a look at this chunk of code, stripped down to the bare essentials to demonstrate prepending:

router bgp 300
neighbor 151.90.60.20 route-map prepender out
!
route-map prepender permit 10
match ip address the-10-net
set as-path prepend 300 300 300 300
!
ip access-list standard the-10-net
permit 10.10.10.0 0.0.0.255

In this example, advertisements headed to neighbor 151.90.60.20 will be subject to the instructions of the route-map called “prepender“. Route-map prepender gives instructions to add the AS path 300 300 300 300 to BGP networks matching permit entries in the IP access-list called “the-10-net“. So, let’s say the 10.10.10.0/24 BGP NLRI comes into this router with an as-path of 200 100. Before this router advertises 10.10.10.0/24 to his neighbor 151.90.60.20, he would put on his own AS of 300, like normal, resulting in the as-path you’d anticipate of 300 200 100. But the prepend will add 4 extra “300” as-path hops, making the resulting advertisement to neighbor 151.90.60.20 look like 300 300 300 300 300 200 100.

Another powerful BGP feature is the ability to use regex to pattern-match AS-paths. Once you’ve matched a particular as-path, you can perform whatever action is appropriate.

router bgp 100
neighbor 151.90.25.2 route-map as400-via-r2 in
neighbor 151.90.45.4 route-map as400-via-r4 in
!
ip as-path access-list 1 permit _400$
!
route-map as400-via-r2 permit 10
match as-path 1
set local-preference 100
!
route-map as400-via-r4 permit 10
match as-path 1
set local-preference 200

In this example, the goal is to modify local-pref such that R4 (151.90.45.4) is the preferred next hop (151.90.25.2) over R2 for NLRIs whose as-path ends in “400”. Both route-maps refer to the same “as-path” access-list (named simply “1”), and assign a different local-pref to the NLRI depending which neighbor the advertisement came in on. (Remember that higher local-prefs are preferred in the BGP best-path algorithm.) All the magic is really happening in the “ip as-path access-list 1 permit _400$”. In this as-path access-list, we’re doing a regex pattern match for any as-path that has a blank followed by 400 at the end of the path. The “_” indicates the blank. The “$” indicates the end of the path. So an as-path of “300 500 400” would match. “300 500 5400” would not match. “400 500 600” would not match, either.

BGP confederations are a way to avoid having a full iBGP mesh within an AS. The other obvious choice to avoid a full iBGP mesh is to use route-reflectors. Confederations establish a pseudo-eBGP environment contained within a contiguous AS. Therefore, eBGP rules for route advertisements apply for confederation neighbors with a few exceptions.

———————————————–
R1
———————————————–
router bgp 65201
bgp confederation identifier 200
bgp confederation peers 65206
neighbor 151.90.16.6 remote-as 65206

———————————————–
R2
———————————————–
router bgp 65202
bgp confederation identifier 200
bgp confederation peers 65206
neighbor 151.90.16.6 remote-as 65206
neighbor 151.90.25.5 remote-as 100

———————————————-
R6
———————————————–
router bgp 65206
bgp confederation identifier 200
bgp confederation peers 65201 65202
neighbor 151.90.12.2 remote-as 65202
neighbor 151.90.16.1 remote-as 65201
neighbor 151.90.60.20 remote-as 400

R1, R2 and R6 are in a confederation. Technically, all of these routers are in AS 200. To eBGP neighbors outside of the confederation, they will appear to be AS200 neighbors because of the “bgp confederation identifier 200” statement. To AS’s that are within the confederation (as identified by the “bgp confederation peers” statement), the neighbors will be treated as eBGP neighbors. Here, we have AS numbers 65201, 65202 and 65206 in a confederation. This confederation is within AS200. R1 will peer with R6. R2 will peer with R6. Because of the confederation design, there is no need for R1 to peer with R2. R6 will forward BGP advertisements from R1 to R2 and vice-versa. R6 is also peering with a neighbor outside of the confederation in AS400. This AS400 neighbor will see R6 as a member of AS200, not AS65206.

Read more about AS prepending.

Read more about AS-PATH filters.

Read more about BGP confederations.