5

I need to verify that the following regex will match against my criteria, which is:

  • Deny any prefixes beginning with 0:
  • Deny any prefixes beginning with 65000:
  • Deny any prefixes beginning with 0:65000
  • Deny any prefixes beginning with 65000:65000
  • Permit any prefixes with any communities tagged
  • Permit any prefixes with no communities tagged

The platform is Quagga.

Here is my expanded community-list:

ip community-list expanded ANY-COMMUNITIES deny ^(0:.*)_(.*)_+$
ip community-list expanded ANY-COMMUNITIES deny ^(65000:.*)_(.*)_+$
ip community-list expanded ANY-COMMUNITIES deny ^(0:65000)_(.*)_+$
ip community-list expanded ANY-COMMUNITIES deny ^(65000:65000)_(.*)_+$
ip community-list expanded ANY-COMMUNITIES permit ^(.*)_+$
ip community-list expanded ANY-COMMUNITIES permit ^$

Will this cover what I'm after? Is there a better way?

4
  • Since there are a number of platforms using a Cisco-like config structure it's useful to specify which routing platform you're refering to.
    – Teun Vink
    Jun 6, 2013 at 7:13
  • I've edited my question and noted that the platform is Quagga but the question is about the regex itself, which is syntactically fairly similar (if not almost identical) across the majority of platforms. Jun 6, 2013 at 7:24
  • @JohnJensen, ping me on IM and I might be able to help... Jun 7, 2013 at 10:11
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 5, 2021 at 19:12

1 Answer 1

3

You don't need to do it so complex way as there is no implied $, so this should suffice:

ip community-list expanded ANY-COMMUNITIES deny ^0:.*_
ip community-list expanded ANY-COMMUNITIES deny ^65000:.*_
ip community-list expanded ANY-COMMUNITIES permit .*

But this probably is not even doing what you want to do, are you really interested in the order? I don't think BGP enforces any particular ordering in communities, RFC1997 just allows manipulation without specifying order. And Cisco seems to order communities in numerical order in presentation (neighbor sends me community 1:42 3:42, I add 2:42 and communities shown are '1:42 2:42 3:42' instead of what you maybe expect '1:42 3:42 2:42'.
That is, your denying of community 65000 in the beginning probably does not work. If you explain your application, maybe better solution can be found.

When it comes to communities in different platform, what @Teun implied is that they are quite different. Juniper had brilliant idea to use ASN as atom in their as-path regexp, normally atom is character (or byte, if you don't support UTF8). Juniper solution is clearly superior solution, if you think about character classes, say you want to match private ASN in JunOS, simple as [64512-65534]. If atom is normal character, like in IOS and Quagga, it's much more awkward.

5
  • Hi @ytti - thanks for the answer. I'll have to double check but I'm pretty sure .* doesn't give me what I want. And you're right, RFC1997 doesn't enforce sequence order and that's up to the implementation. And yes, "ASN as an atom" is a JunOS requirement for AS path regexp, but this is community-list regexp. :-) Jun 6, 2013 at 15:21
  • .* will match to any community which has 0 or more atoms, so it'll cover routes with any or no communities. If you'd want simplest possible regexp to match routes with any community, it would be .+
    – ytti
    Jun 6, 2013 at 15:25
  • The regex itself isn't in question, it's more to do with Quagga or how it is interpreting the regex (I think). Trust me, .* was the first thing I tried when I wanted to match for anything. It didn't work. The community list I originally posted has been working well in my application for some time, I just wanted a chance to have others poke holes in it before I put a stamp on it. Jun 6, 2013 at 15:35
  • Odd. Someone I know tested on 0.99.10-1lenny2 where .* showed both routes with and without communities.
    – ytti
    Jun 6, 2013 at 15:48
  • Nope, not odd - I just tested and it would appear as though it does work (running Quagga 0.99.22 source build). I wonder why I felt I had to use ^(.*)_+$... Will give your suggested regex a shot and report back. Jun 6, 2013 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.