Multiservice Networking with the M-series · 2005. 3. 24. · Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408 745 2000 or 888 JUNIPER Part Number: 200047-001

White Paper

Multiservice Networking with the M-series Examples in Service Delivery

Matt Kolon Technical Marketing Manager

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408 745 2000 or 888 JUNIPER www.juniper.net Part Number: 200047-001 Feb 2004

Contents Contents ..................................................................................................................................................2 Executive Summary...............................................................................................................................4 Perspective..............................................................................................................................................4

From Internet to Infranet .............................................................................................................5 Edge Services and their Enabling Features ........................................................................................5

Setting the Stage............................................................................................................................6 Phase One: Internet Access..........................................................................................................7 Phase Two: Virtual Private Networking....................................................................................8

Adding MPLS to the Network ...........................................................................................9 Configuring Traffic Engineering......................................................................................10 Deploying a Layer 3 BGP/MPLS VPN Service..............................................................11 Inter-site Connectivity at Layer 2 ....................................................................................13 Deploying a Layer 2 BGP/MPLS VPN Service..............................................................13 Deploying Layer 2 Circuits...............................................................................................15 Advanced Layer 2 Functions............................................................................................16 Deploying Layer 2.5 Interworking VPNs .......................................................................16 Deploying Virtual Private LAN Service .........................................................................17 Phase Summary..................................................................................................................19

Phase Three: Additional Value-added Services......................................................................19 Tiered Services using CoS.................................................................................................19 Network Address Translation..........................................................................................22 Adding Security .................................................................................................................23

Conclusion ............................................................................................................................................25

Copyright © 2004, Juniper Networks, Inc. 2

Multiservice Networking with the M-series

Executive Summary The Juniper Networks M-series family is built according to modern architectural principles that make it ideal for both core and edge applications. Because of the performance and scalability resulting from this modern architecture, M-series platforms have been used to construct some of the world’s largest networks. Over the last five years the capabilities of the M-series have been honed to deliver high performance services at the network edge, ranging from best-effort Internet access through many types of Virtual Private Networks to additional value-added services such as Network Address Translation and stateful firewalls.

The platform has also been enhanced with capabilities that make it ideal not only for supporting IP services, but also a platform that can support the convergence of Layer 2 services like ATM, Frame Relay, and Ethernet over IP/MPLS. This set of capabilities makes the M-series ideal for supporting providers who are consolidating a multitude of services and networks onto a single common infrastructure. This common infrastructure follows the vision of the Infranet Initiative espoused by Juniper Networks and others. The infranet approach defines a new type of network that takes the best attributes of today’s public networks, like the PSTN and the Internet, and adds essential commercial functionality to the IP/MPLS architecture. The answer to delivering this new type of network lies in extending public IP/MPLS networks beyond each provider’s footprint through commercially-oriented, inter-carrier interfaces. The result of this approach will expand the overall communications market opportunity by yielding a global set of networks that will support rich any-to-any experiences for business and consumers, without limits.

This paper introduces the reader to the service provider Acme and follows that company’s deployment of customer services over a network of Juniper Networks M-series. Beginning with basic configuration of Internet access, Acme deploys several types of VPN and additional services to transform what was a best-effort Internet network into a multi-service IP/MPLS network capable of providing high-value services to customers of many different types. The shift from Internet to multi-service networking is the transformation that changes Acme from a provider of a commodity service to a valued business resource for its customers, who are willing to pay a premium for the value-added services that Acme now offers.

The deployments described in the paper are accompanied by configuration examples that show the reader in broad strokes the ease with which value can be added to the services provided by Acme.

Perspective While the fundamentals of the Juniper Networks M-series design were first appreciated in the network core role, the M-series architecture was conceived and implemented with full-speed edge service delivery in mind, in expectation of the day when service providers would move from mere best-effort Internet service to full-featured, multiservice IP networking. In fact, the entire heritage of today’s M-series platforms is rooted in design decisions that anticipated the evolution of the router’s role from simple bit transport to complex packet processing, from IP-based to IP/MPLS-based, and from commodity Internet service to the assured experience of the infranet required by the revenue-earning services that drive profitable networking in the 21st century.

These design precepts are referred to collectively as the Juniper Networks Service-Built Edge Architecture, and in summary consist of:

• A groundbreaking design developed with MPLS fundamental to the platform.



• An ASIC-based forwarding architecture centered around the programmable Internet Processor II ASIC and other components of the Juniper Networks-designed chipset that enable high performance and granular packet processing and QoS.

• A scalable and stable control plane running a modular operating system that could scale to signal and manage thousands of services without performance compromise.

• A “telco-quality” approach to the key design goals of stability, high availability, security, and performance without compromise that builds upon the backbone experience of Juniper Networks.

All of these design principals are in stark contrast to competitive offerings that were designed before the importance of MPLS for multiservice, programmable ASICs for uncompromising performance, object-oriented programming for a scalable and stable control plane and security and reliability for preserving SLAs were understood.

The Service-Built Edge has been continuously refined, as it has been used to deploy IP/MPLS services in the world’s largest production networks. The M-series family is ideally positioned to help providers and their customers make the switch from Internet to infranet.

