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?

  • 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 '13 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. – John Jensen Jun 6 '13 at 7:24
  • @JohnJensen, ping me on IM and I might be able to help... – Mike Pennington Jun 7 '13 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 provide and accept your own answer. – Ron Maupin Aug 8 '17 at 9:40
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.

| improve this answer | |
  • 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. :-) – John Jensen Jun 6 '13 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 '13 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. – John Jensen Jun 6 '13 at 15:35
  • Odd. Someone I know tested on 0.99.10-1lenny2 where .* showed both routes with and without communities. – ytti Jun 6 '13 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. – John Jensen Jun 6 '13 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.