AN-005 Using MPLS circuits as legs¶
Note
While this document references MPLS frequently, that is just a common case. Any private network segments can be solved in the same method.
It can be desirable to use MPLS circuits as legs on bonders, but we need a solution to get those MPLS circuits to connect to an aggregator’s public IP address in the same manner as other legs.
The solution provided here makes a few assumptions that are stated here
The aggregator has an interface to the MPLS network
The aggregator’s public IP is not behind NAT
Adding a route through dynamic routing to the MPLS network is possible
Let us look at an aggregator that has 2 interfaces, an eth0 with a public IP
203.0.113.1/24 and an eth1 on the MPLS network with an IP
10.100.100.1/24. On the aggregator record on the management server the
aggregator will have the IP configured as 203.0.113.1 and that is the IP any
legs defined on bonds connecting to this aggregator will try and connect to. We
can also
define a new ethernet interface
for eth1, with the 10.100.100.1/24 IP defined as an IP of this interface
to begin the integration with the MPLS network.
In this example there is a basic OSPF setup for dynamic routing on the MPLS network that we will utilize on the aggregator to get a route for the public IP of the aggregator made available through the MPLS network.
We will begin by
adding a filter
to make sure that we will only be exporting a single IP into the MPLS network to
not add anything beyond what is strictly needed to get the edge devices able to
connect using their MPLS circuits. This filter will be setup with 2 rules, the
first with a match for the network of 203.0.113.1/32 with an action of
Accept, and the second rule simply having an action of Reject so that
only the aggregator’s public IP is allowed.
Note
It is important to note that the filters and networks in the protocols are
for single network addresses with a /32 prefix length and not the entire
network to limit what is exposed into the MPLS network.
Next we will make an OSPF protocol. It is important to set IPv4 export to the filter that was just defined, and optionally you can filter IPv4 import networks if you know which IPs will end up being used as legs for an import filter. The rest of the OSPF protocol depends on the settings of the OSPF in the MPLS network, but ensure that the interface for the MPLS network is chosen.
Next we need to ensure that the aggregator IP actually gets advertised, to do so
we will add a static protocol with the aggregator IP as an interface route. In
this example the route will look like having a network of 10.87.100.51/32, a
destination of Interface and an interface of eth0.
With these protocols and filters in place, the OSPF should connect and any legs on MPLS circuits on this aggregator should now be able to connect.
Downsides¶
Routes for the MPLS network will be installed on the aggregator and be routable to by any tunnels on the aggregator, although the return path likely won’t work. This can be mitigated by adding more filters if you know which IPs the legs are going to have so that only those routes are imported on the aggregator.