as-path outbound filtering with BGP Confederations

[johnnylingo]

In the past I've used as-path filltering out my outbound BGP announcements.  This is done as a safeguard to ensure I don't become a transit AS should the other filters get bungled.  Sample configuration:

router bgp 12345

no synchronization

bgp log-neighbor-changes

network 1.2.3.0 mask 255.255.255.0

neighbor eBGP peer-group

neighbor eBGP prefix-list MY_PREFIXES out

neighbor eBGP filter-list 1 out

!

ip prefix-list MY_PREFIXES seq 10 permit 1.2.3.0/24

!

ip as-path access-list 1 permit ^$

I'm now bringing up a data center using BGP confederations, and am not sure how to translate this policy.  Do I need to explicitly list the Member AS or Confederation AS?   I assume that ^$ would reference the Member AS, but am not sure. 

[Aninda Chatterjee]

Hi Johnny,

Confederations will add a small difference in how you might perceive this to work. Let's take this step by step:

The regular expression being used is ^$. This essentially implies a null AS path - the symbol '^' is for the start of the AS path and the symbol '$' is for the end of the AS path. So applying an AS-path filter like that outbound would mean that you are advertising only locally originated routes, which I believe is the intention since that would mean that your AS would never be used for transit for any other prefix.

When you add confederations into the mixture, with the same AS-path filter, you will be advertising only what the router locally originated - this means that even though your confederation looks like one AS to the outside world, any prefixes that you learned from your confederation peers (sub-AS peers) will not be advertised.

Take the following topology as an example:

R1-------------R2---------------R3----------R4

R1 is running AS 1. R2 is running sub-AS 2. R3 is running sub-AS 3. R2 and R3 form a confederation and to the outside world, they are AS 23. R4 is running AS 4.

R1 has loopback1 as 1.1.1.1/32, R2 has loopback1 as 2.2.2.2/32 and so on.

Without any filters, R1 has the following prefixes:

R1#show ip bgp

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

*> 1.1.1.1/32       0.0.0.0                  0         32768 i

*> 2.2.2.2/32       192.168.1.2              0             0 23 i

*> 3.3.3.3/32       192.168.1.2                            0 23 i

*> 4.4.4.4/32       192.168.1.2                            0 23 4 i

Now I create the filter as below:

R2#show ip as-path-access-list

AS path access list 1

    permit ^$

I apply it outbound on R2 towards R1:

R2#show run | sec router bgp

router bgp 2

no synchronization

bgp log-neighbor-changes

bgp confederation identifier 23

bgp confederation peers 3

network 2.2.2.2 mask 255.255.255.255

neighbor 192.168.1.1 remote-as 1

neighbor 192.168.1.1 filter-list 1 out

neighbor 192.168.2.3 remote-as 3

neighbor 192.168.2.3 next-hop-self

no auto-summary

A clear ip bgp * soft and R1 no longer sees the 3.3.3.3/32 and the 4.4.4.4/32 prefixes:

R1#show ip bgp

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

*> 1.1.1.1/32       0.0.0.0                  0         32768 i

*> 2.2.2.2/32       192.168.1.2              0             0 23 i

R2 is no longer advertising these:

R2#show ip bgp neighbors 192.168.1.1 advertised-routes

BGP table version is 5, local router ID is 2.2.2.2

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

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

Total number of prefixes 1

This implies that even though the confederation technically is one AS to the outside world, with the ^$ AS-path filter, you will only be sending out what the local router originated and nothing else - not even prefixes that were learned via sub-AS peers.

I hope this helps.

Regards,

Aninda

[Peter Paluch]

Hello Aninda,

Very nice and insightful answer! Please allow me to add a few thoughts.

This implies that even though the confederation technically is one AS to  the outside world, with the ^$ AS-path filter, you will only be sending  out what the local router originated and nothing else

More precisely, with the ^$ as-path access list, you will only be sending out routes originated in your own sub-AS (not just by the local router).

