BIRD 2.0.2 VPNv4 RD Filter

[Ondrej Zajicek]

On Thu, Oct 25, 2018 at 05:55:45AM +0000, Hombach, Tobias wrote:
> Hi,
> 
> Is it possible in current BIRD 2.0.2 release to filter (more dynamically) VPNv4 prefixes based on RD? In our scenario, we want to use BIRD to connect large VPNv4 landscapes and want to filter prefixes based on RD on Route Server ingress.

Hi

Seems like we forgot to add support for RD sets. I just fixed that in
current int-new GIT branch, you can try that:

https://gitlab.labs.nic.cz/labs/bird/commit/83715aa82966020100afa35f15d1ca56cadf6d10


> I can extract RD from VPNv4 prefix with special operator '.rd'
> 
> filter vpnv4_ingress
> {
> if (net.rd = 5000:200) then accept;
> reject;
> }
> 
> This is working but I don't want 1x if-statement per RD as we have lots of RD's. Any ranges or wildcards are not allowed. Something like '5000:200..299' does not work. Or '5000:*' also does not work. I tried to create a constant for a VPNv4 prefix to use it in a filter:

With the RD sets, this should work:

  if (net.rd ~ [10:20, 100000:100..100000:200]) ...

Sorry, no wildcards yet.


> Also not allowed. Creating a constant of data type 'vpnrd' did not work.

The data type is 'rd', variable of that type 


 Then I tried to handle the output of 'net.rd' as string to maybe use shell pattern.
> 
> filter vpnv4_ingress
> string test;
> {
>   test = "5000:20?";
>   if net.rd ~ test then accept;
>   reject;
> }
> 
> Results in error: "<ERR> filters, line 90: ~ applied on unknown type pair". Changing the if-statement to 'if net.rd = test then accept;' does work w/o error but all prefixes are filtered. The shell pattern is not working. I guess the output of 'net.rd' is not a string. I also cannot save 'net.rd' output in a string variable.

Yes, this is expected, cannot match directly RD (or other objects) to string, and RD is not a string, so the second statement is false.


> Last but not least. I have found a undocumented function 'format()'. This function seems to return a string and shell patterns work. I guess the function should not be used in production so I just used it for testing.

Well, it is just undocumented, should work without crash. Will fix that.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20181025/3c2e47fb/attachment.sig>