From Internet to Infranet The remainder of this paper will guide the reader through a series of service deployments that are similar to those being offered by many of Juniper Networks’ customers. The purpose of these examples is to provide insight into the multiple new services being deployed on M-series platforms in the networks of the most successful IP/MPLS service providers in the world. The managers of these networks know that the provision of Internet access alone is a commodity service that becomes more and more difficult to do profitably as time goes by. The know, too, that the only way to succeed in this environment is to raise the value of the networking services that they offer, by adding business connectivity, security, convenience services like address translation, efficiency boosters like Class-of-service capability, and other additional items. The ability to do this changes the zero-sum relationship between a commodity vendor and its customer into a trusted relationship between business partners.

By demonstrating the capabilities of the M-series family, this paper seeks to help service providers transform their network – from an extension of the Internet, to an infranet, where value is inherent in the network services themselves, and not simply by virtue of what the network connects to.

Edge Services and their Enabling Features The IP divisions of many service providers are now facing a daunting task: migrating their networks from best-effort Internet access to multiservice, value-added networks that enable customers to select from a varied menu of network services. The following sections provide a primer on how multiple services can be layered on a single M-series platform to achieve this goal.



Setting the Stage Acme, a fictional, mid-sized provider of voice and data services in North America, is deploying a variety of services with a particular focus on the M-series platforms that they use on the edge of the network. Acme will provide an example of the challenges and solutions present in the service provider environment today. The Acme IP network was built in response to customer demand for Internet access service, which Acme offers along with other voice and data services such as Frame Relay and ATM.

Figure 1: The Acme IP network

Acme’s IP network consists of a core of Juniper Networks T-series products, with M-series platforms on the customer-facing edge of the network. The core routers in the network form a mesh topology, with each core router being connected to every other core router via OC-48 and OC-192 links. Other routers serve as customer edge routers and as peering points for interconnection to other providers.

The edge and peering routers differ in their connection to the core depending on the degree of fault-tolerance required for the connected customers, and the number of customer connections and their capacity (and hence the bandwidth required) on that particular router.



Like most service providers, the Acme network offers dedicated Internet access over a variety of customer connection options, with speeds ranging from DS0 to OC-12. Also like most providers, Acme has multiple overlay networks and in the beginning used this IP network to carry basic Internet connectivity only. Customers wanting security or VPN services either subscribed to ATM/FR services or took a “do-it-yourself” approach by setting up tunnels between CPE routers.

Phase One: Internet Access Acme’s IP network, built as an overlay to their existing TDM voice network and their ATM and FR data networks, was originally built to provide only Internet access. Therefore, the IP network was able to benefit from a very straightforward approach to network design. That results in a small but flexible set of relatively simple configuration files for the routers, which simplifies the role of the engineering, operations, and support teams.

To follow the changes that happen in the configuration of the network as services are added, it is necessary to observe the configuration necessary to operate one of the edge routers. In this case, the router examined below is connected to the core with two OC-12 SONET links because of the large number of customers that it attaches to the network and the high bandwidth demands that these customers have.

Figure 2: Acme network design routing elements



The Acme network core routers each use BGP to interconnect the backbone network, as well as to connect to peering routers in other autonomous systems as necessary. In addition, all the routers in the network run OSPF as an interior routing protocol to ensure intra-domain connectivity.

In this simple IP routing scenario, the edge routers have a basic routing protocol configuration stanza:

Configuration Statement Purpose

protocols { Protocols configuration block. bgp { group internal { type internal; neighbor 10.0.1.22; neighbor 10.0.2.42; } }

Defines an internal BGP group with two peers (in this case, two different core routers.)

ospf { area 0.0.0.0 {

The OSPF configuration block defining area 0.

interface fxp0.0 { disable; }

Disables the management interface fxp0 from using OSPF

interface so-0/0/0.0; interface so-1/0/0.0

Names two interfaces on which OSPF is enabled.

} } ]

The protocol configuration stanza above provides BGP and OSPF routing to the core over the two OC-12 links, but on no other interfaces. OSPF routing is explicitly disabled on the management interface fxp0 to keep routing adjacencies from becoming established there in case of a mistake by operations staff. While the above configuration is sufficient for handling any amount of customer Internet traffic, it can be enhanced with protocol or traffic filtering, rate-limiting (policing), or other services on a per-customer or per-peer basis as needed.

NOTE The configuration examples in this paper are intended to provide simple examples of the most important steps in deploying the services discussed. They do not show every option or necessary step for service configuration, nor do they give in-depth configuration details. For complete information on configuring JUNOS on Juniper Networks products, please see the JUNOS Software Documentation at http://www.juniper.net/techpubs/.

Phase Two: Virtual Private Networking As a first step towards migrating some customers away from Frame Relay and ATM networking and onto their IP network, Acme has decided to address the needs of customers who use their Layer 2 networks as hub-and-spoke WAN networks. These are primarily used for supporting IP traffic for internal business processes, and also to carry Internet connectivity across an enterprise. Most of these customers use Frame Relay for this, because of its low cost and relative simplicity. For these customers, the fact that the data service is Frame Relay is incidental – it’s the IP networking that they are really after. Acme has concluded that many



current customers, as well as a significant number of potential new customers, would be interested in a provider-provisioned IP VPN service that runs over the Acme IP network, has all routing handled by Acme, and has the option of integrated Internet access. Such a service would allow many customers to offload the management of their own IP routing and the difficulties of reconfiguration and maintenance (for example, when adding a new site to the VPN) that are required when building a customer-provisioned VPN over Frame Relay.

