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.

Q: How can I get an account?

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.

  • 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.
  • When you specify a VLAN ID to use, the system knows whether it's available or not.
  • When you select which segments of the network your VLAN should traverse, the system knows where they go and how to interconnect them, and shows you on a map of the network where they will go.
  • If you request a certain amount of 'dedicated' prioritized bandwidth for your VLAN, the system knows whether it's available on those segments and how much it would cost.
  • When you commit your DVS VLAN request, the system will first examine the request as a pretest to ensure it will result in a usable VLAN, then it securely logs into each applicable switch and performs a second set of tests, then configures the VLAN, 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.
  • Normally the VLAN is ready for use within seconds.
  • 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 “work 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 support will be added to Sherpa in a future release.  Currently DVS supports multipoint VLANs manually through the NLR NOC.

Q: Is Q in Q supported?

The Dynamic VLAN Service and Sherpa will support Q n Q in a future release.

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

Yes, you can schedule any provisioning action to happen at a future date.

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

Yes, Sherpa now supports VLAN reservations.

Q: Does it support Spanning Tree for redundancy?

DVS allows users to fully configure VLANs with Spanning Tree for added redundancy.  Primary 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:  Is there a way to edit VLANs without causing packet loss?

Sometimes, and the UI will let you know either way.  Sherpa now has a feature called non-disruptive editing. In the past Sherpa would completely remove a VLAN then readd it on edit, now it examines the live config determining the set of actions required to make the existing config become the requested config.  If the set of actions does not involve anything disruptive then edit will be non-disruptive.  As an example, anything that would trigger a Spanning Tree recalculation would be considered disruptive.

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 will rate limit broadcast traffic to preserve the integrity of the network to a small percentage of the line rate of the interface.

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

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

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.ne
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 2 cosign protected web services.  These services take inputs as standard CGI parameters and return JSON formatted output.

Generally the planning service is used to figure out the design of the vlan, then the provisioning service is used to request a vlan be created, edited, or removed now or sometime in the future.

To facilitate programatic access we provide a client side perl library which allows you to interact with our cosign protected webservices directly.

In addition, we provide a few demo perl scripts.


 

GRNOC::Sherpa::Planning

 

Description


  Sherpa Planning Service
 

Location


  https://sherpa.grnoc.iu.edu/service/planning.cgi
 

Methods

  get_available_vlan_id
  get_entities
  get_interfaces
  get_shortest_path
  get_trunks
  get_vlan_path
  get_vlan_root_bridge
  get_vlan_schedule
  get_vlans
  get_workgroups
  is_vlan_id_available
 
 

get_available_vlan_id

Output Type


  text/plain

Input Parameters:
 

  Name: net
  Pattern: ^(\d+)$
  Required: Yes

  Description: The administrative network identifier


  Name: vlan_id
  Pattern: ^(\d+)$
  Required: No
  Description: optional vlan id/tag, if this is provided we check this specific tag or return the closest next avail.

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier
 

Description: 

  Returns a vlan id that is available for use
 

get_entities

Output Type

  text/plain


Input Parameters:

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:
  Returns the list of entities that can be assign to a vlan by users in the specified workgroup
 

get_interfaces

Output Type

  text/plain

Input Parameters:

  Name: node_name
  Pattern: ^((\w+\.?)+)$
  Required: Yes
  Description: the node with interfaces you want to know about

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:


  Returns the list interfaces on a node upon which a workgroup is allowed to set vlan endpoints
 

get_shortest_path

Output Type

  text/plain

Input Parameters:

  Name: node_z
  Pattern: ^((\w+\.?)+)$
  Required: Yes
  Description: the other endpoint node eg \"chic.layer2.nlr.net\"
 

  Name: node_a
  Pattern: ^((\w+\.?)+)$
  Required: Yes
  Description: one of the endpoint nodes eg \"denv.layer2.nlr.net\"

  Name: reserved_bandwidth
  Pattern: ^(\d+)$
  Required: Yes
  Description: amount of available bandwidth to check for on each trunk

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier
 

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  Returns the shortest available path between node a and z. Checks for sufficient bandwidth.
 

