NLR Framenet Documentation




FrameNet Dynamic VLAN Services/Sherpa FAQ

 

General Questions




Q: What’s the Difference Between Sherpa and the NLR Dynamic VLAN Service?
"Sherpa" is the Global Research NOC's name for a guided, secure, interactive dynamic circuit configuration tool.   The NLR Dynamic VLAN Service uses Sherpa to allow authorized users in the NLR community to provision, modify, enable, and disable dedicated or non-dedicated VLANs on FrameNet in real time, without requiring intervention from the NLR NOC.
Q: Can I try it out?

Yes.  A demonstration version ofthe Dynamic VLAN Service using Sherpa is available here (username: sherpademo password: nationwide). It will allow you to see exactly how the service and tool work on FrameNet without configuring the actual network or requiring accounts.

Q: What do I do if I’m having trouble using it?

Existing users of the Dynamic VLAN Service should contact the NLR NOC (noc@nlr.net) with any questions or problems.
How does account setup work?
Those interested in using the Dynamic VLAN Service can contact NLR Experiments Support Services (ESS) at ess@nlr.net.  The ESS will work with you to make sure DVS fits your needs, and shepherd the administrative and financial process. 


Once this is complete, the NLR NOC (noc@nlr.net) will work with you to setup the appropriate accounts and access needed for your project.

 

Administrative/Financial Questions


Q: What does it Cost?  How will I be billed?

The Dynamic VLAN Service costs and billing models are still being finalized.  If you have questions about possible costs please contact ess@nlr.net


System Architecture Questions


 

Q: How does the Sherpa tool work?

Sherpa is built on top of a number of custom GRNOC database and database-aware tools that track FrameNet resources, what's already been committed on them, how they interconnect with each other, and the graphics tools to display the information.


For example:

  1. When you log into Sherpa, the GRNOC database knows what resources you're entitled to access, for instance the interface(s) that you're connected to.
  2. When you specify a VLAN ID to use, the database knows whether it's available or not.
  3. When you select which segments of the network your VLAN should traverse, the database knows where they go and how to interconnect them, and shows you on a map of the network where they will go.
  4. If you request a certain amount of 'dedicated' prioritized bandwidth for your VLAN, the database knows whether it's available on those segments and how much it would cost.
  5. When you commit your DVS VLAN request, the application securely logs into each applicable switch and configures the VLAN there, tests it end-to-end, and adds it to the database associated with your project, with the relevant business and technical information needed for administration and operational support. If a problem is discovered during verification or configuration, the configuration is undone and you are notified.
  6. Normally the VLAN is ready for use within seconds.
  7. You may also disable or modify the VLAN later; the database will show you all of the already-configured resources you have access to.
Q: How does Sherpa configure the network devices?

Sherpa uses a set of protected utilities to configure NLR FrameNet devices. These configurations are performed over SSH and are limited to actions conforming to NLR VLAN configuration standards.

Q: How does Sherpa verify the service when configuring?

After configuration Sherpa will add temporary addresses to the VLAN interfaces and perform ping tests to verify connectivity. If failure occurs, the configuration is undone.

 

Q: How was the interface built?

Sherpa combines the Altas network tool for visualization of the network with the Yahoo YUI widget set to create a highly interactive point and click provisioning tool.

Q: What is a “group” in the context of Sherpa?

Sherpa has a concept of a work group. Multiple people can belong to each work group.  These groups are used to define permissions on what sorts of resources can be used. For instance each workgroup has a defined set of interfaces upon which it is allowed to terminate VLANs.  Typically, this means that any set of resources that has the same set of provisioners would be grouped as a work group.

Q: Does it support inter-domain circuits?

Sherpa is designed for intra-domain networks, operating under a single operational entity.  It depends heavily on information in the Global Research NOC’s Network Database, and is not intended for heterogeneous networks.

 

While it would be possible architecturally for Sherpa to configure inter-domain circuits, this is not a current feature of the tool.

 

It should be possible, however, for other inter-domain provisioning projects to make requests of the NLR Dynamic VLAN Service using the Sherpa programmatic API.

Q: Is there a Programmatic Interface?

Yes.  See this for detailed information on the Sherpa API interface.

 

Software Features


Q: If a feature is not currently supported, how do I request it?

NLR is committed to providing the features that would be most useful to its members.  If there is a feature you’d like to see in DVS (or any other service or tool), you can send your request to noc@nlr.net.  New features are chosen based on the level of interest in the membership, so your feedback is appreciated.