The most convenient and cost-effective way to provide a service like the one described above is with a Layer 3 BGP/MPLS VPN service, also known as RFC 2547bis VPNs.

Adding MPLS to the Network

While not strictly required for every service they are interested in deploying, Acme realizes that deploying MPLS carries many advantages, including:

Multiple varieties of VPN capability

Traffic engineering for deterministic, predictable, efficient traffic paths

Fast reroute for < 50 millisecond error resolution

Integration with some 3rd-party equipment

Support for multiprotocol traffic carriage

Since these attributes are attractive to Acme in general, even beyond their ability to support the VPNs that they wish to deploy, Acme has decided to configure MPLS capability throughout their IP network.

Basic MPLS configuration involves three steps:

1. Configuring support for MPLS packets on the interfaces they will traverse

2. Configuring support for MPLS forwarding in general

3. Choosing and configuring an MPLS LSP establishment and maintenance protocol

Since MPLS packets will only travel within Acme’s network, and not directly to customers, only the internal interfaces of the routers must be configured for Step One. The single command that accomplishes this results in the following configuration stanza:


interfaces { so-0/0/1 { unit 0 { family mpls; } } }

Configures the SONET interface to recognize MPLS packets as valid input.



Step Two entails a single command for router-wide support for MPLS forwarding. It results in the following stanza:


protocols { mpls { interface all; } }

Configures MPLS forwarding for the entire router.

The final step requires Acme to choose a protocol for establishing and maintaining MPLS paths throughout the network. This choice will depend on the services that are desired by the provider, and might result in RSVP being chosen if traffic engineering is a requirement, or LDP being chosen for the simplest configuration, or even a combination of the two for some deployments. In Acme’s case, their initial requirement was simply to distribute MPLS labels for path creation and to indicate VPN destinations, and they therefore chose to use LDP for this. However, to support MPLS traffic engineering and allow the intelligent deployment of future services, they’ve decided to also implement RSVP across the network.

Configuring Traffic Engineering

To keep MPLS information inside the network, LDP and RSVP are configured only on the core-facing interfaces of the routers. In the case of router SJC-11, these are the two SONET OC-12 interfaces connecting to the core. The configuration of LDP and RSVP on SJC-11 results in the following configuration stanzas:


protocols { ldp { interface so-0/0/0.0; interface so-1/0/0.0; } rsvp { interface so-0/0/0.0; interface so-1/0/0.0; } ospf { traffic-engineering; } }

Configures the LDP and RSVP processes to operate on the two interfaces facing the network core, and asks OSPF to build a Traffic Engineering Database (TED).

With these three steps, MPLS is now running on the Acme IP network. MPLS packets can be generated by any router, and will follow an MPLS forwarding path to any other router. The utility of this is primarily in the edge-to-edge forwarding of MPLS VPN traffic.

At this point, LDP will discover the neighbor routers running LDP automatically, and MPLS LSPs will be dynamically created to all other MPLS destinations in the network. While this is sufficient to support VPN services, LDP does not provide control over the path taken by MPLS across the network. To control the path taken, LSPs must be established by RSVP signaling, which can be constrained to certain links and routers either manually or via various administrative constraints. The following configuration example shows one way of doing this:




protocols { mpls { label-switched-path to-denver { to 10.0.0.47; bandwidth 5m; } } }

Configures an MPLS LSP to a Denver router, and constrains the path it takes to links having at least 5Mbps of unreserved bandwidth.

By establishing this traffic engineering LSP using RSVP, the network engineers have taken control by specifying path attributes that must be met in order for the LSP to deploy. The Constrained Shortest Path First algorithm in the ingress router (in this case, SJC-11) will consult the Traffic Engineering Database to determine the shortest path meeting those constraints, and then signal the LSP along that path. This is only one example of the traffic engineering capabilities that RSVP makes possible. Acme is also able to constrain LSP paths based on their own administrative criteria, or simply to choose links or routers that must be included or missed in a particular path.

Deploying a Layer 3 BGP/MPLS VPN Service

Layer 3 VPNs based on IETF RFC 2547bis enable Acme to offer customers the ability to migrate from a model where each enterprise manages their own WAN VPN and routing to a fully outsourced model. In the outsourced model, the enterprise simply configures a static route to Acme’s IP/MPLS network and Acme manages the WAN VPN and ensures that packets are properly routed between sites. Taking over the responsibility for network routing allows Acme to provide a valuable service to enterprises that don’t wish to learn the intricacies of IP routing, while simultaneously providing a revenue opportunity for Acme.

As their name implies, Layer 3 BGP/MPLS VPN services use BGP to carry VPN membership and destination information across the network, and use MPLS labels to forward traffic toward a particular VPN site. As seen above, these requirements are already met by Acme; the BGP and MPLS already exist as a part of their service. All that remains is to configure the per-customer VPNs and their member sites.

Layer 3 VPN destinations are very similar to standard IP routing table entries, and are identical to them from the point of view of the customer. Each VPN instance on each edge router has its own dynamically created routing table (called a Virtual Routing and Forwarding table, or VRF) that identifies that VPN’s routable destinations and what label to use to reach them.



Figure 3: A Layer 3 BGP/MPLS VPN Deployment

