device. These rules are then propagated via e-bgp to peering routers.
Each user is authenticated against shibboleth. Authorization is
performed via a combination of a Shibboleth attribute and the peer
network address range that the user originates from. FoD is meant to
operate over this architecture:
device. These rules are then propagated via e-bgp to peering routers.
Each user is authenticated against shibboleth. Authorization is
performed via a combination of a Shibboleth attribute and the peer
network address range that the user originates from. FoD is meant to
operate over this architecture:
- +-----------+ +------------+ +------------+
- | FoD | NETCONF | flowspec | ebgp | router |
- | web app +----------> device +--------> |
- +-----------+ +------+-----+ +------------+
- | ebgp
- |
- +------v-----+
- | router |
- | |
- +------------+
-
+ +-----------+ +------------+ +------------+
+ | FoD | NETCONF | flowspec | ebgp | router |
+ | web app +----------> device +--------> |
+ +-----------+ +------+-----+ +------------+
+ | ebgp
+ |
+ +------v-----+
+ | router |
+ | |
+ +------------+
NETCONF is chosen as the mgmt protocol to apply rules to a single
flowspec capable device. Rules are then propagated via igbp to all
NETCONF is chosen as the mgmt protocol to apply rules to a single
flowspec capable device. Rules are then propagated via igbp to all
(via NETCONF always) to a router and then ibgp would do the rest. In
GRNET's case the flowspec capable device is an EX4200.
(via NETCONF always) to a router and then ibgp would do the rest. In
GRNET's case the flowspec capable device is an EX4200.
-with Django 1.4.x at [Flowspy documentation](http://flowspy.readthedocs.org).
-If upgrading from a previous version bear in mind the changes introduced in Django 1.4.
+with Django 1.4.x at http://flowspy.readthedocs.org.
+If upgrading from a previous version bear in mind
+the changes introduced in Django 1.4.