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..

rays

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,

Peter

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.

rays

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,

Peter

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,

rays