Packet Based Mpls Vpns

This chapter covers the following topics:

• MPLS VPN Operation— MPLS Virtual Private Networks can be built over existing Layer 2 infrastructures. This section details the various MPLS VPN building blocks and the interaction between the various MPLS elements. This section also explains VPN route target communities, distribution of VPN routing information, and MPLS forwarding. The various packet-based MPLS LSR commands used to build VPN networks are explained. These commands are later exemplified in the case study section.

• Verifying VPN Operation— Packet-based MPLS VPN operation can be verified using various IOS commands on the LSRs. This section illustrates the use of these commands in order to verify proper VPN operation. These commands can also be applied in an operations environment on production MPLS VPN networks.

• Case Study of an MPLS VPN Design and Implementation— This section presents a case study of a service provider with points of presence in Chicago, Seattle, San Diego, Miami, and Washington. The service provider offers MPLS VPN services to three customers across its backbone MPLS network. The customers operate a single VPN each. This case study reinforces concepts explained earlier in this chapter.

• The remainder of the chapter covers BGP route reflectors, inter-autonomous system MPLS VPNs, carrier-over-carrier MPLS VPNs, Internet access over MPLS VPNs, MPLS redundancy using HSRP, trace route enhancements, and MPLS VPN management using the Cisco VPN Solution Center.

A Virtual Private Network (VPN) is for all intents and purposes a set of sites sharing common Layer 3 routing information. Although MPLS VPNs are connectionless, they combine the benefits of Layer 2 switching with the connection-oriented Layer 3 routing paradigm to build VPNs. MPLS VPNs also offer secure communications by allowing only sites that belong to a VPN to exchange routing information.

This allows a service provider to build intranets and extranets and provide public Internet connectivity to these various VPNs over a common infrastructure that can also be used to provision ISP, ATM, and Frame Relay services.

The VPN feature for Multiprotocol Label Switching (MPLS) allows a service provider network to deploy scalable IPv4 Layer 3 VPN backbone services. These services can be deployed over a Layer 3 routed backbone or over an ATM backbone. This chapter explains deployment over a routed backbone. Deploying MPLS over an IP+ATM backbone is an extrapolation of the technology explained in this chapter and is covered in Chapter 6, "ATM-Based MPLS VPNs." Either approach allows a service provider to deliver VPN services in an integrated manner on the same infrastructure it uses to provide Internet services or other Layer 2 services such as connection-oriented Frame Relay or ATM VPNs. Currently, IP is the only Layer 3 protocol supported by Cisco's MPLS/VPN implementations.

