=========
Arp-2-BGP
=========

Copyright (c) 2011 Nikhef. All rights reserved.
Author: Oscar Koeroo <okoeroo (at) nikhef (dot) nl>
BSD Licence


Prerequisites
=============
The script is intended to run as a cronjob on any Arista Networks 7k-series
switch running EOS 4.5 and higher. The script is developed using Python 2.7,
and works on the Arista provided Python 2.6 (comes with EOS 4.7). The testing
has been done on an Arista 7148SX with EOS 4.7. The intended platform is a
newer model (currently unlisted) running EOS 4.7.


Synopsis
========
arp-2-bgp.py [config file]


Installation
============
Install the script (and configuration file) in the /persist directory on the
switch and configure a crontab in the bash shell as the root user to run this
script every 5 minutes.


Description
===========
Based on Arp information announce routes to a particular host using BGP.


Summary
=======
This script will read the arp table output to collect the connected IP
addresses to the switch. This information needs to be made available to another
(layer-3) switch using BGP. This feature is makes it possible to use multiple
switches to implement a layer-2 network, while each of them connecting to
another (set of) switches, based on layer-3 routing.

This solution makes it possible to re-route traffic over another switch in the
layer-2 domain to the neighbouring switch based on its layer-3 link. The
net-result will be an aggregation possibility of saturating both Layer-3 links
by the traffic of either layer-2 connected switches. See ascii-art picture
below::


    |-------|                 ---------
    | sw 1  |------Layer 3----|  sw 3 |
    |-------|                 ---------
        |                        /
     Layer-2                    /
        |                      /
    |-------|                 /
    | sw 2  |------Layer 3---/
    |-------|



Innerworking
============
The script will read the output of the command "show ip arp" from the switch
commandline interface and the output of the "show run | include network". All
the IP addresses in the arp-table will be parsed with the information on which
link and Vlan they reside. The current BGP state will be filtered on the
entries that match the /32 subnet mask exclusively, all the other entries are
ignored.

The second level of filtered is based on the contents of the configuration
file. The configuration file has [includes] and [excludes] rules based on
vlans, interfaces and the combination of a particular Vlan on an interface.

If a Vlan or interfaces is configured in the [includes] using the options
"vlans" or "interfaces", the script will consider these entries from the Arp
table to be added to the BGP configuration. The "vlan_on_interface" works
similar to the previously mentioned, with the difference that the combination
of a particular vlan on a specific interface needs to match.

Similarly to how the "[includes]" work, the options in the "[excludes]" section
will explicitly ignore the Arp table entries.

In the section "[defaults]" the "selection" option can be set to "add" or
"ignore"/"remove" entries. If there is no explicit include or exclude rule
defined for an Arp table entry, this setting will either add or filter the
entry.

In the last stage the matching of the filtered Arp table entries will be
performed against the currently set /32 masked BGP entries. If an /32 exists in
the BGP table that is not in the filtered Arp table, the entry will be removed.
If an IP address from the filtered Arp table does not exist in the BGP table,
the entry will be added to the BGP table. If the /32 exists in the BGP table,
and does in the filtered Arp table: nothing will happen due to the equilibrium. 


Background information
======================
For questions and/or background information you can email me or others from the
Physics Data Prosessing group at Nikhef for more detail on our HPC/HTC
Cloud-ready infrastructure. 


Acknowledgements
================
The BofH for letting me play with this hardware.
Floor Terra for some code cleanups and the first setup.py file.