Changes between Version 51 and Version 52 of OpenFlow/FOAM


Ignore:
Timestamp:
06/11/13 14:25:22 (11 years ago)
Author:
Josh Smift
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • OpenFlow/FOAM

    v51 v52  
    232232== Auto-approval ==
    233233
    234 FOAM 0.10 includes a simple analysis engine which can be used to inform auto-approval decisions. The analysis is done by default, but can be disabled if you really want to for some reason.
     234FOAM includes a simple analysis engine which can be used to inform auto-approval decisions. The analysis is done by default, but can be disabled if you really want to for some reason.
     235
     236=== Auto-approval mode ===
    235237
    236238The action taken on a newly created sliver depends on the geni.approval.approve-on-creation configuration option. It has three possible values:
     
    240242 * Mode 2, "analysis": Newly created slivers are automatically approved if they pass all the checks in the analysis engine.
    241243
    242 The default value is "0", for safety, so no slivers will be auto-approved.
    243 
    244 The rest of this section is only really relevant if you use mode 2. If you've read the rest of this section and want to do that, you can do it with foamctl:
     244The default value is "0" on new FOAM installs, so no slivers will be auto-approved.
     245
     246The analysis engine runs regardless of the geni.approval.approve-on-creation setting, with the results visible in the 'foam_pend_reason' field (visible in 'foamctl geni:show-sliver' and in the GENI AM API !SliverStatus call). If the sliver passed the checks in the analysis engine, this field will be "null"; otherwise, it will contain more information about what test it failed. (More precisely, it'll include one test that the sliver didn't pass; if it failed multiple tests, only one will be listed.)
     247
     248You can use foamctl to check your current auto-approval mode:
     249
     250{{{
     251foamctl config:get-value --key="geni.approval.approve-on-creation" --passwd-file=/etc/foam.passwd
     252}}}
     253
     254And to set it:
    245255
    246256{{{
     
    248258}}}
    249259
    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
     262We 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
     264If 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
     270In 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
     272Prior 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
     274As 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
     276By 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
     280The 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
     291In 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
     293For 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.
    271294
    272295== Sliver approval workflow ==