Practical Application

 < Day Day Up > 



Now that we have seen the composition of the major types of MPLS VPNs, let’s have a look at some practical details of implementation. Applications vary from vendor to vendor, but there are generally three to four steps involved in establishing a Layer-3 VPN.

The steps to establishing an L3 VPN are as follows:

  1. Establish the core MPLS Network.

  2. Establish the MPLS tunnel.

  3. Create and map policies.

  4. Test and monitor.

Example 1: Layer-3 Encapsulation in MPLS

The following application example was provided by gracious permission of Riverstone Networks.

Packet Processing for L3 Encapsulation

RSVP-TE initiates the required tunnels through the core network to interconnect the required points of presence. Using any of the methods supported by RSVP-TE, explicitly routed with resource reservations or hop-by-hop, creates these tunnels. Once these tunnels link the edge routers, policy on the ingress router is used to classify and map the inbound traffic to a specific tunnel. All layer 2 information is stripped, and the native IP packet is encapsulated in the MPLS label for the specified tunnel and forwarded accordingly (see Figure 7.36).

click to expand
Figure 7.36: Example Network (1)

Creating the L3-FEC with Policy

The policy statements on the ingress MPLS router use information in the protocol header to classify inbound packets into an FEC. Policy is not limited to the ability to classify purely on source or destination IP address. Classification can look deep into the header information to include Source Socket, Destination Socket, Protocol, and Type of Service, as well as the base IP information. How the profile is created will depend on the end goal. For example, classifying based on prefix would map all packets from or to a prefix to a specific LSP. If more granularity is required, the Layer-4 socket information could be used to differentiate application types.

The following is a list of the classification criteria:

 RS (config)# mpls create policy <name> <classification> dst-ipaddr-mask          - Destination IP address and mask dst-port                 - Destination TCP/UDP port number proto                    - Protocol src-ipaddr-mask          - Source IP address and mask src-port                 - Source TCP/UDP port number tos                      - Type of Service tos-mask                 - The mask used for the TOS byte; default is 30

Once the policy is created, it must be associated to one of the existing RSVP-TE LSPs that has been created.

RS(config)# mpls set label-switched-path <name> policy

It is important to realize that this is not a Virtual Router solution. All edge routers participate in the native IP network to which they are connected; this means the route tables must have destination-based information for packets that must be forwarded from the MPLS core to the native IP network in which they reside. The core network does not have to be aware of any of the IP information that is not part of the MPLS core network; it is shielded from having to know those routes. Again, the beauty of using a dynamic signaling protocol means the configuration of the core network remains unchanged as new LSPs and policy are applied at the edge (see Figure 7.37).

click to expand
Figure 7.37: Network Diagram (2)

Steps to Delivering IP over MPLS

IP over MPLS can be summarized in three simple steps:

  1. Build the MPLS core network

    • IGP is required to distribute reachability information with traffic engineering. (Optional, but recommended)

    • MPLS and RSVP are required on all core facing interfaces, edge and transit.

  2. Edge routers initiate the tunnels using RSVP-TE.

  3. Define the L3-FEC, via policy, on the edges of the network and map to appropriate LSP.

Once again, it is important to remember that MPLS networks are unidirectional and need complementary label-switched paths running in each direction to facilitate bi-directional communications.

IP over MPLS Example

Using this network, the key configuration components will be described using the previous steps (see Figure 7.38).

click to expand
Figure 7.38: MPLS Block Diagram (3)

  1. All core-based transit label switch routers have the IP knowledge for core reachability, using either OSPF-TE or IS-IS-TE. The native IP routing information outside the MPLS core is not present in the core routing tables. MPLS must also enable on all core interfaces. A sample transit router configuration is presented below. All transit routers will follow this same basic configuration, with the obvious deviations, like IP addressing on interfaces.

    interface create ip Core1-LER1 address-netmask 192.168.1.1/30 port gi.3.1 interface create ip Core1-Core2 address-netmask 192.168.1.9/30 port gi.3.2 interface create ip Core1-Core3 address-netmask 192.168.1.13/30 port gi.4.2 interface add ip lo0 address-netmask 1.1.1.1/32 ip-router global set router-id 1.1.1.1 ospf create area backbone ospf add interface Core1-LER1 to-area backbone ospf add interface Core1-Core2 to-area backbone ospf add interface Core1-Core3 to-area backbone ospf add stub-host 1.1.1.1 to-area backbone cost 10 ospf start mpls add interface all mpls start rsvp add interface all rsvp start ospf set traffic-engineering on          

    Once the core MPLS network has been established, the edge routers need to be configured to participate as part of the core MPLS and native IP networks. Core facing interfaces require MPLS and RSVP-TE to be enabled. The interfaces facing the native IP network need to be created as participatory for the IP only network; no MPLS or RSVP-TE support is required. A sample configuration for one of the three edge routers is presented here:

    interface create ip To-Core address-netmask 192.168.1.2/30 port gi.3.2 interface create ip To-NativeIP address-netmask 172.16.1.1/24 port gi.4.2 interface add ip lo0 address-netmask 3.3.3.3/32 ip-router global set router-id 3.3.3.3 ospf create area backbone ospf add interface To-Core to-area backbone ospf add stub-host 3.3.3.3 to-area backbone cost 10 ospf start mpls add interface To-Core mpls start rsvp add interface To-Core rsvp start ospf set traffic-engineering on          

  2. The options for signaling the RSVP-TE tunnel from the edge network may include the use of traffic engineering, backup paths, or simply hop by hop. The simple example below initiates the end-to-end RSVP-TE without traffic engineering, using loopback address as tunnel start and end points.

  3. After the tunnels have been configured, the policy is defined it is associated to an LSP.

