Network Description

From Grid5000
Jump to: navigation, search

Contents

Purpose

  • Describe Grid'5000 network and interconnection equipments (see Schema_Backbone.png and Rennes:Network);
  • For each equipment, provide a reasonable amount of details (bandwidth, linecard models, rate, port channels, vlans, routes, etc.);
  • No dynamic data available, only static description.
  • All the description of a given network equipment is returned in a hash object. You can then parse the returned hash with your favorite programming language to retrieve the information your are looking for.


Network Description in Reference API

Network description is available inside reference API at:

 reference-repository/generators/input/sites/<site>/net-links/<equipment>.yaml
  • Each network equipment is described by one .yaml file
  • Equipments used in administration network only are not described


Network Description Attributes

The description of a network equipment contains the following information (see also example below):

  • Equipment name (same as .yaml filename). A site's primary router must be called gw-<site>
  • model: Model name (used by other tools to know how to speak to the equipment)
  • weathermap: Weathermap related information
    • use_cacti: "no": To disable cacti device creation
  • kind: The type of the equipment that can be connected to a port.
    • router
    • switch
    • virtual: Equipment on which we have no information - e.g. renater equipment.
  • site: Grid5000 equipment's site, or "renater"
  • snmp_community: Read Only SNMP community name (should always be "public" in G5K)
  • vlan: The list of vlans. It is mandatory to describe the administrative vlan with an IP address.
    • #: Vlan number
    • administrative: yes: The vlan used to connect to the switch for administration
    • addresses: List of IP addresses configured on this vlan
      • I.P.: The first IP is the address used to the switch for administration
  • linecards: List of line cards
    • #: Linecard number
    • naming_pattern: How linecards and ports are identified by switch OS. (%LINECARD% is replaced by linecard number, %PORT% by port number, %LINECARD:A% is replaced by linecard letter, see example)
    • rate: Speed in bit/s
    • ports: List of ports
      • #: Port number on the linecard
      • uid: Name of the equipment connected to that port
      • port: Port on the connected equipment. Can be "ethX" (for nodes or servers), "bmv" (for administration interface, should not be used as administration network is not described) or a string identifying the linecard and port on the connected equipment
      • kind : The type of the neighbor equipment among router, switch, virtual (see above), node (a computing node) and other (an equipment which is neither a node nor a network equipment, eg. physical server)


The following information are optional (not used yet):

  • channels: What is this is not clear for me.;
  • routes static description of routes, not used yet ?


Notes

  • Each port described must be connected to another equipment. If a port is not connected to any other equipment, then its description must be left empty.
  • Since all ports on each linecard have almost the same properties (rate, naming_pattern,...), its is more convenient to set those properties on the linecard description. Then all ports will inherit those properties by default. If a port has a property which is different from the linecard's, then it should redefine that value on the port description. For example, if the rate of a port is different from one on the linecard, it should redefine the property rate on the port description. Otherwise, the only property which is mandatory on port description is the uid, unless all ports on the linecard are connected to the same neighbor.
  • In general rule, all parameters are inherited, unless redefined. The property site for example, is defined on the network equipment description. If not redefined on a port, then the neighbor on the other end on the link on that port is on the same site. Otherwise the property site should be redefined on the port description to specify the neighbor's site. Or if all neighbors on a linecard are on another site, the property site should be redefined on the linecard description.


Naming Pattern Examples

Naming pattern help to find the interface name, based on the linecard and port numbers :

  • for Gi3/2 , pattern should be "Gi%LINECARD%/%PORT%"
  • for GigabitEthernet1/0/32, pattern should be "GigabitEthernet1/%LINECARD%/%PORT%"
  • for 9:4 , pattern should be "%LINECARD%:%PORT%"
  • for D3 , pattern should be "%LINECARD:A%%PORT%"
  • for c:5 , pattern should be "%LINECARD:a%:%PORT%"
  • for Vlan550 , pattern should be "Vlan%VLANID%"
  • for v101 , pattern should be "v%VLANID%"
  • for Po201 , pattern should be "Po%CHANNELID%"
  • ...
Warning.png Warning

FIXME : If you have Te5/2 and Gi5/2, then this API will not be able to describe both interfaces since both are interface 2 on linecard 5


Example

Here is an example of a network equipment description than can be found on the network API, with comments. This example tries to cover as much cases as possible :

# File : reference-repository/examples/net-links.json
# This is how the json file on the network API would look like.
# The comments in front of properties will not be present on the API.

