Re: [Testbed-admins] update need advice regarding "SNMP SET failed"

["Cheng Cui" <ccui1@tigers.lsu.edu>]

Thanks a lot Keith,

Quote of Keith:
>try:

>snmpset -m all cisco2 vlan2 portAdminSpeed.1.1 = 100000000

>If that does work, then we can go back to trying to figure out
>how the wires tables should be set up.

What I get is:
%snmpset -m all cisco2 vlan2 portAdminSpeed.1.1 = 100000000
enterprises.cisco.workgroup.ciscoStackMIB.portGrp.portTable.portEntry.portAd
minSpeed.1.1 = s100000000(100000000)

Quote of Keith:
>Can you tell us whether you entered the data for it by hand,
>or did you rely on the automated node_addition process through
>the web interface?
>(My guess is that you did it by hand, because you couldn't even
>talk to the switch from the boss until recently and the internally
>used "switchmac" which attempts to survey what mac addresses have
>been seen on which port via SNMP could not have obtained its data).

We got the data through web interface. I have to admit that boss could
previously reach experiment switch before we altered the switch's ip address
by mistaken. At the very first, we see "snmp set" error; then, we mistakenly
altered the experiment switch's ip and get the "snmp get" error. After Leigh
and others point out our mistaken, I changed the experiment switch's ip in
all the same subnet "192.168.0.x" for simplicity and get this "snmp set"
error again. Honestly speaking, it was our mistaken to assume the snmp mib
problem in a loop situation. I apologize for that. Now, it looks the wires
table is the source of those problems because I assume there is a port
mis-match in "switchmac", isn't it? : )

Quote of Keith:
>If you did run switchmac and the data were not entered correctly
>into the wires table, then there may be an off-by-one bug that
>is switch type specific ... this is a comment for the maintainers
>of the snmpit stuff (including me).

I have no other reason than thinking about the "switchmac" caused this
problem. Here is the 'wires' table:
mysql> select * from wires;
+-------+-----+---------+----------+-------+-------+----------+-------+-----
--+
| cable | len | type    | node_id1 | card1 | port1 | node_id2 | card2 |
port2 |
+-------+-----+---------+----------+-------+-------+----------+-------+-----
--+
|  NULL |   0 | Node    | pc       |     1 |     1 | cisco2   |     1 |
9 | 
|  NULL |   0 | Node    | pc       |     0 |     1 | cisco2   |     1 |
1 | 
|  NULL |   0 | Control | pc       |     2 |     1 | cisco1   |     1 |
9 | 
|  NULL |   0 | Node    | pc2      |     1 |     1 | cisco2   |     1 |
5 | 
|  NULL |   0 | Node    | pc2      |     0 |     1 | cisco2   |     1 |
7 | 
|  NULL |   0 | Control | pc2      |     2 |     1 | cisco1   |     1 |
10 | 
|  NULL |   0 | Control | pc3      |     0 |     1 | cisco1   |     1 |
2 | 
|  NULL |   0 | Node    | pc3      |     2 |     1 | cisco2   |     1 |
19 | 
|  NULL |   0 | Node    | pc3      |     1 |     1 | cisco2   |     1 |
20 | 
+-------+-----+---------+----------+-------+-------+----------+-------+-----
--+
As I spied on the physical connection from nodes to experiment switch, I
could say, for example: the actual ports connection of 'pc3' to experiment
switch are 10 and 11; but in the 'wires' table they are 19 and 20 in field
'port2'.

Best Regards,

Cheng Cui
578-5445 . 231 Johnston Hall . Baton Rouge, LA 70803

-----Original Message-----
From: Keith Sklower [mailto:sklower@vangogh.CS.Berkeley.EDU] 
Sent: Wednesday, April 15, 2009 3:27 PM
To: ccui1@tigers.lsu.edu
Cc: azad@cct.lsu.edu; testbed-admins@flux.utah.edu
Subject: Re: [Testbed-admins] update need advice regarding "SNMP SET failed"

    From testbed-admins-bounces@flux.utah.edu Wed Apr 15 10:58:51 2009

