On Thursday, October 20, 2011 06:39:38 AM Livio Zanol Puppim wrote: > About MPLS features in multiple areas, aren't there > solutions that can be implemented to overcome the > limitations like LDP prefix leaking or some solutions > with mGRE?
The IGP already knows about the individual infrastructure addresses between areas, which is what helps LDP to work. But MPLS-TE is something else. Paths have to be signaled, and by default, ingress routers signaling paths tend to prefer that the tail-end of the LSP be in the same area or level. If that isn't the case, Inter-Area TE is required. > What issue do you see keeping a lot of routers in a > single area (let's say 400) versus routers in different > areas? In OSPFv2, Areas help the routing protocol to scale, primarily due to the close ties between Type 1 and Type 2 LSA's. This isn't an issue in OSPFv3 or IS-IS, as Topology and Reachability information is separated. At the risk of starting a routing protocol war, IS-IS has been known to scale very well in single level environments (see Vijay Gill's OSPF-to-IS-IS migration at ATDN). We have two networks, one where we run IS-IS in one level (L2) and one where we use multiple levels. It scales very well in both, and both are fairly large. There are rumours that OSPF can scale to some 10,000 routes on today's kit, but I'm not sure as I don't run it. > Are there any recommendations about that or about the > maximum number of routers in a single area, or maybe > something about benefits/problems in both designs? The problem with a single area/level is that one router sneezing a million miles away is heard by all other routers at the topology level. For such a problem, OSPFv3 or IS-IS will react better. Areas/levels help to scale the network, but introduce issues like MPLS-TE. In our IPTv network, where we use NG-MVPN for Multicast (p2mp RSVP-TE), we use a single L2 IS-IS domain, just to avoid issues or configuration complexities with signaling p2mp paths across different parts of the country. The risk is increased noise, but the kit can take it. Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
