[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Testbed-admins] Problem configuring Cisco switch



Our switch is running IOS.

And yes! It works with your patch and the right 2-digit physical module
number in the 'wires' table.

Moreover, 'switchmac' also shows the actual 2-digit physical module number.

FYI. Previously, when I had the wrong 1-digit physical module number, I got
the following error:

*** ERROR: snmpit:
***   Can't "goto" into the middle of a foreach loop at
***   /usr/testbed/lib/snmpit_stack.pm line 471. 
*** ERROR: tbswap: Failed to set up VLANs.

The "goto" is in line 487. There is a similar one in line 462.

Of course, the error has disapeared when the patch has been applied and
'wires' table has the right infos.

Thanks again.
Manuel


> 
> Hmm, this is definitely strange! We do have a 6513 here, and haven't
> seen anything like this. You should definitely be able to put the actual
> physical module numbers in the wires table.
> 
> Theory: is your switch running IOS?
> 
> One thing to try: run 'snmpit -l -v 2', and look for the lines starting
> with 'IFINDEX' - these will report on how we are pulling card and port
> numbers in the switch.
> 
> Possible fix: I think I found a bug in our IOS code that would cause it
> to drop the all but the last digit of the module number - this would not
> show up in our testbed, because our 6513 runs CatOS, and all of our IOS
> switches have 9 or fewer modules. Try the attached patch to
> snmpit_cisco.pm and let me know if it fixes your problem.
> 
> Thus spake Manuel Requena on Tue, Sep 22, 2009 at 05:30:41PM +0200:
> > >
> > > > I've been playing with "/usr/testbed/libexec/switchmac" and
> > > > "/usr/testbed/bin/snmpit" and I think I have to put 10, 11, and 12
> > > > for 'card2' field for data interfaces. But card2='3' for control
> > > > interface. Why?  Any other idea?
> > >
> > > Could you send the output of swichmac so we can look at it?  Also,
> > > before you can use switchmac, you need to have traffic going out on
> > > all the interfaces, which is what the newnode MFS does. How are you
> > > arranging for the traffic?
> > >
> >
> > I only show the lines for pc21 and other machines in module #9:
> >
> > 000eXXXXXX98,cisco6513/0.21,1,pc21:eth2,expt
> > 0009XXXXXX12,cisco6513/9.25,1,unknown,expt
> > 000eXXXXXX88,cisco6513/1.21,1,pc21:eth3,expt
> > 0002XXXXXX6f,cisco6513/3.21,1,pc21:eth0,expt
> > 0009XXXXXX99,cisco6513/9.26,1,unknown,expt
> > 0002XXXXXX6e,cisco6513/2.21,1,pc21:eth1,expt
> >
> > According to the code, the output is:
> > <mac>,<switch>/<module>.<port>,<vlan>,<interface>,<class>
> >
> > So, pc21:eth0 is in module #3, but in fact, it is in physical module #13
> > pc21:eth1 is in module #2, but in fact, it is in physical module #12
> > pc21:eth2 is in module #0, but in fact, it is in physical module #10
> > pc21:eth3 is in module #1, but in fact, it is in physical module #11
> >
> > In line 2, you can see a mac in module #9, and it is. The same for line
> 5.
> >
> > Why sometimes you can find the real module and sometimes you can find a
> > "virtual" one? What I have to put in 'wires' table?
> >
> > For the traffic, I set a 1-node experiment and I use arping over all the
> > interfaces.
> >
> > Manuel
> >