MP-VPN topology integration #42
Comments
Adding and removing POPs and sites from a VPN appear to work correctly to the point of pushing flows. MAC learning is partially operational, but pushing the flows for unicast data forwarding doesn't quite work yet due to a last set of dependencies on the topo builder, which I'm working on removing.
|
Note: I'm doing work on this issue in the bmah-mpvpn-topology branch. Will merge this to master after the work is done and tested. |
MAC learning and unicast forwarding both work. At this point all information on POPs comes from topology objects, not from the old topology builder.
|
As I write this, POP information no longer depends on the topo builder. We also need to remove some link-finding dependencies on the TopologyBuilder as well. These are roughly in topology.py in the functions linkednode, getlinks, and parselink (and their consumers). Probably the right approach here is to re-implement these functions in places that need them, rather than modify the original function definitions. It appears that all of these functions are in hostctl.py. Related to this is the fact that the site descriptors (which record where each site physically attaches to the backbone) is hardcoded in vpn.py. This information should really come from the topology. I'm not sure if that's a part of this issue or should be made a separate issue. |
…e the database-backed Topology/Container objects and their contents. Towards #42. We're trying to have the MP-VPN code only depend on the Topology containers for network topology information, and not having it fumble around in the topology builder objects. Note that we could maybe stand a little cleanup in function names.
|
Got all of the bmah-mpvpn-topology branch merged back to master and tested. |
|
After some consultation with @jmacauley we have decided to put the site descriptor work as a separate issue, which I have opened as #88. All other work for this issue is believed to be complete, so moving to the Done pipeline. |
The MP-VPN code should use the database-backed topology objects, rather than pulling network topology information from the topology builder (which currently only supports a hard-coded topology).
Note that this will require some API changes, since the interfaces for topology objects and topology builder objects are (by design) not the same.
The text was updated successfully, but these errors were encountered: