Mailing List Archive

You didn't say what the problem you are trying to fix is.? Its is a real
problem that happens (like a router failing) or a theoretical problem
like 'we must makesure if this ISP fails, we can still connect`

It is very easy to replace one point of failure (an ISP) with another
point of failure (one router), but along the way convert a simple
network into a complicated network.? So think really carefully.


On 26/11/2021 09:06, pieter@towel42.nl wrote:
>
>
> As a primary issue, is something like scenario 1 (two routers
> connected via two ports/paths) possible using OSPF (or another routing
> protocol)?

This is the kind of thing you can do with OSPF.

The downside is that OSPF is not instant at detecting a failed link.? If
the ethernet link drops, then you know it is dead.? If an IPsec pseudo
wire just stops forwarding, then it could be a few minutes before a
problem is detected.

Equally, if they are really just plain ethernet cables you could use
static routes, and just detect that the link is down??? But I suspect
you actually have a lot of IPsec tunnel between devices.

Frr (fork of quagga) does have a proposed feature to allow BFD on static
routes.?? It isn't ready yet, see
https://github.com/FRRouting/frr/pull/7101??? But something like this
would allow just a simple routing table, and a detection that a link is
up from end to end.

BFD is bidirectional forwarding detection - a way to check 2 IP hosts
have connectivity between each other and detect a failure really quickly.

I think you could also use BGP + BFD just a easily as using OSPF.


*****

You could also have a look at https://www.tinc-vpn.org/????? It's a VPN
but also has routing engine, and so is able to keep up a mesh if a node
fails.


> As a secondary issue, is something like scenario 2 (two routers
> connected via one port on one side, two ports on the other side, two
> paths) possible using OSPF (or another routing protocol)?


I'm not sure what you mean here.? The connections could come into a
router via a network switch?? So you get 2 connections on 2 vlans into
the same port.? That is ok.? But the switch is something else to break,
and so leaves you a single point of failure.






_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Hello Tim,

Thank you for your answer, and my apologies for not making my problem
more clear. I was trying to build some understanding of the underlying
issues before diving into the actual scenarios we're looking at.

I design crypto products that, for reasons of security, use static
routing to route IP traffic over their secure associations (SAs) to
their destination. As such, they do not participate in any routing
protocols, though they will pass unicast routing protocols between
routers in the customer network. Our customers would like to know if
they can use their routers to set up fail-over scenarios over the crypto
products (and perhaps the ISPs they're connected to). The most common
scenarios are 2:2 fail-over (scenario 1) and 1:2 fail-over (scenario 2).
I've depicted those in the attached figures in simple setups.

In order to help our customers figure out their options to this regard,
we are running some simulation scenarios using Quagga. Our first setup
was using OSPF in some simple scenarios (without the crypto units). I
agree that it's very easy to create incredibly complex scenarios to rule
out SPOF issues, but we were trying to keep it simple for now.

The issues I initially encounter with OSPF (in NBMA mode) are as
follows:
1. OSPF assumes that neighbor routers are on the same subnet. I was
wondering if I could fix that using virtual links.
2. OSPF does not use a source port in its neighbor configuration. In
order to test all routes however, I would need to set up 4 OSPF
point-to-point connections (via virtual links?) in the first scenario
and 2 in the second. I'm not sure whether that's possible with OSPF or
not.

From what I can tell, BGP might support these scenarios better. Is that
correct?

I'm familiar with BFD; is this a protocol commonly supported on routers
these days such that it could be used for this purpose?

Kind regards,

Pieter Hulshoff

On Fri, Nov 26, 2021 at 6:35 AM <pieter@towel42.nl> wrote:
> I design crypto products that, for reasons of security, use static
> routing to route IP traffic over their secure associations (SAs) to
> their destination. As such, they do not participate in any routing
> protocols, though they will pass unicast routing protocols between
> routers in the customer network. Our customers would like to know if
> they can use their routers to set up fail-over scenarios over the crypto
> products (and perhaps the ISPs they're connected to).

Tunnel mode IPSec is actually a tunnel protocol (IP-IP I think? I
don't remember) on top of transport mode IPSec where the tunnel is
sort of implicit and subject to the SA definitions. If you want to use
dynamic routing, your best bet is to separate the components: use a
tunnel protocol like GRE explicitly between transport mode IPSec
endpoints. This will expose GRE virtual interfaces on the two routers
which are clean for whichever dynamic routing protocol you feel like
using.

https://tools.ietf.org/search/rfc3884 talks about something similar.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Hello William,

On 26-11-2021 18:46, William Herrin wrote:
> On Fri, Nov 26, 2021 at 6:35 AM <pieter@towel42.nl> wrote:
>> I design crypto products that, for reasons of security, use static
>> routing to route IP traffic over their secure associations (SAs) to
>> their destination. As such, they do not participate in any routing
>> protocols, though they will pass unicast routing protocols between
>> routers in the customer network. Our customers would like to know if
>> they can use their routers to set up fail-over scenarios over the crypto
>> products (and perhaps the ISPs they're connected to).
> Tunnel mode IPSec is actually a tunnel protocol (IP-IP I think? I
> don't remember) on top of transport mode IPSec where the tunnel is
> sort of implicit and subject to the SA definitions. If you want to use
> dynamic routing, your best bet is to separate the components: use a
> tunnel protocol like GRE explicitly between transport mode IPSec
> endpoints. This will expose GRE virtual interfaces on the two routers
> which are clean for whichever dynamic routing protocol you feel like
> using.


That is correct. Tunnel mode IPsec provides an IP over IP or UDP tunnel.
I had a quick look into how routers configure GRE tunnels these days,
and since they connect from source to destination IP, it's certainly an
option our customers can consider. It's certainly one we prefer from a
security perspective, but not all of our customers are willing to lose
the bandwidth necessary for the GRE overhead. Running OSPF over GRE
should solve some of the issues we're running into though.


Kind regards,


Pieter Hulshoff


_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users