Each site will receive a configuration stanza similar to the one below, for a fictitious company named Alpha:


routing-instances { alpha {

Defines and names an instance of the VPN for the company Alpha.

instance-type vrf; Specific to L3 VPN operation interface t1-0/0/1.0; Interface to which Alpha connects vrf-target target:1:1;

Invokes default VPN policies.

routing-options { static {

The routing protocols that control the routing between the sites.

route 172.16.1.0/24 discard;

A static route for the enterprise site.

} } } }

These commands need be issued only on the edge routers that actually host VPN sites; the core routers and non-participating edge routers need no additional configuration at all. This “configure it where you need it” philosophy of BGP/MPLS VPNs is a huge boon to service providers wishing to add services to their networks incrementally.

To learn more about Layer 3 VPNs, see “RFC 2547bis: BGP/MPLS VPN Fundamentals” located at http://www.juniper.net/solutions/literature/white_papers/200012.pdf


http://www.juniper.net/solutions/literature/white_papers/200012.pdf


Inter-site connectivity at Layer 2

While the Layer 3 VPN service is popular with enterprise customers who use only IP for their VPN and want to offload their routing to the provider, there are customers and applications for which it is not suited. If there are non-IP protocols to be carried, if the customer wishes to control his own IP routing across the network, or if the amount of control that the customer desires is very high, then the customer will likely want to maintain the Layer 2 WAN. In keeping with the desire to converge services onto a single backbone, Acme would like to support Frame Relay and ATM service emulation over the Acme IP network, and thereby avoid having to build separate Layer 2 networks to offer these services. This will reduce transport costs by eliminating long haul overlay links between the same city pairs and eventually reducing costs by obviating entire overlay core networks.

There are two distinct functions required by Layer 2 networking over IP/MPLS, encapsulation and signaling. Juniper Networks Layer 2 VPNs and Layer 2 circuits adhere to the PWE encapsulation standard (based on draft-martini.) Juniper supports two signaling options: Layer 2 Virtual Circuits use targeted LDP signaling, and Layer 2 VPNs use BGP signaling.

Customers who have ATM or Frame Relay VPNs with a large number of sites, or that may span multiple sites will probably choose to use L2 VPNs, because of the auto-discovery and multipoint connectivity benefits that BGP offers. Other customers who have only a handful of sites and will not need VPN services across multiple ASs may choose Layer 2 virtual circuits to build their own ad hoc VPNs. M-series routers allow either or both of these approaches to be used for each customer.

For more information on the comparative benefits of the various types of Layer 2 IP/MPLS networking, please see http://www.juniper.net/solutions/enabling_tech/layer2vpns/maximum_flexibility.pdf

Deploying a Layer 2 BGP/MPLS VPN Service

Layer 2 BGP/MPLS VPNs use mechanisms very similar to those used by Layer 3 VPNs in that BGP is used to distribute VPN routing information, and MPLS labels are used to forward packets to the correct VPN site. The essential difference is that while Layer 3 VPN destinations are IP prefixes, Layer 2 VPN destinations are circuit endpoints directly analogous to Frame Relay DLCIs or ATM VPI/VCI pairs. In fact, from the customer point of view, a Layer 2 VPN behaves exactly as its equivalent Layer 2 service does, which is what makes this service capability so attractive to customers accustomed to these services.

Figure 4: A Layer 2 BGP/MPLS VPN Deployment



Instead of the VPN-specific routing tables that are used to build a Layer 3 VPN, Layer 2 VPNs use the underlying BGP-based mechanism to build VPN Forwarding Tables (VFTs) that associate the destination circuit with a particular MPLS label (and therefore a particular LSP). The customer equipment is unaware that the Layer 2 service it is using is any different than a “traditional” Layer 2 network.

Since BGP and MPLS have already been deployed by Acme, the only steps required to institute a Layer 2 VPN are those involving the VFTs themselves, a process very similar to that used in configuring a Layer 3 VPN similar to the one above. These configuration items result in the following stanza:


routing-instances { gamma{

Defines and names an instance of the L2 VPN for Gamma.

instance-type l2vpn; Specific to L2 VPN operation. interface t1-2/0/1.0; Interface Gamma connects to. vrf-target target:1:1;

Invokes default VPN policies.

Protocols { VPN protocol configuration block. l2vpn { L2 VPN configuration block. encapsulation-type frame- relay;

Type of L2 VPN.

control-word; Allows carriage of control bits. site one { VPN site configuration block. site-identifier 1;

This site’s unique VPN ID.

interface t1- 2/0/1.0;

The VPN interface for this site.

Remote-site-ID 2;

The remote site connected to.

} } } } }

The VPN created by a configurations similar to the one above at each edge router that Gamma connects to is a Frame Relay VPN virtually indistinguishable from Frame Relay services deployed all over the world over ATM and other network infrastructures. For example, there are L2 VPN configuration options not shown here that allow for the support of Frame Relay and ATM options such as control bits (BECN, FECN, DE, CLP) and others. If Acme wishes at a later date to add support for, say, frame relay DE capability, they need only add a few lines to the customer-facing interface configuration:


interfaces { t1-2/0/1.0 { unit 0 {

Identifies the customer-facing interface and unit for the Gamma L2 VPN

family ccc { The protocol family for l2VPN translate-discard- eligible;

Allows mapping of the DE control bit into the VPN control word



} } } }