[http://safari.oreilly.com/158705020X/ch05]

Copyright © 2002 O'Reilly & Associates, Inc. All rights reserved. 1005 Gravenstein Highway North Sebastopol, CA 95472

MPLS VPN Operation

Figure 5-1 illustrates an example of a VPN deployed by a service provider. It is in the service provider's best interes capability to provision scalable VPNs for its customers. Enterprise networks that own or lease private Layer 2 infras also deploy this technology.

Figure 5-1. MPLS Virtual Private Network

Figure 5-1. MPLS Virtual Private Network

The various MPLS components that are used to build a VPN include the following:

• MPLS core routers (P)— The core routers, also known as provider routers (P routers), do not maintain any They typically reside in a full- or partial-mesh configuration with other P LSRs and interface with provider e routers. P routers are never directly connected to customer routers.

• MPLS edge routers (PE)— Point-of-presence routers, also known as provider edge routers (PE routers), ma routes for VPNs that are members. They peer with the customer edge (CE) routers and interface to the core p PE routers peer with P routers or may be directly connected to other PE routers.

• Customer edge routers (CE)— The customer edge routers (CE routers) do not have to support MPLS and c conventional routing methods to achieve connectivity. The peer model requires a customer site to peer with c router as opposed to all other CPE or CE routers that are members of the VPN. CE routers are never directly routers.

• Customer routers (C)— The customer-owned internal routers, also known as C routers, do not have to supp can use conventional routing methods to achieve connectivity with the CE router and each other.

The VPN contains customer devices attached to the CE routers. The CE routers in either VPN can be connected to a service provider's PE routers. The PE routers connect to each other through a core network of P routers.

VPN Routing and Forwarding

Each VPN is associated with one or more VPN routing and forwarding instances (VRFs). A VRF defines the VPN r customer site attached to a PE router. A VRF consists of an IP routing table, a derived Cisco Express Forwarding (C

of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the inform; included in the routing table.

A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can be a membe VPNs, as shown in Figure 5-2. However, a VRF can only define a single VPN. A customer site's VRF contains all tl available to the site from the VPNs of which it is a member.

Figure 5-2. Multiple VPN Membership

Figure 5-2. Multiple VPN Membership

Packet forwarding information is stored in the IP routing table and the CEF table for each VRF. A separate set of roi tables is maintained for each VRF. These tables prevent information from being forwarded outside a VPN and also ] that are outside a VPN from being forwarded to a router within the VPN.

Each customer VPN must preserve the uniqueness of its IP addressing space. However, if two customer VPNs decic form an extranet by the controlled import of routes, they must preserve the uniqueness of their IP addressing by avo: address overlap.

The PE routers use the global IP table to forward IPv4 packets between each other. The VRF IP routing and forward used to forward information within the VPN. Because a PE router can have multiple VRF instances, each VRF IP ro forwarding table combination can be perceived as a virtual router within the physical PE router.

Each VRF IP routing and forwarding table combination contains routes that belong to one or more customer VPNs.

Limiting the routing protocol used within the VPN to a single VRF table supports overlapping VPNs (such as extrar support). Interfaces on PE routers are associated with individual VRFs. Routing information learned through these i associated with the configured VRFs and is known as the routing context. Some routing protocols such as RIP suppo instances or contexts of the same protocol, whereas other protocols such as OSPF require a separate copy of the roui process for each VRF.

VPN Route Target Communities

The distribution of VPN routing information is controlled through the use of VPN route target communities, implem gateway protocol (BGP) extended communities. The distribution of VPN routing information works as follows:

When a VPN route learned from a CE router is injected into Multiprotocol IBGP (MP-IBGP), a list of VPN route ta community attributes is associated with it when it is exported from the local VRF to be presented to other VRFs. Ty of route target community values is set from an export list of route targets associated with the VRF from which the r learned.

An import list of route target extended communities is associated with each VRF. The import list defines route targe community attributes that a route must have in order for it to be imported into the VRF. For example, if the import l particular VRF includes route target communities A, B, and C, any VPN route that carries any of the route target ext communities A, B, or C is imported into the VRF.

Distribution of VPN Routing Information

A service provider edge (PE) router can learn an IP prefix from a customer edge (CE) router by static configuration, session with the CE router, or through RIPv2 or OSPF sessions with the CE router. The IP prefix is a member of the family. After it learns the IP prefix, the PE converts it into a VPN-IPv4 prefix by combining it with a 64-bit route di (RD). The generated 96-bit prefix is a member of the VPN-IPv4 address family. It serves to uniquely identify the cu even if the customer site is using unregistered private IP addresses.

The route distinguisher used to generate the VPN-IPv4 prefix is specified by a configuration command associated w the PE router.

NOTE

BGP is an extremely scalable protocol that can support the provisioning of a large number of VPNs. BGP also : the exchange of routing information between routers not directly connected to each other. This is possible as lo is an underlying IGP such as OSPF or IS-IS that provides Layer 3 connectivity between the BGP peers. BGP al flexibility to carry optional parameters (attributes), which makes it the protocol of choice for use with the MPL architecture.

BGP distributes reachability information for VPN-IPv4 prefixes for each VPN. BGP communication takes place at t within autonomous systems (internal BGP or IBGP) and between autonomous systems (external BGP or EBGP). PE (route reflector) sessions are IBGP sessions, and PE-CE sessions are EBGP sessions. A separate E-BGP session bet CE router is required for each customer VPN.

NOTE

RFC 2283, Multiprotocol Extensions for BGP4, permits BGP to carry extended attributes. This technology forr of current implementations of MPLS, wherein the PE routers communicate with other PE routers using IBGP a core of provider P routers that do not participate in the BGP process. The PE routers form a full IBGP mesh.

BGP propagates reachability information for VPN-IPv4 prefixes among PE routers by means of multiprotocol BGP which define support for address families other than IPv4. It does this in a way that ensures that the routes for a give learned only by other members of that VPN, allowing members of the VPN to communicate with each other. The ac created to allow the Multiprotocol Border Gateway Protocol (MP-BGP) to carry protocols other than IPv4. The BG1 communities draft specifies two new communities defined as the route target and the route origin. The route target d and export policies for VRFs. The route origin is referred to as Site of Origin (SOO) in the Cisco implementation an routing loops between sites. MP-BGP propagates the extended community along with other BGP attributes between

NOTE

PE routers maintain and store routes for directly connected VPNs. This feature improves scalability by importii VPN IPv4 routes that are associated with VRFs configured on the PE router. However, BGP stores all BGP rou table, regardless of whether they are used by the VRFs or not. This consumes resources in terms of DRAM and in terms of bandwidth consumed for the advertisement of these messages to other PE routers. The Route Refres Automatic Route Filtering features provide methods to reduce the amount of BGP routing information that the needs to hold. However, none of these mechanisms prevents the arrival of unnecessary routing information to a

The Route Refresh feature ensures that a change in a PE router policy, such as an addition, deletion, or modific VRF, triggers the request for a retransmission of routing updates from its neighbors.

The Automatic Route Filtering feature automatically filters VPNv4 routes that contain a route target extended c that does not match any of the PE's VRFs.

Outbound Route Filters (ORFs) are locally configured outbound filters that prevent the unwanted routes from le source.

MPLS Forwarding

Based on routing information stored in the VRF IP routing table and the VRF CEF table, packets are forwarded to tl using MPLS.

A PE router binds a label to each customer prefix learned from a CE router and includes the label in the network rea information for the prefix that it advertises to other PE routers. When a PE router forwards a packet received from a across the provider network, it labels the packet with the label learned from the destination PE router. When the desi router receives the labeled packet, it pops the label and uses it to direct the packet to the correct CE router.

NOTE

The provider P routers do not take part in the MP-BGP process and don't carry VPN routes. They are not requir any routing decisions based on VPN addresses. The P routers forward packets based on label values of labels a IP packets. The P routers participate in MPLS label swapping, however do not teminate MPLS VPNs.

Unique identifiers such as loopback IP addresses with 32-bit masks (host routes) typically identify the PE routers. T addresses are used with the BGP next-hop attribute for VPN routes advertised by PE routers. Labels are assigned by the host routes and are transmitted to all neighbors. MPLS LDP ensures that all PE routers receive a label associated router. The MPLS network is ready to perform VPN packet exchange when the ingress PE router receives a label fo router.

Label forwarding across the provider backbone is based on either dynamic label switching or traffic-engineered path data packet carries two levels of labels when traversing the backbone. The first label forwards the packet to the corn router, and the second label indicates the VRF associated with the egress interface on the destination CE router. The mechanism is commonly called hierarchical tag or label switching.

When an IP packet is received through a particular interface from the CE, the PE associates it with a VRF, and a lab with the egress PE router (which identifies the target VRF and the outgoing interface of the egress PE router) is obta label). The PE router also obtains another label from the global forwarding table that points to the next-hop PE route and combines the two labels in an MPLS label stack. The label stack is attached to the VPN packet and is forwarded hop. The P routers in the MPLS network examine the top label and forward the packet correctly to the next hop acrc