Q: Is Multipoint Supported?

Multipoint is not currently an option in the Dynamic VLAN Service.

Q: Can I use it to schedule a start or end time for a VLAN?

VLAN scheduling will be supported in an upcoming release .

Q: Can I set aside VLAN numbers ahead of time? 

Preconfigured VLAN blocks will be supported in an upcoming release.

Q: Does it support Spanning Tree for redundancy?

DVS allows users to fully configure VLANs with Spanning Tree for added redundancy.  Primary and Backup Root Bridge selection is supported for this as well.

Spanning Tree for DVS, as with all FrameNet VLANs, is provided using fast per VLAN Spanning Tree (PVST+)

Q: How much bandwidth can I dedicate?

Bandwidth can be dedicated in 100M increments, from 100M to 10G.  However, actual bandwidth availability on the network will dictate what can be configured at any one time.  Real-time available bandwidth is dependent on the bandwidth set aside by all static and dynamic VLAN users, and not by actual traffic.  NLR does not overprovision dedicated bandwidth on any backbone links, to prevent congestion.

For instance, if only 1G is available on a link, the Sherpa interface will prevent a user from configuring any more than what is currently available.  Real-time available bandwidth is shown during the configuration process to give immediate information to users.

Q: How is my bandwidth protected?

Bandwidth is protected using strict quality of service at the edge.  All traffic below the dedicated limit is marked as priority traffic.  All traffic exceeding this profile (and all non-dedicated traffic) is marked as best effort.

Dedicated traffic is never over-provisioned, so that there will never be more than 10G of high priority traffic on a link.  

 

Security Questions


Q: Can I provision VLANs between any ports in FrameNet?

When a new group is created, ports related to that project are set aside for configuration by the group.  Only those predefined edge ports, along with all of the FrameNet backbone ports will be configurable by that group.  Other ports will not be configurable without being assigned to that group by the NLR NOC.

Q: What credentials do I need to login?

GRNOC Web Login is used for authentication.




NLR FrameNet Technical Guide

NLR FrameNet Connection Information and Recommendations

Summary of Connection

Members get a 1 GE interface on their local NLR FrameNet 6509.

General Physical Connectivity Information

Cross-connect Responsibility - The member is responsible for physical connectivity to the NLR 6509 switch port with the appropriate fiber.

Optics - NLR will supply the optics for the memberÕs connections. Intermediate range (LX/LH) optics are the standard type used. Short range (SX) or Extended range (ZX) optics can be made available, if needed, but may incur addition cost and deployment delays.

General Protocol Information

The National Lambda Rail FrameNet is intended to be a large Ethernet switch fabric, and as such we ask connectors to do their best to ensure its stability. All services will have the following attributes:

MTU - The MTU on all edge interfaces on the Layer 2 network is set to 9192 to prevent dropping transported IP packets with a 9000 byte MTU.

STP Packets - Members should prevent frames related to any Spanning Tree Protocols (STP) such as BPDUs from being sent to the NLR. BPDUs will be discarded at the ingress port, though we ask that members refrain from sending them. Spanning tree is enabled by default for all VLANs across the NLR network.

Broadcast Packets - Members should refrain from sending unnecessary broadcast packets to the NLR switch fabric. We ask that you make sure that your routing devices that are connected are configured to not forward broadcast packets. For example, on a Cisco, please insure Ôno ip directed broadcastÕ is configured on your interface that is connected to NLR. We may rate limit broadcast traffic to preserve the integrity of the network. Broadcast packets will be limited to 50% of line rate.

VLANs - VLAN ids can be negotiated with NLR to avoid conflicts. By default, all VLANs will be sent with 802.1q tags.

Service Specific Information

National Exchange Fabric Birthright Service

Service Description - The NEF is a single VLAN and broadcast domain that extends to every member who elects to participate in the service. It allows members to arrange bi-lateral peerings with any of the other participants in this birthright service.

Physical Connectivity - Every member gets a single 1GigE interface on their local NLR FrameNet node for use of the NEF service.

VLAN Info - The NEF VLAN ID is 505.

IP addresses - IP addresses used for these peerings will be assigned by NLR. By default 1 /32 host address will be assigned to each member to use as a peering address. If a member requires more addresses, NLR will provide them. Each switch in the network will have an IP address in the NEF VLAN that members can use for basic connectivity testing. A list of these can be found at <URL>.

