HNA-filter or multiple instances

[Bastian Rosner]

Hello,

in Berlin, we have BGP-routers in datacenters with multiple
network-interfaces. These nodes speak BGP to the outside world while
some interfaces are directly connected to our WiFi-mesh via OLSR.
For reasons of simplicity and to use fat-pipes as shortcuts wherever
possible, we decided to also use OLSR as interior routing protocol to
interconnect our BGP-servers and their view of the meshi via
tunnel-interfaces.

Now we are facing issues with HNAs that are only useful for our
BGP-routers and not for the rest of the city-wide mesh. For example,
public-IPs that should only be used for connections from the internet
are now announced inside the mesh.

Is there any way to define HNA for specific interfaces? Or some way of
filtering incoming HNA so it won't get redistributed?

If above approach should not be possible, what about multiple instances
of OLSRd for different interfaces?

Might OLSRd2 be useful and stable enough for the purpose of IGP?
FYI, we don't redistribute BGP into OLSR or vice versa.

Kind regards,
Bastian Rosner

[Saverio Proto]

Hello,

at Ninux we have a similar setup, you will find interesting reading this:
http://nnx.me/routingarchitecture

for the IGP peerings we also use tunnel interfaces, because most
routers are not bgp speakers.
We used tinc-vpn in switch mode. All BGP speakers participate to this
VPN, so they all have one tunnel interface that sees all the other BGP
speakers on the same LAN. All IGP peerings are done on this LAN.

would this design fix your problem ?

take your time to fully read the document I linked above, that
explains our design.

bye

Saverio

Post by Bastian Rosner
Hello,
in Berlin, we have BGP-routers in datacenters with multiple
network-interfaces. These nodes speak BGP to the outside world while
some interfaces are directly connected to our WiFi-mesh via OLSR.
For reasons of simplicity and to use fat-pipes as shortcuts wherever
possible, we decided to also use OLSR as interior routing protocol to
interconnect our BGP-servers and their view of the meshi via
tunnel-interfaces.
Now we are facing issues with HNAs that are only useful for our
BGP-routers and not for the rest of the city-wide mesh. For example,
public-IPs that should only be used for connections from the internet
are now announced inside the mesh.
Is there any way to define HNA for specific interfaces? Or some way of
filtering incoming HNA so it won't get redistributed?
If above approach should not be possible, what about multiple instances
of OLSRd for different interfaces?
Might OLSRd2 be useful and stable enough for the purpose of IGP?
FYI, we don't redistribute BGP into OLSR or vice versa.
Kind regards,
Bastian Rosner
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users

[Henning Rogge]

Post by Bastian Rosner
Hello,

Hi,

Post by Bastian Rosner
in Berlin, we have BGP-routers in datacenters with multiple
network-interfaces. These nodes speak BGP to the outside world while
some interfaces are directly connected to our WiFi-mesh via OLSR.
For reasons of simplicity and to use fat-pipes as shortcuts wherever
possible, we decided to also use OLSR as interior routing protocol to
interconnect our BGP-servers and their view of the meshi via
tunnel-interfaces.
Now we are facing issues with HNAs that are only useful for our
BGP-routers and not for the rest of the city-wide mesh. For example,
public-IPs that should only be used for connections from the internet
are now announced inside the mesh.
Is there any way to define HNA for specific interfaces? Or some way of
filtering incoming HNA so it won't get redistributed?

I am not sure what you mean with "HNA for specific interface".

A router announcing a HNA says "I can route traffic to prefix X". All
other nodes will build a route towards this prefix, otherwise the
hop-by-hop forwarding could fail spectacularly.

Post by Bastian Rosner
If above approach should not be possible, what about multiple instances
of OLSRd for different interfaces?

If your group of BGP routers is connected directly without any
"normal" mesh node between them this could work, otherwise you break
the connection, because the intermediate mesh node will not forward
the traffic.

OLSRd2 supports multiple topologies on the same routing agent, but
even with this the intermediate node needs to be part of this
topology.

Post by Bastian Rosner
Might OLSRd2 be useful and stable enough for the purpose of IGP?

I think its reasonable stable, but I am still waiting for someone
doing the first large scale deployment.

Henning Rogge