At the egress PE router, the top label is stripped, and the bottom label is examined, which identifies the target VRF a interface. The bottom label is then stripped, and the IP packet is sent toward the correct CE router.

NOTE

An additional Layer 3 lookup is performed in the target VRF for summary VPN routes to determine a more spe

NOTE

The second-to-last router to the egress PE router might remove the top label in the label stack. This method of l stripping in MPLS is called penultimate hop popping. This method is used only for directly connected subnets o aggregate routes.

Configuring Router-Based MPLS VPNs

Your network must be running the following Cisco IOS services before you configure VPN operation:

• MPLS in provider backbone routers, or GRE tunnel connectivity among all PE routers

• MPLS with VPN code in provider routers with VPN PE routers

• BGP in all routers providing a VPN service

• CEF switching in every MPLS-enabled router

• Class of Service (CoS) feature (optional) NOTE

Cisco Express Forwarding (CEF) is a topology-driven switching architecture that isolates processing tasks to av contention for system resources. This approach stabilizes CPU processing, speeds up packet processing, and re network performance consistent and predictable.

CEF builds two main data structures: the FIB (Forwarding Information Base), which contains the best paths to destinations, and an adjacency table, which defines the next-hop forwarding information.

In order to enable CEF on the router, simply enter the command ip cef in global configuration mode.

