Changes between Version 20 and Version 21 of OpenFlow/CampusTopology
- Timestamp:
- 03/28/12 21:28:23 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
OpenFlow/CampusTopology
v20 v21 19 19 = Operations = 20 20 21 Once you have this set up, experimenters will be able to create !OpenFlow slivers to use in their experiments. Before they can actually use those slivers, though, you'll need to approve them (or "opt them in", in Expedient's terminology). Here are some things to think about when doing that:21 Once you have this set up, experimenters will be able to create !OpenFlow slivers to use in their experiments. Before they can actually use those slivers, though, you'll need to approve them (or configure FOAM to approve them automatically). Here are some things to think about when doing that: 22 22 23 23 * Does the sliver seem to accomplish what the experimenter is trying to accomplish? For example, if they tell you that they want traffic to and from a particular IP subnet for your MyPLC plnodes, you should confirm that this is actually what they've requested. If you aren't familiar with what the experimenter is trying to do, you should probably ask them for more information about their experiment, since it's easier to evaluate their request if you know what their intended effect is. … … 83 83 VLAN 1750 is an !OpenFlow-controlled VLAN, shared by multiple experimenters via the FlowVisor. In addition to whatever other !OpenFlow programming each experimenter wishes to do with their sliver, the experimenter also uses !OpenFlow to direct outbound traffic to a physical port; the port they choose controls which inter-campus VLAN will be used for the outbound traffic. For example, an experiment that wanted to send inter-campus traffic via VLAN 3715 would use !OpenFlow to send that traffic out port 3. 84 84 85 Note that since VLAN 1750 is cross-connected to multiple intercampus VLANs, care must be taken to ensure that e.g. broadcast packets aren't flooded out to both VLAN 3715 and 3716. The simplest way to prevent this is for experimenters to never reserve a topology that includes more than one cross-connect port, and for campus Expedientadmins to carefully check experimenter requests to make sure that they don't. If a particular experimenter wanted to do a particular experiment that did use multiple inter-campus VLANs, they would need to expressly confirm that they understand the risks and are confident that they won't accidentally flood broadcast traffic, ideally by testing and demonstrating their experiment in a staging environment first.85 Note that since VLAN 1750 is cross-connected to multiple intercampus VLANs, care must be taken to ensure that e.g. broadcast packets aren't flooded out to both VLAN 3715 and 3716. The simplest way to prevent this is for experimenters to never reserve a topology that includes more than one cross-connect port, and for campus FOAM admins to carefully check experimenter requests to make sure that they don't. If a particular experimenter wanted to do a particular experiment that did use multiple inter-campus VLANs, they would need to expressly confirm that they understand the risks and are confident that they won't accidentally flood broadcast traffic, ideally by testing and demonstrating their experiment in a staging environment first. 86 86 87 87 Additional VLANs can be set up for physical translation, but they use two ports per VLAN, and they need to be physically connected by a campus network admin... So this can be done if needed, but should generally be minimized.