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: santi...@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."
signature.asc
Description: PGP signature