The following tasks must be performed on the PE router to configure and verify MPLS VPN operation: Step 1. Configure your interfaces and IGP. Step 2. Define your VPNs. Step 3. Configure your PE-to-PE routing sessions. Step 4. Configure your PE-to-CE routing sessions. Step 5. Configure your P routers. Step 6. Configure your CE routers. Step 1: Configuring Your Interfaces and IGP To configure your interfaces and IGP, do the following:

Step 1. Enable CEF on the PE router in global configuration mode. CEF switching is essential for running M Router(config)#ip cef

Step 2. Configure the IP address of the loopback interface for use as an identifier in your IGP routing procesi Router(config)#interface loopback n

Router(config-interface)#ip address IP-address mask

Step 3. Configure your IGP. For this example, I have enabled OSPF routing, which places you in router conf

Router(config)# router ospf ospf-process-id

Step 4. Define an interface on which OSPF runs, and define the area ID for that interface:

Router(config-router)# network address wildcard-mask area area-id

Step 5. Configure the interfaces that connect to PE routers with an IP address. For this example, I have confi DS3 interface.

Router(config)#interface Serial slot/adapter/port Router(config-interface)#ip address IP-address mask

Step 6. Enable Tag Switching for the interface:

Router(config-interface)#tag-switching IP Step 2: Defining Your VPNs

As discussed, MPLS supports multiple VPNs for various customers and is extremely scalable. Each customer VPN : with a routing instance. In order to define VPN routing instances, follow these steps on the PE router:

Step 1. Define the various VPN routing and forwarding instances by assigning VRF names and entering VRJ mode:

Router(config)#ip vrf vrf-name vrf-name is the name assigned to the VRF. This must be a unique name used to identify the customer VPN. T case-sensitive. All customer CE routers, which are connected to the PE router, should have their VRFs define

Step 2. Create routing and forwarding tables for the customer VPN by identifying the VPN using a Route Di (RD). The RD is added in VRF submode. There is no default value for the RD. The RD must be configured i VRF to be functional.

The RD adds a 64-bit value to the 32-bit IPv4 prefix to create a 96-bit VPN IPv4 prefix. The RD creates rout forwarding tables and specifies the default RD for a VPN. The RD is added to the beginning of the customer' to change them into globally unique VPN-IPv4 prefixes. This permits VPN customers to use the same private scheme.

Router(config-vrf)#rd route-distinguisher

The RD is either ASN-relative, in which case it is composed of an autonomous system number and an arbitra is IP address-relative, in which case it is composed of an IP address and an arbitrary number:

ASN-relative format— 16-bit AS number : 32-bit arbitrary user number (ASN:nn). For example, 100

IP address-relative format— 32-bit IP address : 16-bit arbitrary user number (IP-address:nn). For e: 192.168.10.1:1.