get_trunks

Output Type

  text/plain

Input Parameters:

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  Returns the list of trunks available for use by the wg
 

get_vlan_path

Output Type

  text/plain

Input Parameters:

  Name: ckt_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: the vlan's ckt id

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  Returns the set of trunks the vlan currently traverses
 

get_vlan_root_bridge

Output Type

  text/plain

Input Parameters:

  Name: ckt_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: the vlan's ckt id

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  Returns the specified root bridge (not the current acting)
 

get_vlan_schedule

Output Type

  text/plain

Input Parameters:

  Name: ckt_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: database ckt_id

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier 

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  Returns the pending scheduled events for the specified vlan
 

get_vlans

Output Type

  text/plain

Input Parameters:

  Name: search
  Pattern: ^(\w+)$
  Required: No
  Description: Optional search routine to search for vlans by name, description, or vlan id content

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  provides the set of vlans a user in the specified workgroup is allowed to manipulate
 

get_workgroups

Output Type

  text/plain

Input Parameters:

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

Description:

  Returns the list of workgroups the remote user is allowed to use
 

is_vlan_id_available

Output Type

  text/plain

Input Parameters:

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan tag/id to check

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  tests if the vlan tag is available for use

 


 

GRNOC::Sherpa::Provisioning

 

Description

 
  Sherpa VLAN Provisioning

Location

 
  https://sherpa.grnoc.iu.edu/service/provisioning.cgi

Methods

  add_reservation
  edit_vlan
  get_reservations
  get_status
  is_edit_intrusive
  provision_vlan
  remove_reservation
  remove_scheduled_edit
  remove_vlan
  schedule_add
  schedule_edit
  schedule_remove
 
 

add_reservation

Output Type

  text/plain