In this example, Acme makes it possible for a customer using Frame Relay to prioritize data traffic based on a customer-set parameter for discard eligibility (DE) which indicates to the customer equipment the degree to which certain traffic may be discarded in a congestion situation. The Juniper Networks platforms do not discard any traffic, but the customer equipment may become congested at times, making this marking useful. Note that Acme could also offer FECN and BECN capability with a similar command.

Deploying Layer 2 Circuits

As part of its convergence strategy, Acme would like to move as many customers as possible to IP/MPLS-based services, and away from ATM/Frame Relay-based services. By doing this, Acme can reduce transport costs by eliminating long-haul overlay links between the same-city pairs, and eventually reduce costs even further by eliminating entire overlay core networks. Part of that migration will involve replacing customers’ VPN services as shown above, but it will also involve replacing individual circuits with their IP/MPLS equivalents. The Layer 2 circuit capability in JUNOS is perfect for this.

Some customers may not need the multipoint connectivity of a Layer 2 BGP/MPLS VPN because the circuits they replace are simple point-to-point connections with no concept of multiple destinations. For situations like these, MPLS and LDP can be used together to deploy simple point-to-point Layer 2 circuits between any two points on the IP/MPLS network. Layer 2 circuits like these can be configured as part of a broader service offering, but may also be deployed ad-hoc as requested by individual customers.

Layer 2 circuits will utilize the same MPLS infrastructure as the Layer 2 and Layer 3 VPNs that Acme has already configured, but differ from the VPN offerings in that their circuit endpoint information is not carried by BGP, but rather by targeted LDP. To configure a Layer 2 circuit, the customer-facing interface must be configured with the correct encapsulation and the remote-edge-router-facing interface must have the destination router address configured as a neighbor. In this case, the customer wants to replace a single Frame Relay circuit with an equivalent Layer 2 Circuit:


interfaces { so-2/3/3 {

Identifies the interface that connects to the local customer.

encapsulation frame-relay-ccc; Specifies Frame Relay circuit encap. unit 722 { Unit (sub-interface) block. encapsulation frame-relay- ccc;

Specifies Frame Relay circuit encap.

point-to-point; Identifies the circuit as point-to-point. dlci 722; The local FR data link conn. ID. } } }



After the interfaces are configured, the following stanza will configure the Layer 2 Circuit between the two sites:


protocols{ l2circuit{

Defines the Layer 2 circuit.

neighbor 10.100.40.200 { The neighbor at the remote end. interface so-1/0/0.1 { The local customer interface. virtual-circuit-id 1; Uniquely identifies the circuit. no-control-word; Disables FR control information. } } } }

This is a simple example of Layer 2 circuit configuration. Acme may decide in the future, or for other customers with more complex needs, to support many of the options that the JUNOS software allows, such as control word transmission, translational switching, and others.

As a customer deploys multiple Layer 2 circuits, there comes a point where the management of those individual circuits – simple though they are – becomes more of a burden on the provider and the customer than a standard BGP/MPLS VPN would be. Customers who anticipate continued growth in their VPN connectivity requirements would do well to consider this from the beginning rather than have to change from one model to the other in the middle of their deployment, or allow the number of individual circuits to become too large to comfortably handle. In addition, Layer 2 VPNs provide a number of additional advantages such as site auto-discovery and pre-provisioning that enhance the provider’s ability to respond to customer needs.

Advanced Layer 2 functions

Many M-series Layer 2 capabilities that are not addressed in this paper, such as “hard” QoS enabled by DiffServ-aware MPLS traffic engineering, or ATM SCR, PCR, and MBS configuration for precise ATM service emulation, are possible. Please see Juniper Networks software reference materials for descriptions on how to configure these functions.

Deploying Layer 2.5 Interworking VPNs

As they continue the process of network convergence, Acme and its customers often encounter the need to connect VPN sites together, even when those sites do not use the same technology for VPN access. For example, an enterprise may wish to unite all their sites over a single Frame Relay Layer 2 VPN, but does not wish to replace all the circuits and equipment of a few legacy ATM sites. Layer 2.5 VPN capability is an extension to Layer 2 VPNs that offers the translation of one media type to another in order to allow sites using that media type to access the VPN.

For many network architects, Ethernet is the ultimate access technology, because it’s simple, fast, and ubiquitous. Unfortunately, Ethernet has not been available as a VPN technology until very recently, and switching to it will take time. Many of Acme’s customers are expressing an interest in moving to Ethernet VPNs (VPLS) gradually – that is, adding new sites to their VPN via Ethernet connections, but not migrating all their older VPN sites at the same time, simply because of the work that it would involve. Layer 2.5 VPNs allow this by



translating between the Ethernet and Frame Relay headers, and forwarding the frame contents unaltered.

Acme can use the Layer 2.5 VPN capabilities of the M-series to offer such a “translational VPN” service, either as a transitional step towards a more permanent, single-media Layer 2 VPN, or as part of a comprehensive multi-media VPN service.

Deploying Virtual Private LAN Service