NOTE

The RD does not have any semantics in either format ASN:nn or IP-address:nn and is interpreted by BC sequence of bits.

Step 3. Import or export routing information from or to the target VPN extended community. Create a route 1 community for the VRF using the route-target command in VRF submode. The route target specifies a targe extended community. Like a route distinguisher, an extended community is composed of either an autonomo number and an arbitrary number or an IP address and an arbitrary number.

Router(config-vrf)#route-target {import | export | both}

route-target-ext-community

Step 4. (Optional) Associate the specified route map with the VRF. Route maps can be created to apply polic VRFs. The route maps are configured in VRF submode. Use an import route map when an application requir over the routes imported into a VRF than that provided by the import and export extended communities conf importing and exporting VRF.

The import map command associates a route map with the specified VRF. You can filter routes that are elig into a VRF, based on the route target extended community attributes of the route, through the use of a route r map might deny access to selected routes from a community that is on the import list.

Router(config-vrf)#import map route-map

Step 5. Associate a VRF with an interface or subinterface. This is an extremely important step, because MPL physical interface with the VRF instance.

Router(config-if)#ip vrf forwarding vrf-name NOTE

Associating an interface with a VRF removes the IP address from that interface. The IP address should 1 reconfigured after an interface is assigned to a VRF.

Step 3: Configuring PE-to-PE Routing

To configure PE-to-PE multiprotocol IBGP routing sessions in a provider network, follow these steps on the PE rou Step 1. Configure the IBGP routing process with the autonomous system number passed along to other IBGI Router(config)#router bgp autonomous-system Step 2. Deactivate the advertisement of the IPv4 unicast prefixes: Router(config-router)#no bgp default ipv4-unicast NOTE

The preceding command lets MP-BGP carry VPN-IPv4 sessions only.

Step 3. Specify the neighboring PE's IP address or IBGP peer group identifying it to the local autonomous sy

Router(config-router)#neighbor {ip-address | peer-group-name} remote number

Step 4. Activate the advertisement of the IPv4 address family to your IBGP neighbors: Router(config-router)#neighbor ip-address activate Step 4: Configuring PE-to-CE Routing

The PE router needs to be configured so that any routing information learned from the customer interface can be ass particular VRF. This can be performed through standard routing protocol processes known as routing contexts.

There are four ways of configuring PE-to-CE routing:

• Static PE-to-CE routing configuration

• RIPv2 PE-to-CE routing configuration

• BGP4 PE-to-CE routing configuration

• OSPF PE-to-CE routing configuration

Customer VPN routes are placed in the VRF that is associated with the interface to which the CE router is attached. either as a separate routing process or as a separate routing context within a process per VRF. After the VRF is popu routes, these routes are advertised using MP-IBGP to other PE routers as VPN-IPv4 (VPNv4) prefixes. Address fam tell BGP which VRF routes to advertise. NOTE

The redistribution of CE routes into MP-IBGP is required for non-BGP PE-to-CE routing sessions. CE routes l through PE-to-CE EBGP sessions are automatically redistributed into MP-IBGP. In comparison to conventiona wherein IBGP routes are not permitted to be redistributed into the IGP, the VPN routes received through an MP session can be redistributed into the VRF.

Configuring Static PE-to-CE Routing Sessions

A static route for every destination IP subnet must be configured into the VRF on the PE router connected to the CE syntax is similar to static route configuration.

The static routing information is advertised between PE routers by redistributing it into IBGP. This is achieved by u redistribute command within the BGP address family configuration. The route-map command can be used to cont distribution of routes into IBGP during redistribution. This is useful to prevent specific static routes from reaching o of the same VPN.

To configure static route PE-to-CE routing sessions, follow these steps on the PE router: Step 1. Define static route parameters for every PE-to-CE session:

Router(config)#ip route vrf vrf-name Step 2. Define static route parameters for every BGP PE-to-CE routing session: Router(config-router)#address-family ipv4 [unicast] vrf vrf-name NOTE

