==================================
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 <../aggregators/interfaces.html#adding-editing-deleting-interfaces>`__
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 <../dynamic-routing/configuring-dynamic-routing-in-bonding.html#adding-editing-deleting-filters>`__
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.