Point-to-point, Dedicated Bandwidth Service

Service Description - Members may order private VLANs to connect 2 different locations together, with dedicated bandwidth, for a circuit-like service.

Bandwidth Minimums/Maximums - There is a 100Mbps minimum bandwidth requirement for the Point-to-pointed dedicated layer2 service. The maximum bandwidth for this service is 10Gbps.

Bandwidth Increments - When requesting a Point-to-Point dedicated Layer2 service from NLR, members should specify the amount of bandwidth required, in 100Mbps increments

QoS - by default, any traffic a members sends in excess of the amount dedicated to their service (burst traffic), will be set to best effort. If a member desires, NLR can also configure their VLAN to immediately drop this traffic instead.

Path - In addition to choosing the endpoints and bandwidth, members may also dictate the path through the NLR FrameNet for their point-to-point service. If no path is chosen, NLR will chose the shortest and/or the least congested path through the network.

Point-to-multipoint, Best Effort Service

Service Description - Members may order private VLANs to more than 2 different locations together, for a circuit-like service.

Bandwidth -Traffic on these VLANs will be carried through the network on a best effort basis.

Tunneled VLANs - In addition to a standard dot1q encapsulated interface, NLR will also support Q-in-Q. This allows a single point to point or point to multipoint circuit to pass many VLANs without having to negotiate them NLR. Enabling this on a port will prevent any other service from being available on that port.




NLR National Exchange Fabric Address Assignments

NLR National Exchange Fabric users as of 17 Jan 2008

 

NLR National Exchange Fabric users  as of 17 Jan 2008--brs

216.24.182.0/23        L2 National Exchange Fabric - Vlan 505
216.24.182.0/27        NLR-NEF Internal hosts (6500 framenet switches)
  216.24.182.1    chic-nef.layer2.nlr.net
  216.24.182.2    clev-nef.layer2.nlr.net
  216.24.182.3    pitt-nef.layer2.nlr.net
  216.24.182.4    newy-nef.layer2.nlr.net
  216.24.182.5    wash-nef.layer2.nlr.net
  216.24.182.6    rale-nef.layer2.nlr.net
  216.24.182.7    atla-nef.layer2.nlr.net
  216.24.182.8    jack-nef.layer2.nlr.net
  216.24.182.9    bato-nef.layer2.nlr.net
  216.24.182.10    hous-nef.layer2.nlr.net
  216.24.182.11    tuls-nef.layer2.nlr.net
  216.24.182.12    kans-nef.layer2.nlr.net
  216.24.182.13    denv-nef.layer2.nlr.net
  216.24.182.14    albu-nef.layer2.nlr.net
  216.24.182.15    elpa-nef.layer2.nlr.net
  216.24.182.16    losa-nef.layer2.nlr.net
  216.24.182.17    sunn-nef.layer2.nlr.net
  216.24.182.18    seat-nef.layer2.nlr.net