The default is Off for auto-summary and synchronization in the VRF address-family submode.

Step 3. Redistribute VRF static routes into the VRF BGP table. This passes the static routing information pei VRF to all other PEs.

Router(config-router-af)#redistribute static Step 4. Redistribute directly connected networks into the VRF BGP table: Router(config-router-af)#redistribute connected Configuring RIPv2 PE-to-CE Routing Sessions

RIP version 2 can be run as a routing protocol between the PE and CE. The routing information received by the PE the CE is placed into the VRF associated with the physical interface connected to the CE. The VRF information is th via IBGP to the peering PE routers.

In normal RIPvl or RIPv2 routing, the network statements that define the RIP-enabled interfaces are placed under t routing protocol configuration submode. This would lead to the propagation of RIP routes in the global routing table routers. However, the intent is to maintain RIP routes within the closed user group VRF of the customer VPN. This by defining network statements in the address-family submode. Likewise, the redistribution of IBGP routes must b within the address-family submode as well so that VPN routes learned from IBGP are advertised to the CE router v process.

NOTE

Classful RIP version 1 (conventional RIP) does not support VLSM and is not recommended for MPLS PE-to-C

NOTE

RIP metrics can be transparently carried across the MPLS/VPN backbone by using the redistribute bgp metri transparent command, which causes RIP to use the routing table metric for redistributed routes as the RIP met the original metric being carried across the MPLS/VPN backbone in the BGP MED field.

To configure RIP PE-to-CE routing sessions, follow these steps on the PE router:

Step 1. Enable RIP version 2:

Router(config)#router rip Router(config-router)#version 2

Step 2. Define RIP parameters for PE-to-CE routing sessions in the address-family submode within the main configuration:

Router(config-router)#address-family ipv4 [unicast] vrf vrf-name NOTE

The default is Off for auto-summary and synchronization in the VRF address-family submode.

Step 3. Associate a network with the RIP routing process under the address-family submode:

Router(config-router-af)#network prefix

Step 4. Redistribute the IBGP routes into the RIP address family in order to advertise these routes toward the Router(config-router-af)#redistribute bgp asn metric metric Configuring BGP4 PE-to-CE Routing Sessions

Some MPLS/VPN customers might prefer BGP4 connectivity to the PE and prefer to exchange BGP4 routes with tl provider. All routes learned from the CE router are advertised across the MPLS/VPN backbone using MP-IBGP ses the service provider's PE routers. The redistribution between the customer EBGP sessions and the MP-IBGP sessior automatically.

NOTE

EBGP multihop is not currently supported on BGP sessions between PE and CE routers.

To configure BGP PE-to-CE routing sessions, follow these steps on the PE router:

Step 1. Configure an IBGP routing process with the autonomous system number passed along to other PE ro

Router(config)#router bgp autonomous-system

Step 2. Define EBGP parameters for PE-to-CE routing sessions by entering the address-family submode witl IBGP process configuration:

Router(config-router)#address-family ipv4 [unicast] vrf vrf-name

Step 3. Specify a neighboring CE's IP address or EBGP peer group identifying it to the local autonomous sys

Router(config-router-af)#neighbor {ip-address | peer-group-name} remote-as number

Step 4. Activate the advertisement of the IPv4 address family:

Router(config-router-af)#neighbor ip-address activate

Configuring OSPF PE-to-CE Routing Sessions

Many customers currently run OSPF as their intranet routing protocol. The routing information learned from custom OSPF is placed in the VRF associated with the interface connected to the CE router. These routes are advertised ove PE routers and are imported into the VRFs of other PE routers belonging to the same VPN.

The physical topology of most PE-to-CE links is point-to-point links without a designated router (DR). This preclud configuring OSPF network types. However, if multiple CEs connect to the PE over an NBMA network such as Fran manipulation of OSPF priority and the network type could be a requirement.