Virtual Private LAN Service (VPLS) is an MPLS-based method for LAN interconnection over an IP/MPLS network. Some of Acme’s customers wish to connect their geographically remote Ethernet networks together over a non-routed network, and have them appear to each other as though they are actually connected over a simple bridge. This is interesting to customers because it allows for the simple support of anything that can be carried in an Ethernet frame, such as legacy protocols or certain specialized applications, but also because it allows even a geographically large network to be viewed as a single “flat” entity – with no hierarchy to complicate things. The elimination of a requirement for special skill sets to manage the WAN is also a bonus, since all connectivity is now over well-known Ethernet. This “inter-metro” Ethernet connectivity is a new capability that leverages the scalability of MPLS to carry Ethernet traffic across large areas and was not previously possible with standard Ethernet equipment due to broadcast storms and spanning tree instabilities.

Figure 4: A VPLS Deployment

VPLS uses the same transit and control protocol suite as Layer 3 and Layer 2 VPNs – a combination of MPLS and BGP. Because of this, much of the work of deploying the service was already accomplished during the configuration of those services.



BGP as a Service Control Protocol

Both equipment vendors and their service provider customers are using BGP in a number of increasingly popular service definitions. BGP was designed to be flexible precisely so that it could expand into new roles and grow with the service provider to integrate the control plane and the application plane, while preserving the interdomain characteristics that all providers now realize are critical to future growth. Furthermore, BGP is the only available mechanism that exhibits these crucial characteristics:

• It is a well-known and proven protocol.

• It allows the use of a single protocol to configure and provision all VPN types.

• It is the only solution that supports auto-discovery, which is critical for full mesh VPNs with more than a few end points.

• It supports scalable inter-AS and inter-provider VPN capabilities for carrier-of-carriers and interdomain VPNs, and is already being deployed in inter-carrier Layer 3 VPN networks.

Layer 3 VPNs, Layer 2 VPNs, and VPLS all specify BGP as the primary control protocol. For the exchange of many types of IP destination, VPN membership, site label, or other information, the BGP protocol provides an answer that is scalable, reliable, and has been proven in the Internet for almost ten years.

With the BGP and MPLS configuration already running, all that remains for the provider to do on each VPLS-providing router is configure the site-specific information, in this case for a customer site called Theta:


routing-instances { theta{

Identifies the instance of VPLS configured for the customer Theta

Instance-type vpls; Names the service as VPLS interface ge-1/0/0.501; The customer-facing interface vrf-target target:1:1; Simple import and export policy for

the community protocols{ vpls {

The protocol configuration stanza for VPLS.

site-range 2; Total number of sites in the VPN. site theta-1 { site-identifier 1;

Uniquely identifies the VPN site.

} } } } }



Other Advanced Layer VPN Functions

There are many other services that can be implemented using M-series through combinations of VPNs. For example, ACME could set up a VPLS service for a customer that carries both IP and non-IP traffic such as IPX and SNA. At the provider edge (PE), the M-series can recognize IP traffic that may be destined for an extranet partner and, using a ‘LT’ interface, map it from the VPLS domain into a Layer 3 2547 VPN. This type of advanced functionality is not discussed in detail in this paper. Please see Juniper Networks software reference materials for descriptions on how to configure these advanced services or contact a Juniper Networks representative.

Phase Summary

This phase has shown how Acme was able to deploy multiple types of VPN services on its M-series PE routers, and provide all these services over an IP/MPLS infrastructure that previously provided only best-effort Internet access. The M-series platforms that now provide these services have made a transition from Internet core routing nodes to multiservice delivery platforms in the process.

Phase Three: Additional Value-added services With many of Acme’s customers now using different forms of VPN in addition to their Internet service, Acme is able to offer its customers VPN-aware enhancements to these services that are based on additional capabilities of the M-series. By doing so, Acme can bring considerable value to customers in areas such as:

Traffic prioritization using Class of Service (CoS) mechanisms

Network address translation allowing Internet access from VPNs using private addressing

Security services to protect customer data and facilities.

In addition, Acme can use other capabilities of its M-series platforms to manage and account for an individual customer’s traffic:

Billing with Destination or Source Class Usage

Traffic accounting with traffic counters

Determining application resource usage with flow accounting

The following section will show ways in which Acme has use some of these M-series capabilities to offer its customers additional services, and has used others to manage and account for customer use.

Tiered Services Using CoS

Acme has a number of customers who would like to be able to prioritize different types of traffic over a single VPN, rather than building separate VPNs for different applications. A common example of this is when a customer wishes to support voice, client-server applications, and email over a single VPN. To accommodate this, Acme can use the JUNOS Class of Service (CoS) features in its M-series platforms to dedicate resources to that traffic of particular applications, while allowing best-effort traffic to use bandwidth not being used for priority traffic. The M-series is able to support multiple levels of QoS per customer regardless of media type, and each logical interface can support policing, shaping, strict priority scheduling, WRR, WRED/RED, and marking. This rich set of JUNOS CoS mechanisms



ensures that Acme can guarantee its customers specific levels of service that match the applications the customer wishes to run.

The JUNOS software allows a service provider to flexibly invoke many different CoS mechanisms, and to use them separately or in combination to prioritize traffic according to virtually any scheme. For customers who want to converge voice, VPN, and Internet traffic onto a common IP/MPLS VPN infrastructure, Acme can use the combination of a few simple classifiers and forwarding classes to prioritize the handling of these different types of packets. In this way, Acme can provide for the customer a valuable service while opening up a revenue opportunity that would otherwise be lost.