216.24.182.32    Cornell-nef
216.24.182.33    Matp-nef
216.24.182.34    NCLR-nef (North Carolina)
216.24.182.35    SLR-nef
216.24.182.36    psc-nef-1 (PSC gigapop
216.24.182.37    psc-nef-2 (PSC-Penn State
216.24.182.38    psc-nef-3 (PSC-Univ of Pittsburgh
216.24.182.39    psc-nef-4 (PSC proper)
216.24.182.40    UNM-nef
216.24.182.41    UCAR-nef
216.24.182.42    Onenet-NEF
216.24.182.43    pnw-nef
216.24.182.44    loni-nef
216.24.182.45    CENIC-UCLA-nef
216.24.182.46    NYU-nef
216.24.182.47    LEARN-hous-nef
216.24.182.48    LEARN-elpa-nef
216.24.182.49    Case-nef (through clev)
216.24.182.50    RENCI (North Carolina)

216.24.182.64/28    NEF-CIC--up to 16 members
  216.24.182.64    CIC-U of Chicago
  216.24.182.65    CIC-U of Illinois at Chicago
  216.24.182.66    CIC-Indiana U
  216.24.182.67    CIC-U of Iowa
  216.24.182.68    CIC-U of Michigan
  216.24.182.69    CIC-Michigan State U
  216.24.182.70    CIC-U of Minnesota
  216.24.182.71    CIC-Northwestern U
  216.24.182.72    CIC-Ohio State U
  216.24.182.73    CIC-Purdue U
  216.24.182.74    CIC-U of Wisconsin
  216.24.182.75-79    unallocated

# start in 216.24.183...
216.24.183.128    CENIC-Sunn-nef
216.24.183.129    CENIC-Losa-nef
216.24.183.132/30    CENIC "Digital California" hosts
  216.24.183.132    cenic-dc1-nef
  216.24.183.133    cenic-dc2-nef
  216.24.183.134    cenic-dc3-nef
  216.24.183.135    cenic-dc4-nef
216.24.183.192    FLR-nef




Sherpa API Information


The Sherpa client is based upon 10 cosign protected web services.  These services take inputs as standard CGI parameters and return JSON formatted output.   Almost all services require the net and wg parameters to define the security context. 

VLAN editing is currently implemented by removing a VLAN and then re-adding it, which is to say edits are disruptive to packet forwarding.

 

Generally the planning services are used to figure out the design of the vlan, then the provisioning services are user to either add or remove a vlan.

 

Planning Services:

This section contains 8 services used to plan out the provisioning request.

getActivationHistory.cgi

Provides a history of Sherpa provisioning for circuits within the provided administrative network and workgroup.  Additionally, supports a search pattern to restrict history output to a keyword search that is applied to the circuit’s name, description and vlan tag.

Required CGI Parameters:

  • net
    • admin network identifier, always 1 for NLR for instance
  • wg
    • work group id to operate under, getWorkgroups.cgi used to resolve this


Optional CGI Parameters:

  • search
 
getAvailableTag.cgi

Provides the next available unused VLAN tag.  If optional tag is provided then will let you know if that tag is available or the nearst greater value.

Required CGI Parameters:

  • net

Optional CGI parameters:

  • tag
    • desired vlan tag number.
 
getEntities.cgi

Provides a list of organizational entities.  Each VLAN needs to be associated with an Entity.


Required CGI Parameters:

  • net
  • wg

 

getExistingVlans.cgi

Provides list of VLANs that belong to a given work group.

 

Required CGI Parameters:

  • net
  • wg

 

Optional CGI Parameters:

  • search

 

 

getInterfaces.cgi

Returns a list of interfaces on the specified node that the specified workgroup is allowed to use as VLAN endpoints.

Required CGI Parameters:

  • net
  • wg
  • short_name
    • FQDN for the router/switch of interest.

 

Optional CGI Parameters:

  • search

 

getTrunks.cgi

Provides a list of trunks upon which the specified VLAN is currently provisioned over.

Required CGI Parameters:

  • net
  • ck_id
    • this VLANs circuit ID

 

getVlanHistory.cgi

Provides the provisioning history for a given VLAN. Accepts either VLAN Tag or ckg_id.

Required CGI Parameters:

  • net
  • wg
  • tag or ckt_id

 

getVlanSPF.cgi

Based on 2 defined endpoints, this service will provide the shortest available path considering available bandwidth.  

Required CGI Parameters:

  • net
  • reserved_bw
    • bytes per second integer to represent amount of bandwidth to reserve.
  • node_a
    • FQDN hostname for the first node/endpoint
  • node_z
    • FQDN hostname for the second node/endpoint

 

getWorkgroups.cgi

Provides the list of Sherpa workgroups that the user is allowed to access.

Required CGI Parameters:

  • net

 

isTagAvailable.cgi

Checks to see if a defined VLAN tag is available.  

Required CGI Parameters:

  • net
  • tag

 

Provisioning Services:

 

provisionVlan.cgi

This service is used to provision a VLAN on the network.  Typically all data used to build this request is gathered via the planning aids.

Required CGI Parameters:

  • net
  • wg
  • tag
    • VLAN Tag
  • reserved_bw
    • reserved bandwidth in bytes per second
  • description
    • human friendly description
  • node_a
    • the host name for endpoint a device
  • node_z
    • the host name for the endpoint z device
  • int_a
    • the endpoint a interface
  • int_z
    • the endpoint z interface
  • node_rb
    • node name for switch to act as Spanning Tree Root Bridge
  • path
    • comma delimited list of trunks to activate the VLAN upon
  • entity_id
    • entity id for the assocated entity

 

removeVlan.cgi

Service used to remove a vlan from the network.  

Required CGI Parameters:

  • net
  • wg
  • ckt_id

 

Optional CGI Parameters:

  • no_writemem
    • this tells all the switches to not save the config, if you are editing a vlan, setting this on the removal will save 10 seconds of down time, because we will only save the config after we do the final edit.