It is possible for a VPN customer to run an OSPF Area 0 between PE and CE router links for more than one site in t In this case, the CE router becomes the Area Border Router (ABR) for all other OSPF areas in the customer's intrans router acts as an ABR from the CE router's perspective, and vice versa. The PE router also acts as an ASBR for the < backbone. The PE and CE routers form an adjacency and exchange Link-State Advertisements (LSAs) across the ad CE router inserts summary LSAs from the customer to the PE router, and the PE router inserts summary or external customer routes coming across the OSPF-MPLS backbone.

Adjacencies are not formed between PE routers in the MPLS backbone. IBGP is run between the PE routers, and Oi translated into VPN-IPv4 routes. The redistribution of VRF OSPF routes into IBGP does not convert the OSPF rout OSPF routes when advertised to the other CEs.

NOTE

The down-bit is an extension of the OSPF protocol and is a part of the options field of the LSA header. Summa generated by the PE routers have the down-bit set.

In order to prevent routing loops from occurring when two or more CE sites are connected to the same Area 0, t routers propagate summary LSAs into the OSPF-MPLS backbone only if the down-bit is not set. This ensures t summary LSAs being propagated are generated by the CE routers.

It is also possible to configure the PE-to-CE link as a nonbackbone area. In this case, the PE router acts as an ABR a the CE and forms an adjacency with the CE for exchanging LSAs. The LSAs are placed into the customer VRF, wh redistributed into IBGP and advertised across the MPLS backbone as an intra-area route. When this route is receive« PE, it is imported into the customer VRF and is advertised as a summary LSA to the CE router at the far end.

NOTE

A separate OSPF process is required for each VRF that will receive VPN routes via OSPF. This is implemented VRF extension to the router ospf command in IOS.

To configure OSPF PE-to-CE routing sessions, follow these steps on the PE router: Step 1. Enable OSPF with VRF extensions:

Router(config)#router ospf ospf-process-id vrf vrf-name

Step 2. Define an interface on which OSPF runs, and define the area ID for that interface: Router(config)#network address wildcard-mask area area-id Step 3. Redistribute IBGP routes into the OSPF VRF process:

Router(config-router-af)#redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [metric metric-value] [metric-type type-value] [match internal | external 1 | external 2]

[tag tag-value] [route-map map-tag] [weight weight] [subnets]

NOTE

The redistribute command might need several options so that all IBGP routes are properly distributed i VRF.

Step 4. Access the address-family submode within the main IBGP process configuration:

Router(config-router)#address-family ipv4 [unicast] vrf vrf-name

Step 5. Redistribute VRF OSPF routes into IBGP through the address-family submode configuration:

Router(config-router-af)#redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [metric metric-value] [metric-type type-value] [match internal | external 1 | external 2]

[tag tag-value] [route-map map-tag] [weight weight] [subnets]

NOTE

The redistribute command might need several options so that all VRF OSPF routes are properly distrib IBGP.

Step 5: Configuring P Routers

The provider core routers (P routers) are LSRs that participate in the IGP routing protocol, such as OSPF or IS-IS. H do not take part in the multiprotocol IBGP process like the PEs would, so they have a simpler configuration. The P r terminate customer links from CE routers. The following shows the step-by-step configuration of a P router running

Step 1. Enable CEF on the PE router in global configuration mode. CEF switching is essential to run MPLS.

Router(config)#ip cef

Step 2. Configure the IP address of the loopback interface for use as an identifier in your IGP routing proces; Router(config)#interface loopback n

Router(config-interface)#ip address IP-address mask

Step 3. Configure your IGP. In this example, I have enabled OSPF routing, which places you in router confij

Router(config)#router ospf ospf-process-id

Step 4. Define an interface on which OSPF runs, and define the area ID for that interface:

Router(config-router)#network address wildcard-mask area area-id

Step 5. Configure the interfaces that connect to PE routers with an IP address. In this example, I have configi interface.

Router(config)#interface Serial slot/adapter/port Router(config-interface)#ip address IP-address mask

