Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-20 Thread Maria Matejka
Hello! 


>> So if you're not careful you could end up in a situation where Babel
>> maintains a loop-free forwarding graph, BGP maintains a loop-free
>> forwarding graph, but there exists a loop that goes Babel -> BGP -> Babel.
>> 
>We almost experienced such a situation as well. Bird
>always prefers Babel over BGP, unfortunately.

In BIRD, you can set the preference per route, this way you may prefer any 
route over any else.

Maria

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-20 Thread Marek Küthe
On Mon, 20 Feb 2023 16:51:52 +0100
Juliusz Chroboczek  wrote:

> > I think the answer should be that no matter how you mess with the metrics
> > babel should still remain loop-free, right?  
> 
> Both Babel and BGP should remain loop-free whatever you do.  However, when
> you redistribute routes between protocols, there's no guarantee that the
> union of the two graphs remains loop-free.
> 
> So if you're not careful you could end up in a situation where Babel
> maintains a loop-free forwarding graph, BGP maintains a loop-free
> forwarding graph, but there exists a loop that goes Babel -> BGP -> Babel.
> 
> -- Juliusz

We almost experienced such a situation as well. Bird
always prefers Babel over BGP, unfortunately.

> 
> ___
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


-- 
Marek Küthe
m...@mk16.de
er/ihm he/him


pgpMuY5mLR_2C.pgp
Description: OpenPGP digital signature
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-20 Thread Juliusz Chroboczek
> I think the answer should be that no matter how you mess with the metrics
> babel should still remain loop-free, right?

Both Babel and BGP should remain loop-free whatever you do.  However, when
you redistribute routes between protocols, there's no guarantee that the
union of the two graphs remains loop-free.

So if you're not careful you could end up in a situation where Babel
maintains a loop-free forwarding graph, BGP maintains a loop-free
forwarding graph, but there exists a loop that goes Babel -> BGP -> Babel.

-- Juliusz

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-20 Thread Juliusz Chroboczek
> Hence my question some time ago at the Mailling list if there is some
> kind of "include" statement in babeld.

You may use multiple '-c' options on the command-line to include multiple
configuration files.  There's no include statement currently, but I could
certainly add one.

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-20 Thread Juliusz Chroboczek
> I guess it would also help if babel could send some kind of metadata along
> with the routes. Like BGP communities or some such. Has this been thought
> about already?

No objection, but there are a few questions we'd need to answer first:

1. Should the metadata be mandatory or not?  Suppose that a router
   receives a route with a kind of metadata that it doesn't understand,
   should it drop the route?

2. If the route doesn't get dropped, should the metadata be transitive?
   If a router receives a route with a kind of metadata that it doesn't
   understand, should it drop the metadata, or should it reannounce the
   route with the metadata unchanged?

3. What should be the format of the metadata?  One octet of metadata kind,
   followed with opaque binary data?

4. Which kinds of metadata should be defined initially?

-- Juliusz

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-20 Thread Marek Küthe
The bird filter engine is clearly more complex and diverse. I have now
solved the problem (at least partially) with the following filters:
```
redistribute ip fd5c:3e37:2666:ea00::/56 eq 56 allow
redistribute local deny
redistribute deny

in ip fd5c:3e37:2666:ea00::/56 deny

in ip fd5c:3e37:2666::/48 le 56 allow
in ip fd5c:3e37:2666::/48 deny
in ip fd92:58b6:2b2::/48 le 48 allow
in ip fd92:58b6:2b2::/48 deny
in ip fd08:8441:e254::/48 le 64 allow
in ip fd08:8441:e254::/48 deny
in ip fd40:aa42:4f39::/48 le 64 allow
in ip fd40:aa42:4f39::/48 deny
in ip fd96:cd8b:f25d::/48 le 64 allow
in ip fd96:cd8b:f25d::/48 deny
in ip fda2:a9b0:a02b::/48 le 64 allow
in ip fda2:a9b0:a02b::/48 deny
in ip fdae:d3e4:83e4::/48 le 64 allow
in ip fdae:d3e4:83e4::/48 deny
in ip fdc2:9471:e3ba::/48 le 64 allow
in ip fdc2:9471:e3ba::/48 deny
in ip fdd2:cbf2:61bd::/48 le 64 allow
in ip fdd2:cbf2:61bd::/48 deny
in ip fdf1:1dc1:f54d::/48 le 64 allow
in ip fdf1:1dc1:f54d::/48 deny
in ip fd96:21ef:a9ba::/48 le 64 allow
in ip fd96:21ef:a9ba::/48 deny
in ip fdd4:975c:1440::/48 le 64 allow
in ip fdd4:975c:1440::/48 deny
in ip fda7:3ae7:e04d::/64 le 64 allow
in ip fda7:3ae7:e04d::/64 deny

in ip fd00::/8 le 64 ge 44 allow

in deny
```
If it is a CRXN prefix, the maxlen is checked and the prefix is
accepted or filtered accordingly. For non-CRXN prefixes it is only
checked if they are between /64 and /44. If so, they are also accepted.
The problem here is that now non-CRXN and non-dn42 routes can be
propagated and they are not filtered. The only possibility would be to
extend the babeld configuration file by 3000 lines accordingly. Hence
my question some time ago at the Mailling list if there is some kind of
"include" statement in babeld.

