Morning, Eric. Did you folks finally thaw out up there? We didn't get nearly as much weather as you got these past few weeks. We narrowly escaped the ice too. Good thing.
I'd figured out why they translated our VLAN IDs. It seems like they could find another way to accomplish that though, even if it was more config intensive. It will work though. I read the whitepaper before we brought them in for the dog & pony show. Unfortunately Flex-Link isn't an option in our environment (nor is it in many others) simply because it isn't multichassis-aware. We're touching the Occam switches from a pair 7600s for redundancy. Connecting the Occam switches to a single chassis doesn't meet out redundancy needs. STP will work though and in fact it is now working. Phil was right. There was a VLAN crossed in the Occam switches. I found it this morning. We changed our VLAN plan during the deployment and apparently we didn't change one of the Occam switches to match. Now that we have STP working I'll experiment with STP's rapid cousins to see how quickly we can make it fail-over. I wish we had UDLD support; that would greatly help speed up L2 failure discovery. We'll just have to make due without it. Thanks for all the input Justin Eric Helm wrote: > Justin, > > I've had some experience with the Occam FTTx gear, and it is a bit odd > the way they handle those internal VLANs, but they do it because they > hard code the QOS based on VLAN ID, so they simply tranlate their > internal VLANs to whatever VLANs you want to use in the rest of your > network. In my past experience with Occam, it was with Foundry L2 > aggregation gear, and we chose to use Foundry's Metro Ring Protocol > instead of STP. It worked great in conjunction with Occam's Ethernet > Protection Switching protocol. Although, I've not used Occam with Cisco > gear, Occam's website has a whitepaper that suggests using Cisco's Flex > Link technology for high availability, which would remove the need for STP. > http://www.occamnetworks.com/pdf/CiscoSvcFlxOccam.pdf > > /Eric _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