Step 6. Enable Tag Switching for the interface:

Router(config-interface)#tag-switching IP

Step 6: Configuring CE Routers

CE routers can be configured using one of four options:

• Static routing

• RIPv2 routing

• BGP4 routing

• OSPF routing

The PE router must be configured using the same routing protocol as the CE router. CE routers can be customer-ow provider-owned. Typically, if the service provider offers Managed IP VPN services, the CE router is owned and ma service provider. The customers are provided detailed IP architecture information and documentation to assist them numbering and internal intranet routing. Most service providers prefer to manage the CE router(s), especially if their solution is quite sophisticated. Troubleshooting this type of service is difficult if the Service Provider engineers don' access to the CE router.

CE Routers with Static Routing

To configure static routing for CE-to-PE routing sessions, follow these steps on the CE router:

Step 1. Configure the interface that connects to PE routers with an IP address. For this example, I have confi DS1 interface.

Router(config)#interface Serial slot/adapter/port Router(config-interface)#ip address IP-address mask

Step 2. Configure a default route to point toward the PE router as the next hop:

Router(config)#ip route 0.0.0.0 0.0.0.0 [PE-ip-address | CE-egress-interface]

CE Routers with RIPv2 Routing

To configure RIPv2 for CE-to-PE routing sessions, follow these steps on the CE router:

Step 1. Enable RIP version 2:

Router(config)#router rip Router(config-router)#version 2

Step 2. Associate a network with the RIP routing process under router configuration mode:

Router(config-router)#network prefix CE Routers with BGP4 Routing

To configure BGP4 for CE-to-PE routing sessions, follow these steps on the CE router: NOTE

As mentioned before, EBGP multihop is not currently supported on BGP sessions between PE and CE routers.

Step 1. Configure an IBGP routing process with the autonomous system number passed along to the PE rout

Router(config)#router bgp autonomous-system

Step 2. Specify the neighboring PE's IP address or EBGP peer group identifying it to an autonomous system: Router(config-router)#neighbor {ip-address | peer-group-name} remote Step 3. Specify the networks or subnets that are to be announced to the EBGP session: Router(config-router)#network network-number [mask network-mask] CE Routers with OSPF Routing

To configure OSPF for CE-to-PE routing sessions, follow these steps on the CE router: Step 1. Enable OSPF:

Router(config)#router ospf ospf-process-id

Step 2. Define an interface on which OSPF runs, and define the area ID for that interface:

Router(config)#network address wildcard-mask area area-id

[http://safari.oreilly.com/158705020X/ch05lev1sec1]

Copyright © 2002 O'Reilly & Associates, Inc. All rights reserved. 1005 Gravenstein Highway North Sebastopol, CA 95472

Verifying VPN Operation

To verify VPN operation, follow these steps:

Step 1. Display the set of defined VRFs and interfaces: Router#show ip vrf

Step 2. Display information about defined VRFs and associated interfaces:

Router#show ip vrf [{brief | detail | interfaces}] vrf-name

Step 3. Display the IP routing table for a VRF:

Router#show ip route vrf vrf-name

Step 4. Display the routing protocol information for a VRF:

Router#show ip protocols vrf vrf-name

Step 5. Display the CEF forwarding table associated with a VRF:

Router#show ip cef vrf vrf-name

Step 6. Display the VRF table associated with an interface:

Router#show ip interface interface-number vrf vrf-name Step 7. Display information about BGP VPN: Router#show ip bgp vpnv4 all [tags]

Step 8. Display label forwarding entries that correspond to VRF routes advertised by the router:

Router#show tag-switching forwarding vrf vrf-name [prefix mask/length][detail]

[http://safari.oreilly.com/158705020X/ch05lev1sec2]

Copyright © 2002 O'Reilly & Associates, Inc. All rights reserved. 1005 Gravenstein Highway North Sebastopol, CA 95472

Continue reading here: San Diego PE Configuration

Was this article helpful?

+1 0