Passport 8606 Version 3.7.2.0 and SMLT

Hello,

I have a bit of a problem here. I have 2 Passport 8606 core switches that are interconnected with an IST MLT links. From these switches there are several SMLT links running to Passport 1624 Distribution switches. All those links are fiberlinks of 1 Gb. To one location this SMLT is build with a Singlemode fiber and a Laserlink through the air (Laserbit Gigabit Pinto).

Sometimes this Laserbit connection has some trouble due to fog etc and this connection starts to break and come up again very fast after on another. The result is that sometimes the Passport 8606 thinks it sees a loop on this port and drops this connection. This would not be a problem except that the moment this Laserbit connection drops the whole SMLT sometimes stops transporting packets and the site that should be connected is gone completly. Most of the times when this happens I have to disconnect the laserbit from the network and the SMLT comes back online.

On the Passport 1624 the SMLT is connected to port 23 and 24 of the switch.

Are there some known problems with SMLT links in the used firmware of the Passport 8606 switch, if so, are there firmware revisions that fix this problem?

Are there some other issues that I am not aware of that could result in this configuration being instable?

Thanks a lot, Jan Hugo Prins

Reply to
Jan Hugo Prins
Loading thread data ...

First of all, you may want to open a case with your support channel. But.. From what I remember, there where some ways the 8600 could detect loops. If you really don't have a loop in the port, I guess you could try to disable these "detections", one by one, to see what is the trigger. But, you would need first to see if this is the problem..

I've not used 3.7.2.0 with SMLT, but there are at least 2 minor releases I saw in the field (3.7.2.1 and 3.7.2.2) using SMLT. You may want to check at these release notes to see if they fix anything..

You may want to take a look at the log information, from both 8600s, to isolate the problem.

In SMLT (also), if you have something preventing you from "detecting" the failure, link failures may be a problem hard to isolate.

I've not checked the 16xx sw, but recent sw for the 8600, offer something called VLACP to be able to detect failures "over transmission", where the transmission equipament would be 'hiding' the failure from the 8600.

Assuming the 8600 doesn't know the link went down, it would be still sending traffic over the bit-bucket link, same thing would be possible in the 16xx side ? [],

Reply to
Julio Arruda

You should not have loops with SMLT. Disable STP on MLT ports.

Reply to
joe blow

Just checked in the configuration and STP is disabled on the MLT ports, at least in the Core routers (8606). Can't check the 1624 at the moment because I don't have that config at my laptop. But a reference config that should be about the same, for maybe some minor changes tells me that STP might be enabled on the ports where the SMLT enters the 1624 (port 23 and

24).

# STP

disable stp config stp version rstp config stp maxage 20 hellotime 2 forwarddelay 15 priority 32768 txholdcount 3 fbpdu enable config stp ports 1-24 cost auto edgeport false p2p auto priority 128 state enable enable stp

A few lines might be wrapped a little.

Anyway, could you tell me what the result of this setting could be? Could this result in the problems that I'm experiencing? What does STP do exactly that it results in this?

Jan Hugo

Reply to
Jan Hugo Prins

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.