03-25-2011 11:32 AM
We have following set of switches:
After extreme debugging, we are still unable to access the TurboIron from the FastIron and the other way around (neither ICMP via ping nor TCP/IP access via telnet works). We don't even get the destination switch's IP to the arp table of the source. Note that this problem occurs when we connect the switches via the fiber interfaces. If we connect them via the copper ports, pinging works flawlessly.
We have tested all possible switch pair combinations using fiber among the above switches and this works flawlessly, i.e. we are facing the above problem only with the TurboIron-FastIron pair.
The switches operate on their factory settings (even resetting won't work). Both involved fiber ports show up as UP and FORWARDING, access llists and mac filter tables on them have been cleared and we don't use any VLANs beyond the default one (VLAN 1). Fiber cables used are also good.
I would appreciate any tips towards a solution, since we have run out of clues.
Thank you in advance
03-25-2011 02:14 PM
Are you pinging from switches or from clients?
Please post a show version from both switches.
Have you configured a management IP address on the turboiron? Is that the ip address you are tring to ping from the FCX?
Please try this.
Say you are connecting the port number 25 on the Turboiron to the FCX on port 24.
TI#tag eth 25
FCX#tag eth 24
03-28-2011 03:28 AM
thanks a lot for your reply.
I have tried pinging both from clients or switches, neither works. I ping the management IP addresses of the switches, which have been checked to be correct (via show ip ...)
I attach below the software versions that the switches are running.
Unfortunately the port tagging commands are not available in neither my TurboIron, nor the FastIron versions I got.
Would appreciate any further input.
telnet@TX24 Switch#show version
SW: Version 04.1.00d Copyright (c) 1996-2009 Brocade Communications Systems, Inc.
Compiled on Jan 15 2010 at 17:57:14 labeled as TIS04100d
(4853454 bytes) from Primary TIS04100d.bin
Compressed Boot-Monitor Image size = 373767, Version:04.1.00T205 (grz04100)
HW: Stackable TurboIron-X24
Serial #: BFF2340E01P
BROCADE-ASIC 0: type B820, rev 01 subrev 00
833 MHz Power PC processor 8541 (version 32/0020) 66 MHz bus
512 KB boot flash memory
31744 KB code flash memory
512 MB DRAM
The system uptime is 1 hours 6 minutes 44 seconds
The system : started=cold start
telnet@FCX648 Switch>show version
Copyright (c) 1996-2010 Brocade Communications Systems, Inc.
UNIT 1: compiled on Mar 17 2010 at 22:15:04 labeled as FCXS07001b
(3805331 bytes) from Primary /foundry/FGS/os/FCXS07001b.bin
SW: Version 07.0.01bT7f1
Boot-Monitor Image size = 369286, Version:07.0.01T7f5 (grz07001)
HW: Stackable FCX648
UNIT 1: SL 1: FCX-48G 48-port Management Module
Serial #: BGG2217F0E1
P-ENGINE 0: type DB90, rev 01
P-ENGINE 1: type DB90, rev 01
UNIT 1: SL 2: FCX-4XG 4-port 10G Module (4-SFP+)
800 MHz Power PC processor 8544E (version 33/0022) 400 MHz bus
65536 KB flash memory
512 MB DRAM
STACKID 1 system uptime is 1 hours 8 minutes 8 seconds
The system : started=cold start
03-30-2011 03:14 AM
Thanks for your reply.
Yes, the ports 1-4 on the FCX (copper ports) are occupied. I just note that these ports (1-4) are on slot 1/1,
while the fiber ports are on 1/2.
03-30-2011 03:38 AM
As CMD implied - Ports 1-4 are combo ports on the FCX - you cannot use both port 1/1 though 1/4 when using 1/1f though 1-4f.
Take the copper connections out and retest please.
03-30-2011 04:55 AM
Thanks for that. I will test this later today and let you know about the outcome.
Though what bugs me is that using both ports (e.g. port 1 copper and port 1 fiber) concurrently does work,
when I connect the FCX with a NetIron! But it stops working, when I only connect the FCX with the TIX.
03-31-2011 05:43 AM
the port 1-4 was unfortunately not the problem, i.e. even if I don't use the 1-4 copper ports, I am still unable to ping the TurboIron from the FCX.
Note that if I connect the fiber port of the FCX to the fiber port of a NetIron and still use the copper port 4 of the FCX concurrently, poing still works,
i.e. this is not an issue.
I kind of run out of solutions, so installed wireshark on my laptop and monitored the fiber port at the FCX. I observe that arp requests from the TIX looking for the MAC of the FCX get never answered and so is the opposite direction. This is why I keep finding the arp tables of both switches empty. But even adding manually the respective entries to the ARP tables of both switches did not help.
Another observation during tracing is that FCX keeps periodically sending an STP topology change broadcast, which never ceases. I guess this means that the L2 path FCX-TIX is never built. This is confirmed, if I do L2-tracing from either switch: neither reports an L2 path.
The simplest I can think is that either of the two switches is blocking STP PDUs from the other and so no L2 paths are built.
I am also wondering whether I am wasting my time with >L2 debugging and the problem is at the physical layer.
I have though tested the fiber transceivers of both involved switches with other NetIron switches and all these tests work fine (pinging). It s only when I try
to ping between TIX-FCX that I get the problem.
Any further help would be greatly appreciated.
04-01-2011 03:29 PM
ok time to test another VLAN other then the default vlan.
create VLAN 2 on both switches
Tag the two port to the vlan.
put a VE on the FCX and then try and ping the FCX from the TI.
FCX#tag eth xx
FCX#router inter VE 2
FCX# ip address x.x.x.x/y
TI# tag eth xx
Please test this and let me know - if still no go then I will lab it on Monday (Australian time)