250 | | The analysis engine performs three tests related to the sliver's flowspace: |
251 | | |
252 | | 1. If the sliver's flowspace includes IP space: That IP space must not overlap with the IP space of any already-approved slivers. |
253 | | 2. If the sliver's flowspace includes MAC addresses: Those MAC addresses must not overlap with the MAC addresses of any already-approved slivers. |
254 | | 3. If the sliver's flowspace includes ethertypes (other than IP and ARP): Those ethertypes must not overlap with the ethertypes of any already-approved slivers. |
255 | | |
256 | | For each of those tests, the result could be "pass", "fail", or "n/a" (e.g. if the sliver's flowspace doesn't include IP space, or there are no port groups defined). |
257 | | |
258 | | It also performs three tests related to datapaths, ports, and VLANs: |
259 | | |
260 | | 1. The sliver's flowspace must include at least one datapath. |
261 | | 2. The sliver's flowspace must not include more than one of the ports in any port group. |
262 | | 3. The sliver's flowspace must not include any flowspace defined by VLAN. (no 'dl_vlan') |
263 | | |
264 | | In mode 2, the sliver is automatically approved if at least one test in the first group passes, and no test fails (in either group). |
265 | | |
266 | | In practice, this implements a policy somewhat like: "Auto-approve a sliver that includes IP, MAC, or ethertype flowspace, doesn't overlap with anything else, and doesn't include more than one port in these port groups". Port groups might include things like cross-connects, or any other collection of ports where you only want a given sliver to have one port in the group. |
267 | | |
268 | | If a sliver is not auto-approved, the 'pend_reason' field (visible in 'foamctl geni:show-sliver') should explain why. (More precisely, it'll include one test that the sliver didn't pass; if it failed multiple tests, only one will be listed.) |
269 | | |
270 | | A more flexible policy is expected in future versions of FOAM. |
| 260 | === Turning on auto-approval === |
| 261 | |
| 262 | We recommend that GENI sites turn on analysis-based auto-approval. If your site's topology doesn't contain any loops, and doesn't connect to other sites in a way that could form a loop, this is generally safe to do. The FOAM aggregates in the GENI racks have analysis-based auto-approval turned on by default. |
| 263 | |
| 264 | If your topology does contain a loop, or if you connect to other sites in a way that could form a loop (e.g. you connect to two sites who also connect to each other), you can use FOAM's "port groups" feature to allow auto-approval of safe topolgies only. This can be somewhat complicated; talk to the GPO (gpo-infra@geni.net) about the details of your site, and we'll help you set it up. |
| 265 | |
| 266 | (Loops are dangerous because they enable naive experimenters to generate huge amounts of traffic easily (and accidentally), and current !OpenFlow implementations on switches generally don't isolate different experimenters' traffic from each other very well, meaning that one accident of this sort can fairly easily take down entire networks for many people.) |
| 267 | |
| 268 | === Analysis and VLANs === |
| 269 | |
| 270 | In principle, traffic in GENI is sliced by VLAN, such that each slice has one or more private VLANs that carry traffic only for that slice. In practice, the current GENI mesoscale OpenFlow network consists mainly of VLAN-hybrid switches, and thus uses a single shared VLAN (colloquially "1750", the VLAN ID number used by many (but not all) sites), where traffic is then sliced by other features, such as MAC address, ethertype, or IP subnet. The [wiki:NetworkCore GENI network core page] has more details about that. (FIXME: No it doesn't. But it really should. Or maybe there's some other page that does, or should.) |
| 271 | |
| 272 | Prior to FOAM 0.12, the analysis engine only supports VLAN-hybrid datapaths, and could not auto-approve any sliver that included a VLAN-based match (the dl_vlan match attribute). |
| 273 | |
| 274 | As of FOAM 0.12, the analysis engine also supports dl_vlan matches, and differentiates between "exclusive" VLANs, "reserved" VLANs, and "shared" VLANs. The shared mesoscale VLAN (and other VLAN-hybrid datapaths) is effectively a special case of a shared VLAN, one in which no dl_vlan attribute is specified ("dl_vlan=none" is one way to think about it). |
| 275 | |
| 276 | By default, FOAM treates each VLAN as exclusive, unless a FOAM admin has added the VLAN to the list of reserved or shared VLANs. (A VLAN can be on both lists, although there's not really any reason to do that; but if you want to change a VLAN from one to the other, for example, you need to both remove it from the old list and add it to the new one.) |
| 277 | |
| 278 | === Analysis checks === |
| 279 | |
| 280 | The analysis engine performs the following checks: |
| 281 | |
| 282 | 1. If any port groups are defined, the request must include at most one of the ports in each port group. |
| 283 | 2. The request must not include any VLANs on the reserved list. |
| 284 | 3. If the request includes any exclusive VLANs: Those VLANs must not overlap with the VLANs of any already-approved slivers. |
| 285 | 4. If the request (a) includes any shared VLANs; and/or (b) includes any matches with no dl_vlan attribute; then the sliver's other matches must pass at least one of the following additional tests, and not fail any of them: |
| 286 | a. If the request includes matches based on IP space: That IP space must not overlap with the IP space matches of any already-approved slivers. |
| 287 | b. If the request includes matches based on MAC addresses: Those MAC addresses must not overlap with the MAC address matches of any already-approved slivers. |
| 288 | c. If the request includes matches based on ethertypes (other than IP and ARP): Those ethertypes must not overlap with the ethertype matches of any already-approved slivers. |
| 289 | For each of those tests, the result could be "pass", "fail", or "n/a" (e.g. if the request doesn't include IP space). |
| 290 | |
| 291 | In that last set of tests, overlap is only considered within the context of a VLAN (or the "none" VLAN). For example, if you have three shared VLANs, and an already-approved sliver matches 172.16.0.0/16 in one shared VLAN, another sliver which matches 172.16.0.0/16 in a different shared VLAN will not be considered to overlap with the first sliver. |
| 292 | |
| 293 | For slivers with only exclusive VLANs, if the request includes any '''other''' match criteria, those criteria will appear in the resulting !FlowVisor flowspace rules; but they're entirely irrelevant to auto-approval for exclusive VLANs, which only considers whether the VLAN overlaps with an already-approved sliver. Experimenters are encouraged not to include any other match criteria in slivers with exclusive VLANs. |