Just put this on a live system, and it behaves as intended (so far). Special meaning of _ would certainly have to be added to the check, i guess, but that needs further delving into bgp-regex syntax.

@tfiebig Could you add a PR?

Honestly? Rather not. Even though i have been testing this extensively, there needs to be some discussion re: old-config-impact (+some testing); Similarly, _ideally_ this would not just go for standard python regex, but instead try to figure out what frr _acutally_ uses. So, while a poc, i think this needs a bit more work.

The patch is btw here, in case anyone want to use it as inspiration: https://github.com/vyos/vyos-1x/compare/current...ichdasich:vyos-1x:bgp_large_community_validator_new

Well, someone should make a PR so that we can discuss the code. :)

Looking at the code in FRR, it just expands '_' to the full match '(^|[,{}()]|$)' and sends that whole match off to regexec().

Adding this to my TODO-list:

• Simple form validation can itself be done by regex, such as` '^(\d+:){2}\d+$'`, we get a standard match
• Something that doesn't match should be a valid regular expression (we can expand _ before checking), we get an extended match

There's no simple wrappers for POSIX regex in Python, so either a re.compile() would be "close enough" or it could be filtered through something that does use POSIX regex, like an echo 'test' | grep -E 'expr' - and look for exit code 2.

IMO just using re.compile() should be fine - you'd have to really try hard to find something that passes and wouldn't just be a dud non-matching POSIX regex.

Looking at it, T5816 already attempted to fix this and is probably better for users - doesn't give the full flexibility of regex and doesn't handle '_' at all, but does have a strict format expectation.

I've bumped into large community regexes being odd with older versions, T5816 would cover my use cases without a problem.

I've issued a PR for this at https://github.com/vyos/vyos-1x/pull/4482, attempting to address a few things T5816 missed.