Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
Hi,
Please look at these patches:
bytestring-hex-prefix.patch - syntax with "hex:" prefix
I allowed mixed colons with no-divider there, so hex:12:345678:90 is
allowed. As there is a distinguishing prefix here, this should not be
a problem.
Empty bytestrings are allowed too: "hex:"
bytestring-hex-function.patch - function-like hex("...") syntax (on
top of the other patch)
It wasn't too complex, but you might have wanted to do it some other
way. I think this should be quite good too, the only problem with it
is inability to mix "hex" symbol with hex("...") bytestrings.
I parse string in two steps. First to know the length of a binary
output. Current hex realization does the same anyway. I made a
separate function for it to reuse it for "classic" bytestrings and for
function-like syntax.
It ignores all non-alphanumeric symbols and requires that each byte
symbols go in pairs without delimiters.
I added a HEX keyword and added it to kw_sym, but this solution does
not allow to mix "hex" symbol and hex("...") bytestring in the same
config.
There probably was a mistake in nest/config.Y with missing "|" here:
"kw_sym: MIN MAX ;"
There is a "TODO" in the heading of strtobin.c, don't know what is
your policy regarding that. The code is still based on the current
BYTESTRING parser.
I also enabled TEXT literals to be multiline. Didn't know it was not
allowed already, so I think it should not break things, but allows to
be more flexible with binary strings.
On Tue, Jun 13, 2023 at 6:37 PM Ondrej Zajicek wrote:
>
> On Tue, Jun 13, 2023 at 05:34:18PM +0200, Alexander Zubkov wrote:
> > On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek wrote:
> >
> > > We agreed on keeping existing format for suffiently long hex bytestrings,
> > > using hex: prefix for bytestrings of any length, and adding hex("...") /
> > > base64("...") as ordinary expressions.
> >
> > Hi,
> >
> > So full house. :) I can try to implement it. Do you need a hand?
>
> If you implement hex: prefix, we could easily merge that. The
> hex("...") / base64("...") is not priority and would require some
> nontrivial changes to be done properly.
>
> --
> 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."
commit a0d088b49510db8f968a99b7e1a5f7f1242e199d
Author: Alexander Zubkov
Date: Tue Jun 13 22:19:28 2023 +0200
Conf: allow to provide a bytestring of any length with 'hex:' prefix
diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index 9555949d..9025a84d 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -255,12 +255,17 @@ WHITE [ \t]
return IP4;
}
-{XIGIT}{2}((:{XIGIT}{2}){15,}|({XIGIT}{2}){15,}) {
- char *s = yytext;
+({XIGIT}{2}){16,}|{XIGIT}{2}(:{XIGIT}{2}){15,}|hex:({XIGIT}{2}(:?{XIGIT}{2})*)? {
+ char *s, *sb = yytext;
size_t len = 0, i;
struct bytestring *bytes;
byte *b;
+ /* skip 'hex:' prefix */
+ if (sb[0] == 'h' && sb[1] == 'e' && sb[2] == 'x' && sb[3] == ':')
+sb += 4;
+
+ s = sb;
while (*s) {
len++;
s += 2;
@@ -271,7 +276,7 @@ WHITE [ \t]
bytes->length = len;
b = &bytes->data[0];
- s = yytext;
+ s = sb;
errno = 0;
for (i = 0; i < len; i++) {
*b = bstrtobyte16(s);
commit eead1fd2f7193bed2bbece8aeebfa04571030f6e
Author: Alexander Zubkov
Date: Wed Jun 14 00:08:23 2023 +0200
Conf: new bytestring syntax hex("..."), allow multiline strings
diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index 9025a84d..dd607380 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -256,37 +256,26 @@ WHITE [ \t]
}
({XIGIT}{2}){16,}|{XIGIT}{2}(:{XIGIT}{2}){15,}|hex:({XIGIT}{2}(:?{XIGIT}{2})*)? {
- char *s, *sb = yytext;
- size_t len = 0, i;
+ char *str = yytext;
+ size_t len;
struct bytestring *bytes;
- byte *b;
/* skip 'hex:' prefix */
- if (sb[0] == 'h' && sb[1] == 'e' && sb[2] == 'x' && sb[3] == ':')
-sb += 4;
-
- s = sb;
- while (*s) {
-len++;
-s += 2;
-if (*s == ':')
- s++;
- }
+ if (str[0] == 'h' && str[1] == 'e' && str[2] == 'x' && str[3] == ':')
+str += 4;
+
+ errno = 0;
+ len = bstrhextobin(str, 0);
+ if (errno || len == (size_t)-1)
+cf_error("Invalid hex string");
+
bytes = cfg_allocz(sizeof(*bytes) + len);
bytes->length = len;
- b = &bytes->data[0];
- s = sb;
- errno = 0;
- for (i = 0; i < len; i++) {
-*b = bstrtobyte16(s);
-if (errno == ERANGE)
- cf_error("Invalid hex string");
-b++;
-s += 2;
-if (*s == ':')
- s++;
- }
+ bstrhextobin(str, bytes->data);
+ if (errno)
+cf_error("Invalid hex string");
+
cf_lval.bs = bytes;
return BYTESTRING;
}
@@ -361,7 +350,6 @@ else: {
quoted_buffer_init();
}
-\n cf_error("Unterminated string");
<> cf_error("Unterminated string");
["] {
BEGIN(INITIAL);
@@ -370,7 +358,7 @@ else: {
return TEXT;
}
-. BUFFER_PUSH(quoted_buffer) = yytext[0];
+(.|\n) BUFFER_PUSH(quoted_buffer) = yyt
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Tue, Jun 13, 2023 at 05:34:18PM +0200, Alexander Zubkov wrote:
> On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek wrote:
>
> > We agreed on keeping existing format for suffiently long hex bytestrings,
> > using hex: prefix for bytestrings of any length, and adding hex("...") /
> > base64("...") as ordinary expressions.
>
> Hi,
>
> So full house. :) I can try to implement it. Do you need a hand?
If you implement hex: prefix, we could easily merge that. The
hex("...") / base64("...") is not priority and would require some
nontrivial changes to be done properly.
--
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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek wrote:
> On Mon, Jun 12, 2023 at 05:55:34PM +0200, Alexander Zubkov wrote:
> > BTW, if we put a string literal inside the brackets, we can mimic a
> > function call without dirty lexer/parser hacks:
> > hex("...")
> >
> > Or maybe you have already agreed on something?
>
> Hi
>
> We agreed on keeping existing format for suffiently long hex bytestrings,
> using hex: prefix for bytestrings of any length, and adding hex("...") /
> base64("...") as ordinary expressions.
>
Hi,
So full house. :) I can try to implement it. Do you need a hand?
> --
> 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."
>
Re: AdminDown is tearing down BGP session
On Sun, Jun 04, 2023 at 06:06:22PM +, Sunnat Samadov wrote: > Dear Birds, > > I am reaching out to seek assistance and guidance from the community > regarding an issue we are facing with BIRD, specifically version 2.0.11, > which we have been using in our network configuration. > > Our setup involves configuring BIRD with BGP+BFD, where BIRD initiates the > BGP session establishment. However, we have observed an unexpected behavior: > after the BIRD daemon successfully establishes the BGP connection, router > sends a BFD Admin-down message and requests a new BFD session. This action by > router leads to BIRD transitioning to a BFD down state and tearing down the > previously established BGP session. Hi Sorry for late reaction. That is BIRD 2.0.11 on both sides? -- 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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Mon, Jun 12, 2023 at 05:55:34PM +0200, Alexander Zubkov wrote:
> BTW, if we put a string literal inside the brackets, we can mimic a
> function call without dirty lexer/parser hacks:
> hex("...")
>
> Or maybe you have already agreed on something?
Hi
We agreed on keeping existing format for suffiently long hex bytestrings,
using hex: prefix for bytestrings of any length, and adding hex("...") /
base64("...") as ordinary expressions.
--
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."
Re: Different export route target for different prefixes of a same VRF
On Tue, Jun 13, 2023 at 10:47:08AM +0530, Ramanathan Selvamani wrote:
> Hi Team,
>
> I configured l3vpn in BIRD and I was able to see the routes are learnt and
> advertised based on RT.
>
> All the routes in this VRF are advertised with RT (1:11) to neighbors.
Hi
I am glad you tried this MPLS L3VPN branch, i would be interested in
your experiences and suggestions with it.
> I have a use case in which I want to apply different RT for different
> routes belonging to the same VRF.
>
> For example,
> I have the following prefixes in this VRF "vrf2".
> 101.1.1.0/24
> 103.1.1.0/24
> 105.1.1.0/24
>
> I would like to add different "export route target" as below for routes
> belong to same VRF
> 101.1.1.0/24 : export RT 1:11
> 103.1.1.0/24 : export RT 1:20
> 105.1.1.0/24 : export RT 1:30
Currently, the implicit export RT processing works by removing all RT
communitines and then adding ones specified in the export target
option.
If you want to set individual route targets, you could just keep the
export target set empty and add individual communities ex-post in vpn4
channel import filter (VRF export direction first passes through ipvX
channel export filter, then internal processing, then vpnX channel import
filter), with something like:
case (net) {
1:11 101.1.1.0/24: bgp_ext_community.add((rt, 1, 11));
1:11 103.1.1.0/24: bgp_ext_community.add((rt, 1, 20));
1:11 105.1.1.0/24: bgp_ext_community.add((rt, 1, 30));
}
(note that in vpnX import filter the route is already converted to VPNv4 NLRI,
so 'net'
is RD + prefix.
There is an alternative approach, which is not yet implemented, but there
should be an option with EC set that instead of appriori removing all
existing RTs during export, it should keep a defined subset (say [(rt, 1,
10..40)]), and then these RTs could be passed from original IP routes
from VRF.
--
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."