Cheng cui wrote:
>> My understanding is that Experiment switch does not need to assign
>> static ports to vlan, right? Then, why the 'wires' table has such
>> ports match in 'port2'? What does "Port not found, skipping" mean in
>> the error message?

Leigh Stoller responded:
    
> Emulab does indeed assign ports to vlans dynamically.
> not in use, it is disabled ...

> The wires table tells snmpit how to "address" the actual interfaces on
> the switches. It needs to match what the switch thinks. In the output
> you sent, it appears that the switch has the interfaces on card 1
> instead of card 0.

Cheng asked again:

> Sorry, I am a little confused. Each of those three nodes has one interface
> for control, and two interfaces for experiment. I thought two interfaces
> should be recognized by the experiment switch, so as indicated in the
> 'wires' table field 'port2'.

And I attempt to explain differently (and attempt a rationale for
the design of the wires table): 

As Leigh explained, there needs to be some kind of mapping in the
system to identify which interfaces on experimental nodes are wired
up to which sockets on the switches, so that when you tell the
*switch* by SNMP to place a group of sockets into a particular vlan
it corresponds to what the experiment wants.

Emulab has to support different kinds of switches; some of the
big big switches have removable modules (line cards) and ports
within the cards.  So, at least on the switch side, this
translation table should provide for "card" and "port".

It is somewhat unusual for experimental nodes to have multiple ports on a
single
PCI card, and even when they do, the opperating system identifies
them as separate interfaces, so you might think that the
you could have an entry in the wires table that had colunms

(node_id, node_if, switch_id, switch_modules, switch_socket_within_module),

*BUT* the wires table is also used for recording how the switches
are connected.

So the description of both ends of the connection needs to be symmetrically
described.

Leigh Asked:
>> So, we had said "card2" not "port2" ... which did you change?

Cheng replied and asked:

>First, what does the field 'card2' mean? I changed it to 'card2=1' as
>advised. Then, I found there were some mis-match of 'port2' on experiment
>switch because I checked the physical ports on the switch and I thought
>they must be matched on the 'wires' table field 'port2'.

>After these two database operation, I started an experiment through
>website, and got that  "Port not found, skipping" error message.
>Maybe my understanding was wrong?

>Looks like my understanding was so limited. Would you please give more
>explanation and help on our first testbed? Thanks a lot. : )

I attempted to, above.

Before muddling with the wires table, I think it would be good
to first establish that we can even set the duplex and speed
variables by SNMP, and we can test using the this on the command line.

Robert Ricci asked you to use snmpwalk to see if you examine
part of the mib by snmpwalk -m all cisco2 vlan2 portAdminSpped
and on the basis of the result thought it might work by
changing something in the wires table, but it might be good
to double check that the switch actually will change the
variable rather than just read it:

try:

snmpset -m all cisco2 vlan2 portAdminSpeed.1.1 = 100000000

If that does work, then we can go back to trying to figure out
how the wires tables should be set up.

Can you tell us whether you entered the data for it by hand,
or did you rely on the automated node_addition process through
the web interface?

(My guess is that you did it by hand, because you couldn't even
talk to the switch from the boss until recently and the internally
used "switchmac" which attempts to survey what mac addresses have
been seen on which port via SNMP could not have obtained its data).

If you did run switchmac and the data were not entered correctly
into the wires table, then there may be an off-by-one bug that
is switch type specific ... this is a comment for the maintainers
of the snmpit stuff (including me).

My next somewhat snotty suggestion is that if you are still having
problems, you might try using the perl debugger to step through
snmpit .. e.g. have /usr/testbed/{,s}bin in your path and do

    wap perl -wd /usr/testbed/bin/snmpit -u full node:1

where you replace `node' with what ever  you're calling your test
nodes, and trace it through to snmpit_cisco::portControl and
verify that it generates the right variable to be set
corresponding to the interface *which you should calculate by hand*.

I presume that you and your colleagures are graduate students in
computer science (or faculty members), and consquently should be
fully capable of using a debugger and reading code.

Rob Ricci's code is very well laid out, and it was pretty easy
for me to read it and understand his intent.

Regards,

Keith Sklower