Johnny, note that this may not be entirely what you want, as you may want to advertise routes from other sub-ASes to external peers, and the ^$ as-path access-list would prevent you from advertising router from any other sub-AS except your own. In that case, the regular expression to match any route originated in any sub-AS would be:

^(\([0-9 ]+\))?$

Pay attention for the whitespace between the digit 9 and the closing bracket. To break the expression down, the presence of a sequence of conferedation ASes is indicated by the parentheses whose special meaning must be cancelled by the backslash character. Inside the parentheses, there is a sequence of one or more AS numbers represented by the [0-9 ]+ expression. The AS_PATH may also be empty which is why the entire expression is enclosed into a group ()? saying that its innards may be present at most once. Writing the ? character can be tricky - you first need to press the combination and after that, you can type in the ? character which will remain present on the command line as a literal.

Best regards,

Peter

[Aninda Chatterjee]

Hi Peter,

More precisely, with the ^$ as-path access list, you will only be sending out routes originated in your own sub-AS (not just by the local router).

Ah yes, I should have stated it like above. I used 'locally originated' too freely. Good catch, Peter. Any prefix within the local routers sub-AS would not be filtered since the AS path for those would be null.

^(\([0-9 ]+\))?$
Pay attention for the whitespace between the digit 9 and the closing bracket. To break the expression down, the presence of a sequence of conferedation ASes is indicated by the parentheses whose special meaning must be cancelled by the backslash character. Inside the parentheses, there is a sequence of one or more AS numbers represented by the [0-9 ]+ expression. The AS_PATH may also be empty which is why the entire expression is enclosed into a group ()? saying that its innards may be present at most once. Writing the ? character can be tricky - you first need to press the  combination and after that, you can type in the ? character which will remain present on the command line as a literal.

Wonderfully described, Peter. I missed out the enclosure of the entire expression into the ()? group in my thinking and I'm assuming without that, we'd only be advertising what we learned from our sub-AS peers, correct?

The use of regular expressions in BGP is amazing. I'm still not used to it and struggle quite a bit, but it is such a powerful tool for filtering.

Regards,

Aninda

[Peter Paluch]

Hello Aninda,

I missed out the enclosure of the entire expression into the ()? group  in my thinking and I'm assuming without that, we'd only be advertising  what we learned from our sub-AS peers, correct? 

Yes, that is correct.

The use of regular expressions in BGP is amazing. I'm still not used to  it and struggle quite a bit, but it is such a powerful tool for  filtering. 

Absolutely - regular expressions are immensely powerful. They are essentially formal languages describing sets of strings acceptable by the grammar defined in a particular regular expression. This gives them their unusual strength - the ability to define a grammar for sentences whose high-level structure we already know or expect to see.

Best regards,

Peter

[Aninda Chatterjee]

Also, Peter, I'm quite sure you are well aware and use the show ip bgp regex command quite actively, but I wanted to mention that here in case someone is unaware of this command.

The show ip bgp regex is probably the best tool to understand the result of an AS-path filter. So, instead of actually applying the filter and then seeing the result, you can use this command to check the result of the filter and modify as need be before you implement it in production.

Taking the same example as my earlier post, let's see what the ^$ gives us on R2:

R2#show ip bgp regexp ^$

BGP table version is 4, local router ID is 2.2.2.2

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

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

This means that if I apply a regular expression of ^$ the only thing that matches is the 2.2.2.2/32 prefix which is what we expected.

Now let's use the expression that Peter came up with:

R2#show ip bgp regexp ^(\([0-9 ]+\))?$

BGP table version is 4, local router ID is 2.2.2.2

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

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*> 3.3.3.3/32       192.168.2.3              0    100      0 (3) i

The result of this filter would be both locally originated prefixes and any prefix that is learned via a sub-AS peer. Which was exactly what the result needed to be.

Now that we are sure of the result of the filter, it is pretty safe to implement it into production. My recommendation would be to ALWAYS use this command and make sure that the filter works as you think it should before proceeding to implement this into a live environment.