Here, three sites are interconnected by LSPs, and policy maps traffic to the appropriate LSP using a match of the destination IP address. The policies are written in such a way to allow any non-local traffic to be mapped to the LSP that has a connection to that remote site. None of the routes from any of the native IP networks are found in any routers, other than the edge to which they belong.

The IP addresses located at each site are important to note in order to understand how this policy has been written (see Table 7.10).

Table 7.10: IP Addresses at Each Site

Site Number

IP Address Within Site

1

172.16.1.0/24

2

172.16.2.0/24

3

172.16.3.0/24

LER1

mpls create label-switched-path LSP13 adaptive from 3.3.3.1 to 3.3.3.3 mpls create label-switched-path LSP12 adaptive from 3.3.3.3 to 3.3.3.2 mpls create policy Sub1Site2 dst-ipaddr-mask 172.16.2.0/24 mpls create policy Sub1Site3 dst-ipaddr-mask 172.16.3.0/24    mpls set label-switched-path LSP12 policy Sub1Site2 mpls set label-switched-path LSP13 policy Sub1Site3

LER2

mpls create label-switched-path LSP21 adaptive from 3.3.3.2 to 3.3.3.1 mpls create label-switched-path LSP23 adaptive from 3.3.3.2 to 3.3.3.3 mpls create policy Sub1Site1 dst-ipaddr-mask 172.16.1.0/24    mpls create policy Sub1Site2 dst-ipaddr-mask 172.16.2.0/24 mpls set label-switched-path LSP31 policy Sub1Site1 mpls set label-switched-path LSP32 policy Sub1Site2 

LER3

mpls create label-switched-path LSP21 adaptive from 3.3.3.3 to 3.3.3.1 mpls create label-switched-path LSP23 adaptive from 3.3.3.3 to 3.3.3.2 mpls create policy Sub1Site3 dst-ipaddr-mask 172.16.3.0/24 mpls create policy Sub1Site1 dst-ipaddr-mask 172.16.1.0/24 mpls set label-switched-path LSP23 policy Sub1Site3 mpls set label-switched-path LSP21 policy Sub1Site1               

If an inbound packet from the native IP network does not match a policy, normal routing rules apply: destination-based longest prefix match. However, in the case above, since prefixes are local and not propagated to the rest of the network, the packets are discarded.

Related Show Commands

Some useful show commands are presented in this section.

A detailed look at the policies shows information about each policy, including the classification criteria and the label-switched path that is used when there is a match:

 RS# mpls show policy <options>  LER# mpls show policy verbose

Name: Sub1Site2
Type: L3
Source address: anywhere
Source Port: any
Destination address: 172.16.2.0/24
Destination Port: any
TOS: any
TOS Mask:
Protocol: IP
Used by: LSP12

Practical Application Summary

This is only one vendor’s setup for an MPLS VPN, but we can see that it mostly follows the same top-level steps:

  1. Establish the core MPLS network.

  2. Establish the MPLS tunnel.

  3. Create and map policies.

  4. Test and monitor.

Now, let’s have look at two case studies where we will have further opportunity to examine applications of MPLS VPNs.



 < Day Day Up > 



Rick Gallagher's MPLS Training Guide. Building Multi-Protocol Label Switching Networks
Rick Gallahers MPLS Training Guide: Building Multi Protocol Label Switching Networks
ISBN: 1932266003
EAN: 2147483647
Year: 2003
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net