VPLS and layer 3 routing

Unanswered Question
Aug 22nd, 2010

Hello, i was wondering what routing protocol or design considerations you would recommend for 50+ site with any to any connectivity over VPLS..?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Peter Paluch Sun, 08/22/2010 - 02:59

Hello Rays,

In my personal opinion, the presence of the VPLS is not the crucial factor here. What you are really asking about is this: "I have a network consisting of 50+ locations, all interconnected via a single multiaccess backbone segment. What routing protocol should I use?"

I believe that either OSPF, IS-IS or EIGRP would do nicely. Having OSPF or IS-IS has many advantages of being open, vendor-neutral, you could deploy areas to further simplify the amount of information in link-state databases and routing tables on individual locations, and many other advantages that the link-state routing protocols usually give you. Having EIGRP would obviously necessitate using Cisco gear, as - to my knowledge - no other vendor supports EIGRP (anybody correct me here if I am wrong). EIGRP may be somewhat easier to configure. Also, being essentially a distance-vector algorithm, it allows you to summarize routing information on any router (link-state protocols permit summarization only between areas and when performing redistribution).

So I really think that there are different, more important criteria than just having a VPLS VPN - whether your network is multivendor or not, whether your addressing plan is well assigned and summarizable towards the VPLS as the backbone, whether you are familiar with any of these protocols to deploy and maintain it successfully, whether you have any special needs or requirements on them, whether you plan to utilize some advanced technologies that require, for example, running a link-state protocol (MPLS Traffic Engineering is one of them).

I am very interested in learning opinions of other friends here, as these are my personal ideas (no best-practice book involved in this case).

Best regards,


rays Sun, 08/22/2010 - 03:13

Hi Peter, thanks for the responce. I totally understand the concept that it is essentially a

multi access lan segment. My concern is regarding the scaleability and the

issues that may arise from using , lets say EIGRP.. which uses multicast

for Hellos, queries and updates. with 50+ routers on a segment throwing that amount of multicas

t traffic around, i am concerned (maybe wrongly) about

the impact this will have on the network.

I am interested to know what routing protocol others have used for similar scenarios and if there has been any scaleability issues. I think it would be a poor design (if you had a choice) to have 50+ routers on a single broadcast/multicast domain. But due to the nature of VPLS then maybe you have no choice..


Peter Paluch Sun, 08/22/2010 - 03:30

Hello Rays,

Having 50+ routers on a single segment is not that much and I personally have no problems with it. Moreover, using multicasts is not a disadvantage - right on the contrary, for routers, it is the minimum work possible, and thus very advantageous. The job of replicating these multicasts is on your VPLS service provider. In a stable network, there will be 50+ Hellos every 5 or 10 seconds and that's about it. Sure, every OSPF router will regenerate its LSAs every 30 minutes but the routers in OSPF are uncorrelated in this aspect, and the LSA regeneration would spread itself over time. Nevertheless, I do not believe that the amount of routing protocol traffic is significant to the total VPLS bandwidth. By the way, what are the bandwidth parameters of your VPLS service?

Nevertheless, it is possible to force both OSPF and EIGRP to treat that segment as a NBMA segment and configure adjacencies in that particular routing protocol in a hub-and-spoke fashion. That would further minimize the amount of data sent between the routers while not impairing reachability. Of course, a failure of a hub router could disrupt the flow of routing information so multiple designating multiple hub routers on the VPLS segment would be highly recommended.

Best regards,


rays Sun, 08/22/2010 - 04:03

Hi Peter, again thanks for the response. You have helped ease my fears! I have never seen that many routers on a single segment before so was  not sure about the impact. Another question, sticking with EIGRP (that is the preferred option), what if there is a flapping interface at one remote site.. How would this impact the network overall? on a single broadcast/multicast segment, would a single multicast not interrupt traffic (data) flow (ie. consume all bandwidth )... or am i wrong? Another thing, the remote routers will be fairly low spec, are there no issues with having 50+ eigrp neighbors in the table?

The idea is to have any to any connectivity so will not be hub/spoke scenario.

thanks a lot for you're information.


Peter Paluch Sun, 08/22/2010 - 06:51

Hello Rays,

With EIGRP, an interface going down on a router will cause this router to send queries and these queries will, in the worst case, propagate through the entire network, engaging all routers into an active state for the disconnected network. An interface going up will result in an update being sent that also propagates through the entire network. If these are singular events, no harm is done, however, if this is repeated often, it may have a negative effect on the network's performance and/or convergence.

In EIGRP, the scope of a query and update can be very effectively limited by using the summarization. Updates about a particular network do not cross the summarization points (i.e. interfaces on which a summary is configured that covers the particular network in the update), and while a query does cross a summarization point, the very next router immediately replies with an infinite distance to that query because it does not know about a particular component, rather only about the entire summary.

Also, the EIGRP stub functionality can limit the query depth very effectively, however, it poses certain requirements on the network design and I am not sure if that would be applicable for your network.

So there are tools in EIGRP that allow you to minimize the so-called failure domain that is negatively influenced by a topology change, and using them judiciously is strongly recommended.

Regarding the hub-and-spoke: I did not mean converting the VPLS service into a hub-and-spoke topology. What I meant is that we can configure the EIGRP in such manner that only selected routers maintain an EIGRP adjacency as if the network was hub-and-spoke. However, the network itself will remain fully reachable and also the routers will be continuously able to route packets directly from one to another despite the EIGRP will be working in a hub-and-spoke fashion. But, frankly, I am not sure if this would be worth the configuration effort.

Regarding routers maintaining adjacencies with 50+ EIGRP neighbors - I must admit I have no practical experiences of a similar kind. I hope that other friends here will share their knowledge about this. I would say: let's deploy it this way, with the full reachability and full adjacencies, and monitor the CPU load on all backbone routers cautiously. If it starts going too high, we can always reduce the EIGRP adjacencies to a hub-and-spoke scenario while maintaining the direct connectivity.

Best regards,


rays Sun, 08/22/2010 - 09:18

Hi Peter. Thanks for taking the time and giving me a great response. I will go ahead with enabling EIGRP for full connectivity and i will monitor the situation as i go. I will provide some feedback and let you know how it goes,

many thanks,



This Discussion