Figure 5: Configurable JUNOS CoS Parameters

In the JUNOS model, classification is the first CoS mechanism that a packet will encounter as it enters the incoming PE router interface. The components that work together to create a forwarding class, on the other hand, become important when the outgoing packet is queued for transmission.

Classification can be accomplished explicitly on packets that are already marked for priority with a particular IP precedence value or DiffServ codepoint, which is often the case with traffic from certain delay- and jitter-sensitive devices like voice gateways. On the other hand, explicit marking is relatively rare for standard IP applications like email and web traffic. For unmarked traffic, a multi-field classifier can be used to key on virtually any aspect of a packet and use that information to decide how the packet should be treated.

The Acme classification scheme uses a combination of explicit markings (performed by the voice gateways used by the customer) and multi-field classification (in this case, a range of destination addresses that indicate that the traffic belongs to the VPN) to perform classification.


firewall { The firewall configuration block. family inet { Firewall rules for IPv4 traffic. filter service-classifier { This filter is named “service-

classifier.” term voice { The term for voice traffic. from ( The identification clause. dscp af12; Identifies traffic with this DSCP.



} then forwarding-class assured-forwarding; }

Sets voice traffic to use the assured-forwarding forwarding class.

term vpn { The term that identifies VPN traffic from { The identification clause. destination-address { 207.17.127/17; }

Traffic with the destination address within this block is staying on the Acme network, and therefore VPN.

then forwarding-class expedited-forwarding; }

Assigns this traffic to the VPN forwarding class.

term be { This term identifies non-VPN traffic. then forwarding class best-effort; }

No “from” clause, so all other traffic is assigned to the BE class.

} } }

Once traffic has been classified, its future is determined by the forwarding class to which it has been assigned. Juniper Networks M-series platforms are equipped with four default forwarding classes (which may, of course, be altered by explicit configuration):

Best-effort

Expedited-forwarding

Assured-forwarding

Network-control

The best-effort and network-control classes are already set as required, but the classes used for voice and VPN traffic should be defined in line with the type of handling that their respective traffic types demand. Acme has set the following values:


class-of-service { The firewall configuration block. scheduler-maps { Firewall rules for IPv4 traffic. one { This filter is named “service-

classifier.” forwarding-class expedited-forwarding scheduler vpn;

The term for voice traffic.

forwarding-class assured forwarding scheduler voice; }

The identification clause.

schedulers { Identifies traffic with this DSCP. vpn { transmit-rate percent 30; priority low; }

Sets voice traffic to use the assured-forwarding forwarding class.

voice { transmit-rate percent 70; priority high; }



} }

When the filter named above is applied to the customer-facing interfaces, the customer traffic is classified as either voice (if it is pre-marked by the gateway with DSCP af12), VPN (if it has a destination address in the block 207.17.127/17), or best-effort (if neither of these conditions are true.) The classification assigns the traffic to a particular forwarding-class that evokes the suitable transmission and prioritization settings for that traffic.

Network Address Translation

Several of Acme’s Layer 3 VPN customers use private (RFC 1918) addressing in their VPNs, which presents a complication for Internet access from computers on those VPNs. Since these addresses are not routable on the Internet, the source addresses on their traffic must be translated to Internet-legal public addresses when accessing the Internet, and the destination addresses of the return packets must be similarly translated. While it is possible to do this at the CPE equipment, this involves configuration and management for the customer and requires a second access link for Internet traffic that goes through a firewall and then to Acme. Acme has decided to offer Network Address Translation (NAT) as an additional service for customers needing it, which will allow them to use a single access link for both WAN traffic and Internet access.

Figure 6: Public/Private Network Address Translation

By using the ASIC-based Adaptive Services PIC (AS-PIC) in the M-series edge platforms that host customers needing translation, Acme can translate private addresses at the provider edge and keep the customer from having to worry about NAT themselves. This translation service is a value-added service for which Acme charges a premium beyond its standard Internet connection fees.



To translate addresses, the configuration below is applied to the AS-PIC:


services { nat {

The NAT service configuration stanza.

pool public { Names the address pool address-range low 112.148.2.1

high/ 112.148.2.32;

The range of permissible public addresses to be assigned.

port automatic; }

Allows the router to assign the port number.

rule Private-Public { Names the translation rule.

match-direction input; The direction in which the match is attempted.

term Translate {

The first (and in this case only) term.

then { translated {

Since there is no “from”, all traffic matches and is translated.

source-pool public;

The address pool used (from above)

translation-type / source dynamic;

Specifies dynamically assigned source addresses.

} } } }

The configuration above will result in all packets from the customer site being reassigned a source address from the pool defined as “public” above. When replies to those packets are received by the M-series platform as they return to the customer site, the AS-PIC will replace that dynamically assigned address with the correct internal private address that matches it.

Adding Security

In order to protect its own network infrastructure and those of its customers, Acme implements some standard security procedures on all customer links. For example, many schemes for network denial-of-service and other malicious attacks depend on hiding the source of an attack by “spoofing” the source address. Acme can protect itself and its customers by ensuring that no packet leaves a customer site unless it is bearing a source address that legitimately belongs to that site. M-series platforms can use stateless firewall filters (also known as “packet inspection” firewalls) to check all outgoing packets for this property with a simple configuration such as the one below, which can be applied to the customer-facing interface:




firewall { family {

The firewall configuration stanza.

filter no-spoof{ Names the filter “no-spoof” term check-source { Names the term “check-source” from { source-address { 172.16.34/24; } }

Matches any packet with a source address in the range shown.

then accept; Allows those packets to pass.

} } } }

Since firewall filters implicitly deny any traffic not explicitly allowed (accepted), the configuration above allows only traffic with a source address matching the 172.16.34/24 block to exit the site. This address corresponds to the routing information that Acme holds for the customer, and ensures that – either by accident or intentionally – that traffic outside that range is never introduced to the Acme network.

The above configuration is a simple example of the capabilities of stateless firewalls implemented on M-series platforms, but many other matching options and actions are possible. The “from” stanza, which contains one or more matching rules, can use a wide range of identification values, including address, transport-layer ports, control bits and flags, CoS information, interface, length, and the like. Likewise, the “then” stanza, which controls the action to be taken upon a match, can allow, deny, count, log, forward, sample, redirect, and otherwise process the packet. The M-series architecture ensures that these procedures do not affect forwarding performance.

In addition to stateless firewall capability, the addition of a Juniper Networks M-series AS-PIC, like that used in the NAT example above, allows an M-series platform to implement stateful firewalls that are protocol-aware, and can therefore protect the network and customers from some types of attacks that are either difficult or impossible to protect against using stateless firewalls.

For example, for a customer who hosts a public web server, Acme may offer a service to protect that server from any types of traffic other than legitimate web requests that match the commonly-accepted definition of http traffic. With a stateful firewall, Acme can ensure that the requests meet all the rules of the protocol, and deny nefarious attempts to thwart firewalls with attacks made using parts of the protocol as a “cover”, for example UDP attacks on port 80 (the standard http port). By implementing the following configuration, Acme can guarantee the customer that the requests it passes to the customer web server are valid from the protocol point of view:




service stateful-firewall { rule only-http {

The stateful firewall configuration stanza for the rule “only-http”

match-direction output { Matches only requests toward the customer.

term 1 { The first (and only) term. from { destination-address { 172.16.34.4; } applications http; }

Matches packets bound for the web server address only if they are valid according to http.

then accept; Allows those packets to pass.

} } } }

M-series stateful firewalls can match a wide variety of applications with logic that ensures that only traffic that fits the protocol profile is matched, and this intelligence can be used to accept, deny, or otherwise process that traffic.

Other Advanced Services

There are many other services that were not covered in this paper such as IPSec, Multilink PPP, Multilink Frame Relay, Inter-provider VPNS, Carrier of Carrier VPNs, and many, many more. All of these services can be layered on top of the services we have already discussed to increase revenues. Please see Juniper Networks software reference materials for descriptions on how to configure these functions.

Conclusion This paper has shown how a provider like Acme can move from offering only a commodity – best effort Internet access – to offering a wide range of value added-services. The consequences of this transformation are cost savings and improved flexibility for Acme’s customers, a much broader set of revenue opportunities for Acme, and considerable competitive advantage for both Acme and its customers.

The Juniper Networks M-series platform is a central component of Acme’s plan. With a proven architecture that is deployed in the world’s largest IP networks, the M-series family is capable of providing multiple services – including premium data services, voice, Internet access, security services, network address translation, and others – on a single platform. The modular architecture of the M-series platform ensures that Acme need deploy only the number and types of equipment that fit its needs and budget, yet Acme retains the ability to add capacity and services as the company’s needs grow.



Crucial to the success of Acme’s deployment is the economy that comes from the many services that a single M-series platform can offer. With the M-series, there is no reason for separate security gateways, monitoring boxes, NAT servers, VPN endpoint, and the like. A single M-series platform is capable of offering all these services and more. Of equal importance is the ability of the M-series edge platform to support existing and emerging Layer 2 and Layer 3 services over a common IP/MPLS infrastructure. In addition to generating significant new revenues, Acme is able to dramatically reduce capital and operational expenses by consolidating ATM, Frame Relay, Ethernet, and all Layer 3 services onto one network.

Juniper Networks is committed to helping service providers offer the most compelling combinations of service offerings to their customers, and has spent nearly ten years honing the capabilities of the M-series family beyond those of carrier-class routing and packet forwarding, to the provisioning of true multiservice networks. Juniper Networks knows that in order to prosper, service providers have to move away from the simple world of pure Internet, and towards the more efficient and profitable world of infranets, where the services that customers need and are willing to pay for are endowed with reliability, connectivity, and ubiquity by their service providers. The M-series family is at the forefront of this migration to profitability

Copyright © 2004, Juniper Networks, Inc. All rights reserved. Juniper Networks is registered in the U.S. Patent and Trademark Office and in other countries as a trademark of Juniper Networks, Inc. ERX, ESP, E-series, Internet Processor, J-Protect, JUNOS, JUNOScope, JUNOScript, JUNOSe, M5, M7i, M10, M10i, M20, M40, M40e, M160, M-series, NMC-RX, SDX, T320, T640, and T-series are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. All specifications are subject to change without notice.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to changes, modify, transfer, or otherwise revise this publication without notice.


Documents

Multiservice Networking with the M-series · 2005. 3. 24. · Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408 745 2000 or 888 JUNIPER Part Number: 200047-001