On Sun, 19 Feb 2023 15:53:03 +0100
Juliusz Chroboczek  wrote:

> https://mk16.de/blog/the-crxn-dn42-interconnection-is-up/
> 
> Interestingly, the two networks use overlapping prefixes, which requires
> enumerating hundreds of prefixes in their filters.  This is a case where
> BIRD's support for Babel is likely to be useful: babeld's filtering
> engine is simply not designed for large numbers of filtering rules.
> 
> -- Juliusz
> 
> ___
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


-- 
Marek Küthe
m...@mk16.de
er/ihm he/him


pgpRveKCVIwSy.pgp
Description: OpenPGP digital signature
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-20 Thread Marek Küthe
On Mon, 20 Feb 2023 01:29:40 +0100
Daniel Gröber  wrote:

> Interesting,
> 
> Did you notice this passage:
> 
> > This problem could be solved by calculating the Babel metric based on the
> > AS path length, but I am unsure if this is technically possible, on the
> > other hand this may compromise the loop-free nature of Babel. This
> > problem, but with no potential solution, also occurs with the Default
> > Route.  
> 
> I think the answer should be that no matter how you mess with the metrics
> babel should still remain loop-free, right?

The metrics thing actually works. I use the following "formula" in bird:
```
babel_metric = 70 + (2 * bgp_path.len);
```

My understanding is that it should remain loop-free as long as each
Babel hop increments the metric by at least one.

> 
> On Sun, Feb 19, 2023 at 03:53:03PM +0100, Juliusz Chroboczek wrote:
> > Interestingly, the two networks use overlapping prefixes, which requires
> > enumerating hundreds of prefixes in their filters.  This is a case where
> > BIRD's support for Babel is likely to be useful: babeld's filtering
> > engine is simply not designed for large numbers of filtering rules.  
> 
> I guess it would also help if babel could send some kind of metadata along
> with the routes. Like BGP communities or some such. Has this been thought
> about already?

That's right. This would be very practical a kind of BGP communities
for Babel. The only reason I personally prefer babeld over bird is that
babeld can calculate latency on its own with the RTT extension.

> 
> For example while debugging rtt based routing metrics I would have loved to
> be able to send along the raw RTT value along with each route :)
> 
> --Daniel
> 
> ___
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


-- 
Marek Küthe
m...@mk16.de
er/ihm he/him


pgpWbMBJgsDvC.pgp
Description: OpenPGP digital signature
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] CRXN/DN42: interconnecting overlay networks with Babel and BGP

2023-02-19 Thread Daniel Gröber
Interesting,

Did you notice this passage:

> This problem could be solved by calculating the Babel metric based on the
> AS path length, but I am unsure if this is technically possible, on the
> other hand this may compromise the loop-free nature of Babel. This
> problem, but with no potential solution, also occurs with the Default
> Route.

I think the answer should be that no matter how you mess with the metrics
babel should still remain loop-free, right?

On Sun, Feb 19, 2023 at 03:53:03PM +0100, Juliusz Chroboczek wrote:
> Interestingly, the two networks use overlapping prefixes, which requires
> enumerating hundreds of prefixes in their filters.  This is a case where
> BIRD's support for Babel is likely to be useful: babeld's filtering
> engine is simply not designed for large numbers of filtering rules.

I guess it would also help if babel could send some kind of metadata along
with the routes. Like BGP communities or some such. Has this been thought
about already?

For example while debugging rtt based routing metrics I would have loved to
be able to send along the raw RTT value along with each route :)

--Daniel

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users