P.S. Peter, how is the whitespace between 9 and the closing bracket making a difference? I did not understand that. Could you explain more, please?

Regards,

Aninda

[Peter Paluch]

Hi Aninda,

Another very nice article by you!

P.S. Peter, how is the whitespace between 9 and the closing bracket  making a difference? I did not understand that. Could you explain more,  please?

The whitespace stands for the separator between sub-AS numbers. If it was not present, the expression \([0-9]+\) would constitute just a single sub-AS number, such as (3). Adding the whitespace to the set in the brackets allows you to match multiple sub-AS numbers in the AS_CONFED_SEQUENCE segment of the AS_PATH, such as (1 2 3). This would be necessary if you wanted to match all networks that came from somewhere inside your confederation and may thus have multiple sub-AS numbers present in their AS_PATH.

Best regards,

Peter

[Aninda Chatterjee]

Thanks Peter. Makes perfect sense now!

Regards,

Aninda

[Peter Paluch]

Hello Aninda,

Thank you!

Just to share with you a curiosity I've stumbled across: when I originally put down the regexp, it used the underscore instead of whitespace, i.e.: ^(\([0-9_]+\))?$ . According to the BGP Case Studies, the underscore character stands for, among others, a space. It is also often used to designate inter-AS separator in the examples. I also use it routinely. Funnily enough, it did not work for me here for the AS_CONFED_SEQUENCE elements. I simply was not matching the strings. I wonder if I did something something wrong or if the BGP regex engine in IOS has a limitation here.

Best regards,

Peter

[Aninda Chatterjee]

Hi Peter,

What output did you get when you used the underscore? I just tried it and it gave me the same output as earlier (when I had the space between 9 and the closing bracket). Perhaps I need to test this some more.

Could you provide a sample output what you saw?

Regards,

Aninda

[Peter Paluch]

Hi Aninda,

It would give me an empty output if the AS_PATH contained at least two or more elements, i.e. it would match (1) but it would not match (1 2), for example.

Best regards,

Peter

[Aninda Chatterjee]

Hi Peter,

You're right - I went ahead and configured R4 to be a part of the confedertion so now R2 sees:

R2#show ip bgp regexp ^(\([0-9 ]+\))?$

BGP table version is 4, local router ID is 2.2.2.2

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

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*> 3.3.3.3/32       192.168.2.3              0    100      0 (3) i

*  4.4.4.4/32       192.168.3.4              0    100      0 (3 4) i

With the underscore instead of the whitespace however, it seems to be selecting only prefixes which have a single sub-AS within brackets (ignore the fact that 4.4.4.4/32 is not best - the next hop is inaccessible because I don't have the next-hop-self on R3 )

R2#show ip bgp regexp ^(\([0-9_]+\))?$

BGP table version is 4, local router ID is 2.2.2.2

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

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*> 3.3.3.3/32       192.168.2.3              0    100      0 (3) i

I'll have a look at this Peter and see if I can find out the reason for this. Thanks for pointing this out.

Regards,

Aninda

[Peter Paluch]

Hi Aninda,

Thank you very much for confirming the behavior!

I have noticed that the underscore used in brackets, e.g. [0-9_], does not appear to work even with plain AS_PATH attributes (i.e. without confederations - just AS_SEQUENCE, not AS_CONFED_SEQUENCE). I am wondering if perhaps the fact that the underscore expands to a set of characters is not at the bottom of this issue - perhaps this expansion is not working properly when the underscore is put inside a bracket that itself constitutes a set of characters.

If we wanted to use the underscore anyway, we'd need to modify the regexp as follows:

^(\(([0-9]+_)+\))?$

This one is becoming slightly unreadable, though

Best regards,

Peter

[johnnylingo]

Sorry for being slow to reply, but just wanted to thank everyone for the contributions on this thread, especially Peter for pointing out the need for parathesis when doing regex. I hadn't considered that at all!