Input Parameters:

  Name: description
  Pattern: ^((\w+|\||\s+|:|\#+|\-|\=)+)$
  Required: Yes
  Description: description of why these tags are reserved (for your use)

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id2
  Pattern: ^(\d+)$
  Required: No
  Description: second tag, used when reserving a range of tag

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: first vlan tag

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  reserves one or more vlan tags
 

edit_vlan

Output Type

  text/plain

Input Parameters:

  Name: root_bridge
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the node you want to be the root of the vlan spanning tree

  Name: node_z
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the Z end node name

  Name: int_a
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the A end interface name

  Name: node_a
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the A end node name

  Name: path
  Pattern: ^(((\w+-\w+-\w+-\w+-\d+)\s*)+)$
  Required: Yes
  Description: comma separated list trunk ckts upon which this vlan should ride

  Name: reserved_bandwidth
  Pattern: ^(\d+)$
  Required: Yes
  Description: amount of bandwidth to reserve in bits per second

  Name: description
  Pattern: ^((\w+|\||\s+|:|\#+|\-|\=)+)$
  Required: Yes
  Description: vlan description

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan id aka tag

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

  Name: int_z
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the Z end interface name

  Name: entity_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: associated entity

  Name: request_id

  Pattern: ^(\d+)$

  Required: Yes
  Description: integer id for tracking request

Description:

  modify an existing vlan
 

get_reservations

Output Type

  text/plain

Input Parameters:

  Name: search
  Pattern: ^(\w+)$
  Required: No
  Description: optional search pattern

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  Returns the list reserved_vlans
 

get_status

Output Type

  text/plain

Input Parameters:

  Name: request_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: id used at time of provisioning

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan tag for this vlan

  Name: wg
  Pattern: ^(\d+)$

  Required: Yes
  Description: The workgroup identifier

Description:

  checks the provisioning status of a vlan
 

is_edit_intrusive

Output Type

text/plain

Input Parameters:

  Name: root_bridge
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the node you want to be the root of the vlan spanning tree

  Name: node_z
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the Z end node name

  Name: int_a
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the A end interface name

  Name: node_a
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the A end node name

  Name: path
  Pattern: ^(((\w+-\w+-\w+-\w+-\d+)\s*)+)$
  Required: Yes
  Description: comma separated list trunk ckts upon which this vlan should ride

  Name: reserved_bandwidth
  Pattern: ^(\d+)$
  Required: Yes
  Description: amount of bandwidth to reserve in bits per second
 

  Name: description
  Pattern: ^((\w+|\||\s+|:|\#+|\-|\=)+)$
  Required: Yes
  Description: vlan description

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan id aka tag

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

  Name: int_z
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the Z end interface name

  Name: entity_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: associated entity

Description:

  test proposed changed to see if they will interrupt packet forwarding
 

provision_vlan

Output Type

  text/plain

Input Parameters:

  Name: root_bridge
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the node you want to be the root of the vlan spanning tree
 

  Name: node_z
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the Z end node name

  Name: int_a
  Pattern: ^(\w+(\d+\/?:?)+)$
  Required: Yes
  Description: the A end interface name 

  Name: node_a
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the A end node name
 

  Name: path
  Pattern: ^(((\w+-\w+-\w+-\w+-\d+)\s*)+)$
  Required: Yes
  Description: comma separated list trunk ckts upon which this vlan should ride

  Name: reserved_bandwidth
  Pattern: ^(\d+)$
  Required: Yes
  Description: amount of bandwidth to reserve in bits per second
 

  Name: description
  Pattern: ^((\w+|\||\s+|:|\#+|\-|\=)+)$
  Required: Yes
  Description: vlan description

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan id aka tag

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

  Name: int_z
  Pattern: ^(\w+(\d+\/?:?)+)$
  Required: Yes
  Description: the Z end interface name

  Name: entity_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: associated entity

  Name: decom_date
  Pattern: ^(\d+)$
  Required: No
  Description: Optional time this vlan should be removed, in unix epoch

  Name: request_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: integer id used to reference this request
 

Description:

  creates a vlan on the network
 

remove_reservation

Output Type

  text/plain

Input Parameters:

  Name: net
  Pattern: ^(\d+)$
  Required: Yes

  Description: The administrative network identifier
 

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan tag

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  removes the specified reservation
 

remove_scheduled_edit

Output Type

  text/plain

Input Parameters:

  Name: sched_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: schedule record id

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  removes the specified edit from the scheduler queue
 

remove_vlan

Output Type

  text/plain

Input Parameters:

  Name: request_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: request tracking id

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan_id aka tag you want to remove

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  removes the specified vlan from the network

schedule_add

Output Type

  text/plain

Input Parameters:

  Name: activation_date
  Pattern: ^(\d+)$
  Required: Yes
  Description: time this modification should become active, in unix epoch

  Name: root_bridge
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the node you want to be the root of the vlan spanning tree

  Name: node_z
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the Z end node name

  Name: int_a
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the A end interface name

  Name: node_a
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the A end node name

  Name: path
  Pattern: ^(((\w+-\w+-\w+-\w+-\d+)\s*)+)$
  Required: Yes
  Description: comma separated list trunk ckts upon which this vlan should ride

  Name: reserved_bandwidth
  Pattern: ^(\d+)$
  Required: Yes
  Description: amount of bandwidth to reserve in bits per second

  Name: description
  Pattern: ^((\w+|\||\s+|:|\#+|\-|\=)+)$
  Required: Yes
  Description: vlan description

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan id aka tag

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier
 

  Name: int_z
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the Z end interface name
 

  Name: entity_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: associated entity

  Name: decom_date
  Pattern: ^(\d+)$
  Required: No
  Description: Optional time this vlan should be removed, in unix epoch

Description:
 

  add a new vlan some time in the future
 

schedule_edit

Output Type

  text/plain

Input Parameters:
 

  Name: activation_date
  Pattern: ^(\d+)$
  Required: Yes
  Description: time this modification should become active, in unix epoch

  Name: root_bridge
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes

  Description: the node you want to be the root of the vlan spanning tree

  Name: node_z
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the Z end node name

  Name: int_a
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the A end interface name

  Name: node_a
  Pattern: ^((\w+\.)*(\w*))$
  Required: Yes
  Description: the A end node name

  Name: path
  Pattern: ^(((\w+-\w+-\w+-\w+-\d+)\s*)+)$
  Required: Yes
  Description: comma separated list trunk ckts upon which this vlan should ride

  Name: reserved_bandwidth
  Pattern: ^(\d+)$
  Required: Yes
  Description: amount of bandwidth to reserve in bits per second

  Name: description
  Pattern: ^((\w+|\||\s+|:|\#+|\-|\=)+)$
  Required: Yes
  Description: vlan description

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan id aka tag

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

  Name: int_z
  Pattern: ^((\w|-)+(\d+\/?:?)+)$
  Required: Yes
  Description: the Z end interface name

  Name: entity_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: associated entity

Description:

  modify an existing vlan some time in the future
 

schedule_remove

Output Type

  text/plain

Input Parameters:

  Name: decom_date
  Pattern: ^(\d+)$
  Required: Yes
  Description: time this vlan should be removed, in unix epoch

  Name: net
  Pattern: ^(\d+)$
  Required: Yes
  Description: The administrative network identifier

  Name: vlan_id
  Pattern: ^(\d+)$
  Required: Yes
  Description: vlan_id aka tag you want to remove

  Name: wg
  Pattern: ^(\d+)$
  Required: Yes
  Description: The workgroup identifier

Description:

  removes the vlan from the network at a later time






Programatic Access to Sherpa

Sherpa has a set of Cosign protected web services which can be programatically accessed using the GRNOC::WebService::Client perl library.

You can get the perl client library here:

GRNOC-WebService-Client-0.03.tar.gz

 


Example of use of the client library

 

#!/usr/bin/perl 
#--------------------------------------------------------------------
#----- GRNOC Sherpa Demo Client
#-----
#----- Copyright(C) 2007 The Trustees of Indiana University
#--------------------------------------------------------------------
#----- $HeadURL: svn+ssh://svn.grnoc.iu.edu/grnoc/sherpa/trunk/client/sherpaHelpExample.pl $
#----- $Id: sherpaHelpExample.pl 5493 2009-08-31 19:37:16Z ebalas $
#-----
#----- Quck and dirty script to illustrate how to interact with cosign
#----- protected Sherpa Web Service using the GRNOC::WebService::Client
#----- library
#---------------------------------------------------------------------

use strict;
use Data::Dumper;
use Term::ReadKey;
use GRNOC::WebService::Client;

sub main {
#--- get credentials
print "Username: ";
my $username = <STDIN>;
print "Password: ";
ReadMode('noecho');
my $password = <STDIN>;
ReadMode('normal');
chop($username);
chop($password);
print "\n";


#===== Planning Service ======================================================

my $svc = GRNOC::WebService::Client->new(
url => "https://sherpa.grnoc.iu.edu/service-beta/planning.cgi",
uid => $username,
passwd => $password,
debug => 0,
);

if(!defined $svc){
exit;
}

#--- get list of available methods
my $res= $svc->help();
print "Available Methods:\n";
if(!defined $res){
print "Error:\n";
print Dumper($svc->get_error());
}else{
print Dumper($res);
}

#-- get help for specific method
my $res= $svc->help(method_name => 'get_trunks');
if(!defined $res){
print Dumper($svc->get_error());
}else{
print Dumper($res);
}


#--- call get trunks
my $res= $svc->get_trunks(net => 1, wg => 1);
if(!defined $res){
print Dumper($svc->get_error());
}else{
print Dumper($res);
}

#--- lets look at the set of active vlans we have access to
my $res= $svc->get_vlans(net => 1, wg => 1);
if(!defined $res){
print Dumper($svc->get_error());
}else{
print Dumper($res);
}


#===== Provisioning Service ==================================================
my $svc = GRNOC::WebService::Client->new(
url => "https://sherpa.grnoc.iu.edu/service-beta/provisioning.cgi",
uid => $username,
passwd => $password,
debug => 0,
);

#--- get list of available methods
my $res= $svc->help();
print "Available Methods:\n";
if(!defined $res){
print "Error:\n";
print Dumper($svc->get_error());
}else{
print Dumper($res);
}

#-- get help for specific method
my $res= $svc->help(method_name => 'provision_vlan');
if(!defined $res){
print Dumper($svc->get_error());
}else{
print Dumper($res);
}


}


main();