Network Architecture

In the previous chapters, we described most of the design options that are possible. In this case study, the focus is on what is recommended. This practical architecture reflects all of the best current practices of deployment on the

Internet.

11.1.1 PIM-SM

PIM-SM is the multicast routing protocol used in this network. The PIM-SM domain contains five statically mapped anycast RPs. As is the case in most native ISP deployments, static RP mapping is selected over BSR and auto-RP because it provides maximum simplicity. Anycast delivers RP load balancing and redundancy.

The number of RPs deployed in an ISP network typically ranges from four to eight. Fewer than four RPs in a domain may not supply enough redundancy or load balancing. More than eight RPs adds extra administrative burden with little benefit.

11.1.1.1 RP Placement

To reduce the potential for suboptimal routing on the RPT, the routers selected as RPs should be well connected and in the core of the network. Because the RPT is usually short-lived, it is not essential to have centrally located RPs, but it makes more sense. In our example network, one core router from each of the five largest hub sites is chosen as RP.

The names and unique IP addresses of the loopbacks of these routers are as follows:



PIM-SM is configured on all of the nonmanagement interfaces of all routers in the network. PIM borders are configured on all customer-facing links to prevent certain multicast traffic from leaking onto the service provider network. This type of traffic includes protocol and administratively scoped addresses.

Customers of this ISP have the choice of using the provider's RP or their own RP. Likewise, BGP customers may elect to run MBGP with the provider.

11.1.2 IGP

In our example network, configuration for IS-IS is provided with the equivalent OSPF configuration shown in italics.

All routers in the domain are assumed to be level 2-only routers in the same area with congruent unicast and multicast topologies. Likewise, a single backbone area is the only OSPF area in the network. The IGP carries routing

information for only the loopback and network-facing (that is, noncustomer-facing) interfaces of the ISP's routers.

The anycast RP address is also carried by the IGP.

11.1.3 MBGP

MBGP is used to carry all other routes, including customer networks, static routes, and all directly connected routes.

Because the unicast and multicast topologies are congruent, the unicast and multicast routing tables are identical.

11.1.4 MSDP

MSDP is used to create connections between internal and external RPs so that they can exchange information about the active sources in their respective domain and subdomains. Customers who choose to run their own RPs have an MSDP peering between their RP and the nearest RP of the provider. SA filters are configured on customer peerings to prevent customers from leaking SA messages that should not be on the Internet, including SAs with sources that are in private address space and groups that are administratively scoped or reserved for protocol use.

In this example, we reluctantly chose to put all anycast RPs in an MSDP mesh group. A mesh group is needed in this topology to prevent RPF-peer failures. Without the mesh group, external SA messages forwarded by one anycast RP may be discarded by the other four anycast RPs. For example, imagine NY-RP receives an SA message from a customer MSDP peering. The customer's RP, Cust-RP, originates the SA message.

Based on the first RPF rule of version 2 of the MSDP draft (Cust-RP is the originator), NY-RP determines that Cust-RP is the RPF peer, accepts the SA, and forwards the SA to the other four anycast RPs. If NY-RP is not advertising the active IBGP route for Cust-RP to LA-RP (RPF rule 3), LA-RP determines that NY-RP is not the MSDP RPF peer for Cust-RP and discards the SA. Because NY-RP is a router somewhere in the core of the network, this condition probably will not be met, and LA-RP (and possibly the other three anycast RPs) will not accept any SA messages coming from Cust-RP's domain.

With a mesh group, LA-RP always accepts any SA it receives from NY-RP. The disadvantage of mesh groups is that MSDP traceroute might not work properly, and the entire goal of RPF-peer forwarding is lost.

There are two alternatives to using a mesh group in this topology. First, create an MSDP peering between every anycast RP and every edge router that connects directly to customers. By setting up the external MSDP peering between Cust-RP and its nearest edge router, SA messages received by the anycast RPs from this edge router satisfy RPF rule 3. However, this complex topology of MSDP peerings would carry a great deal of administrative burden.

A second approach is to create an MBGP session along with the MSDP session between Cust-RP and NY-RP.

This alternative makes NY-RP far more likely to advertise the active IBGP route for Cust-RP to the other anycast RPs, satisfying RPF rule 3. Once again, this solution adds far more administrative overhead than the simple mesh group option.

This document is created with the unregistered version of CHM2PDF Pilot

This document is created with the unregistered version of CHM2PDF Pilot