Mohammad Khalil wrote: > Thanks a lot Nick for your comments > > My customer is heavily deploying VPLS with autodiscovery , if I want to > suggest replacement what will be the best options?
tl;dr: l3vpn. The longer answer is that you need to step back and look at what's going on and where it's leading to. Lots of VPLS probably means a bunch of different sites with a requirement to have flat inter-site connectivity. This works fine to a certain point and then you run into problems; handling redundancy is one of the traditional problems that you run into, namely connecting two different styles of layer 2 domains together which use different bridging protocols (stp and split horizon). IOS implemented PE redundancy to do this; other vendors provide other solutions (e.g. vpls stp edge, etc). However these solutions are patches to work around a fundamental problem with the network design, namely that layer 2 is not a suitable mechanism for handling large-scale, complicated multisite connectivity, and if you have a border between two bridging protocols, you need a translation layer. Maybe you could use static configuration for situations where you need PE redundancy. I haven't tried this: it might work, or it might not, and most likely if it works, it will cause maintainability problems in future. However, this sort of solution is network engineering with chewing gum and sellotape: you will end up with a poorly built product which will break easily and has a high administrative cost. It's the same as any engineering problem: you can often use tools for different thing, but if you don't choose the right tool for the job, you will run into problems. You need to get your customer to think about a design change. This will mean working with the customer to help them to understand the limitations of what they are trying to do (broadcast / multicast management, site-to-site redundancy management, site-to-provider redundancy management, etc). It might be that using individual pseudowires would provide a better solution in the short term because that would allow them/you to avoid the bridging protocol border incompatibility problem. Alternatively, an l3vpn configuration will scale to as large as the customer needs, and is likely to be a far better solution in the long term, as layer 3 is designed to handle redundancy. If I were you, I would try the static + autodiscovery configuration and see if it works. If it does, I would request the customer to acknowledge in writing that they accept that this is not a recommended design and it is likely to be prone to failure, and that that you will not accept any liability for any future connectivity failure which can be traced to this problem, and that they accept that future connectivity requirements will need network redesign on their part. If it doesn't work, you'll need to let them know the bad news that they'll need to start their network design sooner rather than later. Incidentally, this is partly a customer management problem: your customer needs to be educated and you can make money from educating them. In the process, you'll end up with a happier customer, a cleaner network and lower work load, i.e. win for all. If you continue with just vpls, it will break your heart. Nick _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