{
  "type": "network_equipment", # The same for all network equipments. This is used by the API generator ! To not confuse with "kind" property which is used to distinguish network equipments kinds.
  "model": "xx", # the model must start with the constructor (Cisco,HP Procurve,Foundry,...) followed by the version (3750,...). This is anyway how constructors usually describe they equipments.
  "kind": "xx", # This tells what kind of network_equipement it is (router,switch,virtual,...)
  "uid": "xx" # This equipment's uid
  "site": "xx" # This equipment's site uid
  "snmp_community": "public" # the Read-Only SNMP community. Its is "public" on all equipments since decision in PS-61.
  "vlans": {
    "1":{"addresses":[],"description":"default"}
    "100": {  # 100 is the vlan id
      "addresses": [ # vlan interface ip address, by order of priority. The first one being the primary ip address, the other one are secondary ip addr
        "172.16.68.254",  # The primary ip address
        "10.47.255.254",  # The secondary ip address
      ]
      "mac": "FF:FF:FF:FF:FE" , # The vlan interface mac address. most often, this value is the same on all vlans
      "description": "PRODUCTION" # A description for the vlan
      "administrative": yes
    }
    "naming_pattern": "Vlan%VLANID%" # The vlan interface naming pattern. So the vlan 100 is on interface "vlan100"
  }
  "routes": {
    "172.16.47.0/20": { # 172.16.47.0/20 is the destination network address
      "status": "static", # Can be "connected" or "static". "static" means this route was define by a command line on the router. 
      "via": "192.168.4.14", # gateway of this network, if status == static. Of course this gateway must be join-able by one of the network equipment vlan interface.
    }
    "172.16.95.0/20": { # 172.16.95.0/20 is the destination network address
      "status": "connected", # Can be "connected" or "static". "connected" means the destination network correspond to one of our local interfaces (vlan interface). This type of route is usually added automatically by the network equipment's Operating System when an IP address is added to a local interface.
    }
  }
  "channels": {
    "200": [  # 200 is the port channel id
      {
        "linecard": "2", # the linecard number
        "port": "7", # the port number on the linecard
      },
      {
        "linecard": "3", # the linecard number
        "port": "7", # the port number on the linecard
      }
    ]
    "naming_pattern": "Po%CHANNELID%"; # The naming pattern of all Channel Ports. The port channel 200 is on interface "Po200".
    "190": [  # 190 is the port channel id
      {
        "linecard": "1", # the linecard number
        "port": "8", # the port number on the linecard
      },
      {
        "linecard": "2", # the linecard number
        "port": "8", # the port number on the linecard
      }
      {
        "linecard": "3", # the linecard number
        "port": "8", # the port number on the linecard
      }
    ]
  }
  "linecards": [
    {},
    {
      "rate": "1000000000", # The rate of all interfaces on this linecard. unless overriden within port description
      "naming_pattern" : "Gi%LINECARD%/%PORT%", # the naming pattern of all interfaces on this linecard. unless overriden within port description
      "kind": "node", # The kind of all neighbors on all interfaces on this linecard. unless overriden within port description
      "ports":[
        {
          "uid": "<cluster>-<node_id>", # The neighbor uid on this link. This should be used to identify links aggregations (not necessary channels, just link aggregation).
        },
        {
          "uid": "server_uid", # The neighbor uid on this link.
          "kind": "server", # Redefinition of the neighbor's kind, according to the one already defined on the linecard description.
        }
      ]
    },
    {
      "rate": "1G", 
      "naming_pattern" : "Gi%LINECARD%/%PORT%", 
      "kind": "node", 
      "ports":[
        {
          "uid": "netgdx-1", 
          "port": "eth0", # The neighbor's port name on this link. This is mainly useful when the neighbor has many ports and is not described in the network API. Typically, "node"s and "server"s.
        },
        {
          "uid": "netgdx-1", # Second link to the node "netgdx-1"
          "port": "eth1", # The neighbor's port name on this link.
        },
        {
          "uid": "netgdx-1", # Third link to the node "netgdx-1"
          "port": "eth2", # The neighbor's port name on this link.
        }
      ]
    },
    {
      "rate": "1000000000", 
      "naming_pattern" : "Gi%LINECARD%/%PORT%", 
      "kind": "switch", 
      "ports":[
        {
          "uid": "<cluster>-<node_id>", 
          "kind": "node", # Redefinition of the neighbor's kind
        },
        {
          "uid": "switch01",
        },
        {
          "uid": "switch01", # The second link to the switch "switch01". But nothis says it is a Port-Channel. For now it is just 2 links aggregated for "switch01". You will have to look into "channels" to find if there is a port channel on these ports. Notice that they is no need to specify the neighbor "port" on this link. In fact that that information is redundant since "switch01" should be described in the network API where they would be its links to this network equipment. So setting "port" here can even be confusing if it is coherent with the one in the "switch01" API description.
        }
      ]
    },
    {
      "rate": "10000000000", # Ha, interesting, the 10G links
      "naming_pattern" : "Te%LINECARD%/%PORT%", # The naming pattern of 10G interfaces on this linecard
      "kind": "virtual", 
      "ports":[
        {
          "uid": "renater-lille", 
          "site": "renater", # 'renater-lille' is a virtual network equipment on site 'renater'. This its description is in the grid5000's network API level.
        },
        {
          "uid": "gw1-h.net-admin.lille.inria.fr", # This can be the link to the local labo. Not necessarily described on our network API, but definitely a 'virtual' network equipment
        }
      ]
    }
  ]
}


Missing data

  • Latency (min theoretically observed). It could be implemented for cisco through its CISCO-PING-MIB
  • Router buffer size (vendor dependent);
  • MTU;
  • Networks: how to describe VPN, internet access?
Personal tools
Namespaces

Variants
Actions
Public Portal
Users Portal
Admin portal
Wiki special pages
Toolbox