Changes between Version 14 and Version 15 of Internal/OpenFlow/SandBoxSetup

Timestamp:

Aug 17, 2009, 5:39:37 PM (15 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/SandBoxSetup

@@ -205 +205 @@
 The ideal is for the nodes to negociate to 1Gbps on the Control and Data VLANs, and 10Mbs on the CM. For some reason, the nodes sometimes negociated to 100Mbs. Forcing the ports to 1Gbps with autonegotiation only caused to ports to shut down when the nodes negotiated to 100Mbps. Ultimately the ports were left configured to `speed auto`. 
 
-=== disabling '''all''' forms of spanning tree ===
+=== spanning tree ===
 Spanning tree can be disabled with the command 
 
@@ -220 +220 @@
 }}}
 
-= Making use of NOX (8/6) = 
+= NOX (8/6) = 
 Writing a controller by tying together the functional code defining !OpenFlow Protocol using Ruby turned out to be a pretty messy task. According to the NOX developers, it would be better to do some Python development on the NOX web-API to expose functionality that can then be called using Ruby. 
 
@@ -318 +318 @@
 }}}
 
-
+= SNMP (8/13) =
+Simple Network Management Protocol (SNMP) can be used to get information and configure network devices remotely. The protocol uses management information bases (MIBs), which store information about what can be looked up using SNMP in a tree-like hierarchy (a MIB tree), in order to look up information. Each piece of information has a unique identifier (OID) that denotes which part of the MIB tree they belong in. Information can be pulled up using the OID or their human-readable name (i.e. the administrator-designated status of ports, 1.3.6.1.2.1.2.2.1.7 or ifAdminStatus)   
+
+
+== With respect to SB9 ==
+SB9 is set up to be the manager device for sw-sb09. The switch is configured with an ACL that allows SB9 to access and modify information via SNMP (configuration details [http://www.orbit-lab.org/wiki/Documentation/OpenFlow/CLISetup here]).   
+
+=== retrieving information ===
+syntax : `snmpget|snmpwalk [options] [agent IP/name] [OID]`
+
+`snmpget` retireves a single piece of information. `snmpwalk` retrieves a whole set of information by calling `getnext` repeatedly. You only need read access to the switch to see the information.    
   
-
-   
-  
+for example,
+{{{
+root@sb9:~# snmpwalk -v 2c -c netadmin 172.16.100.10 1.3.6.1.2.1.1
+}}}
+
+returns   
+{{{
+SNMPv2-MIB::sysDescr.0 = STRING: ALAXALA AX3640S AX-3640-48T2XW-L [AX3640S-48T2XW] Switching software Ver. 10.7 [OS-L3L]
+SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.21839.1.2.11
+DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (26201570) 3 days, 0:46:55.70
+SNMPv2-MIB::sysContact.0 = STRING: 
+SNMPv2-MIB::sysName.0 = STRING: sw-sb09
+SNMPv2-MIB::sysLocation.0 = STRING: 
+SNMPv2-MIB::sysServices.0 = INTEGER: 78
+}}}  
+
+`snmpget` follows the identical syntax, but you must specify a single specific parameter, i.e. the status of just one port:
+{{{
+snmpget -v 2c -c netadmin 172.16.100.10 1.3.6.1.2.1.2.2.1.7.3  
+IF-MIB::ifAdminStatus.3 = INTEGER: up(1)
+}}}
+
+trying to get a block of info like with snmpwalk will just give you errors:
+{{{
+snmpget -v 2c -c netadmin 172.16.100.10 1.3.6.1.2.1.2.2.1.7
+IF-MIB::ifAdminStatus = No Such Instance currently exists at this OID
+}}}
+ 
+=== setting information ===
+`setsnmp [options] [agent IP/name] [OID] [datatype] [data value]` - lets you change the status of a MIB value, given you belong in the access list granted with snmp read/write permissions on the switch. 
+
+the syntax here is not much different here. Here, port 0/1 is manually shut down via snmp:
+{{{
+snmpset -v 2c -c netadmin 172.16.100.10 1.3.6.1.2.1.2.2.1.7.10 i 2
+IF-MIB::ifAdminStatus.10 = INTEGER: down(2)
+}}} 
+ 
+for a more detailed look, the tutorial: http://net-snmp.sourceforge.net/wiki/index.php/TUT:snmpset
 
 [[BR]]