Routehub TUNNEL L3VPN MPLS PDF

MPLS VPN
Tunneling: L3VPN
Practical Cisco Training for Network Engineers & Consultants!
RouteHub Group, LLC

www.RouteHub.net
January 23, 2009
Preface i
ROUTEHUB GROUP END-USER LICENSE AGREEMENT
END USER LICENSE FOR ONE (1) PERSON ONLY

IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS,
DO NOT OPEN OR USE THE TRAINING MATERIALS.
IMPORTANT! BE SURE TO CAREFULLY READ AND UNDERSTAND ALL OF THE RIGHTS AND RESTRICTIONS
SET FORTH IN THIS END-USER LICENSE AGREEMENT ("EULA"). YOU ARE NOT AUTHORIZED TO USE THIS
NETWORK CONFIGURATION GUIDE/TRAINING UNLESS AND UNTIL YOU ACCEPT THE TERMS OF THIS EULA.
This EULA is a binding legal agreement between you and ROUTEHUB GROUP, LLC (hereinafter "Licensor") for the
materials accompanying this EULA, including the accompanying computer Network Configuration Guide/Training, associated
media, printed materials and any "online" or electronic documentation (hereinafter the "Network Configuration Guide/Training").
By using the Network Configuration Guide/Training, you agree to be bound by the terms of this EULA. If you do not agree to
the terms of this EULA, do not install or attempt to use the Network Configuration Guide/Training.
The Guide & Training Materials shall be used by only ONE (1) INDIVIDUAL who shall be the sole individual authorized
to use the Guide & Training Materials throughout the term of this License.
1. Grant of License
The Network Configuration Guide/Training is protected by copyright laws and international copyright treaties, as well as
other intellectual property laws and treaties. The Network Configuration Guide/Training is licensed, not sold. This EULA grants
you the following rights:
A. You may use, access, display and run only one copy of the Network Configuration Guide/Training, on a single
computer, workstation or terminal ("Computer"). The primary user of the Computer on which the Network Configuration
Guide/Training is installed may make a second copy for his or her exclusive use for archival purposes only.
B. You may store or install a copy of the Network Configuration Guide/Training on a storage device, such as a
network server, used only to run the Network Configuration Guide/Training on your other Computers over an internal network.
You must, however, acquire a license for each separate Computer on which the Network Configuration Guide/Training is run,
displayed or utilized from the server or similar device. A license for the Network Configuration Guide/Training may not be
shared or used concurrently on different Computers.
C. Your license rights under this EULA are non-exclusive. All rights not expressly granted herein are reserved by
Licensor.
D. You may not sell, transfer or convey the Network Configuration Guide/Training to any third party without
Licensor's prior express written consent.
2. Price and Payment
If you have not previously paid the license fee for the Network Configuration Guide/Training, then you must pay the
license fee within the period indicated in the applicable invoice sent to you by Licensor.
3. Support Services
This EULA is a license of the Network Configuration Guide/Training only, and Licensor does not assume any obligation
to provide maintenance, patches or fixes to the Network Configuration Guide/Training. Licensor further disclaims any obligation
to provide support or to prepare and distribute modifications, enhancements, updates and new releases of the Network
Configuration Guide/Training.
4. Replacement, Modification and/or Upgrades
Licensor may, from time to time, and for a fee, replace, modify or upgrade the Network Configuration Guide/Training.
When accepted by you, any such replacement or modified Network Configuration Guide/Training code or upgrade to the
Network Configuration Guide/Training will be considered part of the Network Configuration Guide/Training and subject to the
terms of this EULA (unless this EULA is superceded by a further EULA accompanying such replacement or modified version of
or upgrade to the Network Configuration Guide/Training).
ii
Preface
5. Termination
You may terminate this EULA at any time by destroying all your copies of the Network Configuration Guide/Training.
Your license to the Network Configuration Guide/Training automatically terminates if you fail to comply with the terms of this
agreement. Upon termination, you are required to remove the Network Configuration Guide/Training from your computer and
destroy any copies of the Network Configuration Guide/Training in your possession. No refund with the product will be
granted.
6. Copyright
A. All title and copyrights in and to the Network Configuration Guide/Training (including but not limited to any
images, photographs, animations, video, audio, music and text incorporated into the Network Configuration Guide/Training),
the accompanying printed materials, and any copies of the Network Configuration Guide/Training, are owned by Licensor or its
suppliers. This EULA grants you no rights to use such content. If this Network Configuration Guide/Training contains
documentation that is provided only in electronic form, you may print one copy of such electronic documentation. Except for
any copies of this EULA, you may not copy the printed materials accompanying the Network Configuration Guide/Training.
B. You may not reverse engineer, de-compile, disassemble, alter, duplicate, modify, rent, lease, loan, sublicense,
make copies of, create derivative works from, distribute or provide others with the Network Configuration Guide/Training in
whole or part, transmit or communicate the application over a network.
7. Export Restrictions
You may not export, ship, transmit or re-export Network Configuration Guide/Training in violation of any applicable law
or regulation including but not limited to Export Administration Regulations issued by the U. S. Department of Commerce.
8. Disclaimer of Warranties
LICENSOR AND ITS SUPPLIERS PROVIDE THE NETWORK CONFIGURATION GUIDE/TRAINING "AS IS" AND
WITH ALL FAULTS, AND HEREBY DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS,
IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY (IF ANY) IMPLIED WARRANTIES OR CONDITIONS
OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE, OF LACK OF VIRUSES, AND OF LACK OF
NEGLIGENCE OR LACK OF WORKMANLIKE EFFORT. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, OF
QUIET ENJOYMENT, OR OF NONINFRINGEMENT. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE
OF THE NETWORK CONFIGURATION GUIDE/TRAINING IS WITH YOU.
9. Limitation of Damages
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR OR ITS
SUPPLIERS BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL, DIRECT, INDIRECT, SPECIAL, PUNITIVE OR OTHER
DAMAGES WHATSOEVER ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR INABILITY TO USE THE
NETWORK CONFIGURATION GUIDE/TRAINING AND WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT
LIABILITY OR OTHERWISE, EVEN IF LICENSOR OR ANY SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. THIS EXCLUSION OF DAMAGES WILL BE EFFECTIVE EVEN IF ANY REMEDY FAILS OF ITS
ESSENTIAL PURPOSE.
10. Arbitration
Any dispute arising under this EULA will be subject to binding arbitration by a single Arbitrator with the American
Arbitration Association (AAA), in accordance with its relevant industry rules, if any. The parties agree that this EULA will be
governed by and construed and interpreted in accordance with the laws of the State of California. The arbitration will be held in
California. The Arbitrator will have the authority to grant injunctive relief and specific performance to enforce the terms of this
EULA. Judgment on any award rendered by the Arbitrator may be entered in any Court of competent jurisdiction.
11. Severability
If any term of this EULA is found to be unenforceable or contrary to law, it will be modified to the least extent necessary
to make it enforceable, and the remaining portions of this Agreement will remain in full force and effect.
12. No Waiver
Preface iii
No waiver of any right under this EULA will be deemed effective unless contained in writing signed by a duly authorized
representative of the party against whom the waiver is to be asserted, and no waiver of any past or present right arising from
any breach or failure to perform will be deemed to be a waiver of any future rights arising out of this EULA.
13. Entire Agreement
This EULA constitutes the entire agreement between the parties with respect to its subject matter, and supersedes all
prior agreements, proposals, negotiations, representations or communications relating to the subject matter. Both parties
acknowledge that they have not been induced to enter into this EULA by any representations or promises not specifically
stated herein.
iv
Preface
Table of Contents
1 Introduction 8
2 Concepts 9
2.1 MPLS VPN 9
2.2 MPLS VPN: Infrastructure Components 9
2.3 MPLS VPN: Services 10
2.4 MPLS VPN: Sub-Services 12
2.5 MPLS VPN: Best Practices 14
2.6 MPLS VPN: Consideration and Risks 15
3 Design 16
3.1 Requirements 16
3.2 Solutions and Topology 17
3.3 Topology Services and Sub-Services 18
3.4 Hardware & Software 19
4 Configuration 20
4.1 Initial Configuration 20
4.2 MPLS VPN 21
4.3 MPLS VPN: Using Route Reflectors 32
4.4 MPLS over GRE 41
4.5 Extranet 52
4.6 VRF Selection 61
4.7 Traffic Engineering (TE) 70
4.8 MPLS QoS: Uniform Mode 87
5 Monitor 103
5.1 Operations 103
5.1.1 show ip vrf brief 103
5.1.2 show ip vrf detail 103
5.1.3 show ip vrf interfaces 104
5.1.4 show mpls ldp neighbor 104
5.1.5 show mpls forwarding-table 105
5.1.6 show ip bgp summary 105
5.1.7 show ip bgp vpnv4 vrf <vrf-name> 106
5.1.8 show ip route vrf <vrf-name> 106
5.1.9 show ip eigrp neighbor 107
5.1.10 show ip cef vrf <vrf-name> 107
Preface v
5.1.11 show mpls traffic-eng tunnels brief 108
5.1.12 show mpls traffic-eng link-management bandwidth-allocation 108
5.1.13 show ip cef vrf <vrf-name> 109
5.1.14 show mpls traffic-eng tunnels Tunnel 1 110
5.1.15 show policy-map interface for MPLS QoS 110
5.2 Traffic Flow for MPLS 112
5.2.1 Understanding MPLS Labels 112
5.2.2 MPLS Labels in Traceroutes 112
5.2.3 MPLS: Bottom Label 112
5.2.4 MPLS: Top Label 112
5.2.5 MPLS: PUSH, SWAP, and POP 113
5.2.6 Traffic Flow Example 114
5.3 Traffic Flow for MPLS QoS 116
5.4 Troubleshooting 119
5.4.1 Root Causes 119
5.4.2 Initial questions to ask 119
5.4.3 Typical fixes 120
5.4.4 General MPLS Troubleshooting 120
6 Full Configuration 121

6.1 MPLS VPN 121
6.1.1 ROUTEHUB-P 121
6.1.2 ROUTEHUB-PE1 122
6.1.4 ROUTEHUB-CE1-A 127
6.1.6 ROUTEHUB-CE1-B 129
6.2 MPLS using Route Reflectors 132
6.2.4 ROUTEHUB-RR 138
6.2.5 ROUTEHUB-CE1 139
6.3 MPLS over GRE 141
6.3.1 INTERNET 141
6.3.2 ROUTEHUB-P1 142
6.3.6 ROUTEHUB-P2 149
vi
Preface
6.4 Extranet 156
6.5 VRF Selection 166
6.5.7 ROUTEHUB-HOST5 175
6.5.8 ROUTEHUB-HOST6 176
6.6 MPLS QoS: Uniform Mode 177
6.6.5 ROUTEHUB-C1 185
6.6.7 ROUTEHUB-C2 188
Preface vii
1 Introduction
Many site focused on providing training towards certifications or exams. These are important
for career development and we have CCIE, CCNP, and CCNA certifications. So we know
that they are very valuable to your network engineering career, however, they do not teach
practical network training relevant for network engineers and consultants in the real world.
This is what our training format is based upon providing practical solutions and technologies
that are deployed in real working environment. Our training workbooks provide the four
major components:
Concepts
Design
Configuration
Monitor
Learn the concepts that matter in terms of the components and protocols involved for a
technology's operation.
Learn how to design a network solution with practical steps, considerations, and tools for
your company or clients.
Learn how to configure a network with best practices and get operational step-by-step. We
also include full working configuration files for our workbooks.
Learn how to monitor, troubleshooting, and confirm the operational state of your configured
network.
All four are important for network engineers and consultants to know how to manage a
network in real time.
RouteHub Group, LLC Page 8 www.routehub.net

2 Concepts
2.1 MPLS VPN

MPLS or Multi-Protocol Label Switching Protocol has the most common misperception on
this operational purpose. Many think MPLS is a technology that deals with isolating routing
domains on the same physical hardware or infrastructure.
That is not correct, MPLS VPN is a label switching technology that work by making VRF
domains scalable across many sites.
VPN Routing and Forwarding (VRF) is the technology that allows isolating layer 3 domains
on the same physical hardware or infrastructure.
2.2 MPLS VPN: Infrastructure Components

An MPLS infrastructure can consist of the following components
Provider Core (P)

Provider Edge (PE)
Customer Edge (CE)
Customer Core (C)
2.2.1 Provider Core or P router

A Provider Core or P router is considered as the MPLS Core connecting other P routers and
PE routers together for label switching. No VRF or MP-BGP is configured on the P router
since it is not directly connected to a client site.
2.2.2 Provider Edge or PE router

A Provider Edge or PE router is the component that is directly connected to the client or CE
site. It also connects to one or more P routers within the MPLS network. VRF instances are
configured on PE routers including MP-BGP sessions configured with other PE routers on the
network.
2.2.3 Customer Edge or CE router

A Customer Edge or CE device is the component that is located at the client's location
directly connected with a PE router within the MPLS cloud. The client's edge router would be
connected into our LAN Core (or Customer Core or C device). No MPLS, VRF, or MP-BGP

configuration is needed or required on the CE or C devices. They are configured normally as
if they are configured with an ISP without MPLS.
One or more of these components exist within an MPLS network. It's important to identify
these components in our MPLS design.
2.3 MPLS VPN: Services

Among our MPLS infrastructure the following protocols and technologies can exist.
MPLS VPN consists of the following components:
VPN Routing and Forwarding (VRF)

o Route Distinguisher (RD)
o Route-Targets
IGP Routing: OSPF, IS-IS
Labels
o Label Protocol: LDP, TDP
Multi-Protocol BGP (MP-BGP)
VPNv4 prefixes
2.3.1 VPN Routing and Forwarding (VRF)

As a recap, VPN Routing and Forwarding (VRF) is the technology that allows isolating layer 3
domains on the same physical hardware or infrastructure. A VRF is configured with a name
to identify the VRF instance, an arbitrary number called a route distinguisher (RD) that is
unique, but the same for all VRF instances similar to the VLAN ID for Layer 2 networks, and
route targets that reflects what traffic can be imported into a VRF or exported from this VRF
that is associated with its RD ID.
2.3.2 IGP Routing: OSPF, IS-IS

An IGP routing protocol is configured among all MPLS components for obvious reasons
(connectivity), but the main reason is to provide routing connectivity between all PE devices
in order to establish MP-BGP peers. OSPF or ISIS is recommended due to the available
protocol extension options with other MPLS sub-services such as Traffic Engineering (TE).
2.3.3 Labels
Label Switching
Label Switching is a mechanism that allows label switching of MPLS pckets across an MPLS
network using either the LDP or TDP label switching protocols. LDP is the recommended
protocol to use.
TOP and BOTTOM Labels

As MPLS packets travel through the network they consist of labels which may contain a TOP
LABEL and a BOTTOM LABEL.

The TOP label is placed by the Label protocol which can be TDP or LDP
The Bottom label is placed by the MP-BGP protocol.
PUSH, SWAP, and POP

As MPLS packets travel through the MPLS networks the top label can be added, removed, or
swapped with a different top label. You can see MPLS labels as a mechanism for knowing
how to forward MPLS packets through a network between other MPLS components.
How MPLS labels are handled is based on what MPLS components it travels through.
Labels exchanged from PE to P devices, the top label is PUSHED or ADDED to the MPLS
packet.
Labels exchanged from P to P devices; the top label is SWAPPED with a different top label
unique for that second P device.
Labels exchanged from P to PE device, the top label is POPPED or REMOVED leaving only
our bottom label which then on our PE device knows how to handle the MPLS packet.
Label Switch Router (LSR) is another term for an MPLS router for switching labels between P
and PE devices. Another term used is Label Switching Path (LSP) which is used to reflect
the path of labels switched between PE routers for routing to certain VPNv4 prefixes (or
routes in the case of CE devices) across an MPLS network.
2.3.4 VPNv4 prefixes

A VPNv4 prefix is a route that is learned from a CE network within a particular VRF instance.
That subnet is appended with the Route Distinguisher (RD) ID that was configured when the
VRF was created on the PE router. This is basically doing a translation in becoming a
VPNv4 prefix. So, for example, and there is a subnet of 10.67.78.0 /24 located in the VRF
called "ROUTEHUB". Within that VRF all subnets are mapped with RD ID 10:100 as an
example. Thus our translation would give us the following VPNv4 prefix of
10:100:10.67.78.0. This VPNv4 prefix is what is sent across as MP-BGP updates to other
PE routers where that info is translated back by stripping off the RD ID. The RD ID part of
the subnet is what makes having overlapping IP addresses or subnets possible because the
RD ID would be unique per VRF instance.
2.3.5 Multi-Protocol BGP (MP-BGP)

Multi-Protocol BGP (MP-BGP) or iBGP is a protocol used between all PE routers for sending
VPNv4 prefixes (VPN information) between PE devices on the subnets learned from the CE
then translated to a VPNv4 address (which means appending the RD ID) and are sent across
as MP-BGP updates. MP-BGP updates would also consist of the labels and route-target
info.

2.4 MPLS VPN: Sub-Services
2.4.1 Route Reflectors

This is a best practice approach that is recommended for scalability and reliability reasons.
Without BGP Route Reflectors then all PE devices (within the same ASN) require to be full-
meshed with all other PE devices due to the interworking of iBGP. This can lead to high
number of iBGP peers to manage bringing high complexity to the design. Therefore, it is
recommended to add a Route Reflector (or two for redundancy) where all PE devices would
only peer with the Route Reflector routers on the MPLS network. The Route Reflectors
would peer between each other and all the PE routers on the network. If one RR fails then
the PE's would use the other RR for routing among the PE devices.
2.4.2 VRF Selection

This is a sub-service within MPLS that allows configuring the use of multiple VRF instances
on a single physical interface. Normal VRF configuration means a single VRF instance is
assigned to a single interface(s). However, the use of multiple VRF instances can be
mapped based on the source or destination traffic specified in an ACL policy that is applied to
route-targets.
2.4.3 Traffic Engineering (TE)

MPLS Traffic Engineering (TE) allows engineers to statically or dynamically determine the
LSP between PE routers that are usually determined via OSPF/ISIS routing mechanisms.
MPLS TE has an extension into OSPF and ISIS to learn route information details on the
MPLS networks. This information is used mainly for dynamic TE tunnels for how they are
built across the MPLS network. Static TE tunnels are configured based on the path that is
manually specified by the engineer.
Traffic Engineering allows an ISP to route network traffic and offer best service for better
control of throughput and delay.
TE uses RSVP not only for maintaining the bandwidth for a link, but to provide signaling of
Label Switch Paths (LSPs) across the MPLS network. Using signaling with RSVP the MPLS
router will know what resources are available for building a TE tunnel across an LSP. It
accounts for the link bandwidth and the size of the traffic flow when determining routes for
LSP across the MPLS network.
Using Dynamic TE tunnels, they can automatically rebuild TE tunnels across a different path
that has enough bandwidth available for a certain link.
TE tunnels utilize the OSPF or IS-IS routing table (hence the TE extension into one of those
two routing protocols) for understanding the routing topology of the network and uses that
info for building TE tunnels.
Lets explain this further with an everyday example. Let's say we get $100 per month. Let's
saw we spend $20 per month for Netflix, $50 per month for Starbuck coffee, and $30 per
month for a video game subscription. Well if I want to get a $50 per month subscription for a
Cisco network lab website, I will be unable to do so because I'm out of money. We are

oversubscribed unless we cancel or lower some of the other services to equal $100 or less.
Now back to MPLS TE, the $100 is seen as our RSVP and our TE tunnel is seen as the
services (Netflix, Starbucks, Video Gaming), so that would mean 3 TE tunnels that can be
static or dynamic. We can also configure certain priorities with our TE tunnels, maybe on
critical tunnels with a higher preference to be built compared to other TE tunnels that may not
be formed but still routing normally between PE sites.
2.4.4 Extranet
MPLS Extranet is a sub-service that is sometimes termed to deal with routing between other
VRF instances that are usually isolated by adding policies within the route targets. The
route-targets is what we configured under our VRF instance in the beginning and this is what
the VRF uses to know what traffic can be routed (export) and what can be routed into a
particular VRF (import).
2.4.5 MPLS over GRE, MPLS over DMVPN

Different MPLS networks with their own group of MPLS devices such as P or PE routers,
VRF instances can be connected with other MPLS networks across the Internet for example.
Two MPLS networks can be connected together using a virtual tunnel like GRE or even with
VPN technologies like DMVPN or even IPSec with GRE. These deployments are pretty
common for quickly connecting two MPLS network across the Internet especially if two
service providers are merging together and need to extend VRF connectivity across different
MPLS domains.
2.4.6 MPLS and Quality of Service (QoS)

QoS mechanisms can exist across an MPLS network using a DiffServ or IntServ model.
MPLS Traffic Engineering (TE) uses more of a IntServ QoS model by using RSVP and
providing guarantee of bandwidth services through the network.
A DiffServ QoS model or DiffServ Tunneling Mode with MPLS is when the CE site is marking
their IP packets using DSCP or IP Precedence values for real time traffic like Voice or critical
data. When the marked IP packets reaches the MPLS the mechanism changes where
instead of using DSCP or IP Precedence, MPLS P and PE routers use MPLS EXP bits.
MPLS QoS can be configured in one of three modes: Uniform mode, Short Pipe Mode, and
Pipe Mode.
2.4.6.1 Uniform Mode

Uniform mode is the default if no other mode is configured, through some additional
configuration is needed. With Uniform mode, it's usually used when the DiffServ domain is
the same and trusted for the Client and Service Provider.
Traffic within the CE is marked to some DSCP or IP Precedence value. When the IP packet
reaches the MPLS network the QoS markings are mapped automatically to MPLS EXP. No
configuration is needed. As the packet travels through the MPLS network when it travels
from the P to the PE router the top label is POPPED (or removed). The MPLS EXP info is
copied to a temporary holding place called a QoS group. When the packet goes from the PE

to the CE the bottom label is removed and the MPLS EXP info in the QoS group is copied to
the IP header ToS bits (DSCP or IP Precedence).
If a policer is in place somewhere on the MPLS (like the P router) it may mark down the
MPLS packet to a lower EXP value, that info will also be copied to the IP header ToS field
changing what we recently assigned from our source CE site.
Remember they share and trust the same DiffServ domain.
2.4.6.2 Short Pipe Mode

Short Pipe and Pipe Mode are really the same expect for what happens at the egress
(outbound) point to the CE.
With Short Pipe, the provider explicitly specifies what the QoS policy will be and what MPLS
EXP they will be mapped to. Therefore, it is important to understand the ISP QoS classes
and policies then making sure that the CE matches their outbound QoS with the ISP. This
ISP policy may consist of a QoS policer that may drop or lower the QoS markings through the
MPLS. Keep in mind that a CE IP packet encapsulated in a MPLS packet is not being
touched or changed. As the packets travels from the PE to the CE router the policies are
based on the customer markings where the original customer marked packets are preserved.
2.4.6.3 Pipe Mode

Pipe Mode is the same operation as Short Pipe except as packets travel from the PE to the
CE the policies are based on provider markings. Again the original customer marked packets
are preserved.
2.4.6.4 Short Pipe vs. Pipe Mode

If these modes are pretty much the same then what are the Pros and Cons and when to use?
Simple, it is based on the PE to CE egress policies defined. With Pipe mode, shaping and
queuing is implemented providing proper ISP end-to-end QoS operations for CE traffic
forwarding.
Where Short Pipe all outbound PE interface resources are shared for all traffic type.
Meaning potentially voice packets may have to contend with large data packets resulting in
possible delay, loss, and jitter.
2.5 MPLS VPN: Best Practices

Use LDP for Label Exchange across MPLS
For PE MP-BGP peering use redundant Route Reflectors
Use MPLS standards for VRF names, number, and CE VRF routing instances

2.6 MPLS VPN: Consideration and Risks
MPLS does not encrypt data only uses labels for switching packets between PE
devices on the MPLS network
MP-BGP relies on IGP, LDP, and MPLS operations to be working
MPLS relies on LDP to be working
LDP relies on IGP to be working
IGP relies on network connectivity to be working

3 Design
3.1 Requirements
First, we need to determine all the business and technical requirements. Understand what is
needed, the expectations involved, budgetary considerations, network services, security
regulations, and more much outlined by the company or business
We would gather details for building our design based on the following:
Requirements and Expectations
Traffic
Budgetary Considerations
Existing Components and Services
Technical Objectives
The technical objectives are what define best practices and recommendations in a network
design. These are often challenges that many networks face early or further down the road
with a network. When there are issues its usually due to one of the objectives that were no
met or considered during the design phase.
Below are the technical objectives our design should consider, include, and bring up with the
requirements gathering:
Performance
Reliability
Scalability
Security
Flexibility
Network Management

3.2 Solutions and Topology
Once the requirements and objectives have been gathered, that info will help us with the
design process of our solutions and topology.
At a high level the solutions is the network that deals with a specific function or task based on
the requirements gathered. Many network solutions listed here do require the existing of
other solutions to work. The one network solution that is required for all solutions is the LAN
solution which is essentially the network backbone that connects all the other solutions
together.
Below are the solutions we can choose from.

Local Area Network (LAN)
Wide Area Network (WAN), Metropolitan Area Network (MAN)
Voice & Unified Communications
Internet Edge
Wireless
Data Center
Once the solutions have been determined it is time to build our topology. The topology is
basically the framework in our design that doesnt contain any technologies, services,
protocols, or hardware devices by name yet. We are essentially just building a street with
nothing on it.
There are many ways to build a design and usually common topologies and case studies are
often used.
These topologies really include tier levels in the design. One way to explain is with a LAN
topology which is often discussed in many networking textbooks. A best practice and
recommended LAN would consist of a LAN Core, LAN Distribution, and LAN Access. This is
a tier level model consisting of 3 tier levels, each with a certain ideal purpose.
A LAN Access provides direct access to nodes like computers, printers, IP Phones, access
points, etc. LAN Distribution deals with aggregating the traffic from the Access layer
including other roles with routing, switching, and security policies. And the LAN Core is seen
at the backbone where the LAN Distribution connects into providing high-speed switching
and forwarding. This three tier model accommodates much of the technical objectives
especially with scalability and reliability among others. But a 3-tier model is often seen with
larger networks.
Some solutions typically can have 1 or 2 tiers in most designs. Again 3 tier designs are often
seen with large size networks or very large networks. But some of the tier levels can be
consolidated where needed and the hardware that you choose that can also change the tier
level in the design. For example, an Internet Edge solution typically consists of 3 tiers (the
Edge Router, the Edge Switch, and the Perimeter Firewall). Well nowadays the edge switch
has been eliminated being integrated with the Edge Router leaving us with a 2 tier model,
which is the most common, however, the firewall services can also be integrated with our
Edge router that provide stateful firewall inspection with capabilities such as rACL (Reflexive
ACL) or CBAC. Thus, our Internet Edge device can be a 1 tier model.
2 tier models are very common for small and medium sized networks.

3.3 Topology Services and Sub-Services
Once the topology has been determined (or narrowed down), the next thing to determine is
the topology services that will overlay on-top of our topology.
This can include the following services:

Routing & Switching
Security & VPN
Tunneling
Voice & Unified Communications
Wireless
Other Technologies (like QoS and HSRP)
Topology sub-services deals with the extended features within the services within the
network design.
For example, one of our topology services could be Routing using OSPF. Well OSPF has
many design considerations and best practices that can include configuring route
summarization within a LAN Distribution to send summary routes up to a LAN Core. A
common best practice discussed with OSPF including Stub routing within the LAN Access
network among other sub-services.
For MPLS, which is a topology service, these are sub-services that can be deployed with
MPLS.
General
Route Reflectors
VRF Selection
Traffic Engineering (TE)
Extranet
MPLS over GRE, MPLS over DMVPN
QoS service to MPLS VPN
IPv6
Internet Access service
Multicast service to MPLS VPN

3.4 Hardware & Software
Determine the best hardware and software solutions for each component in the design to
accommodate the following points:
Requirements
Topology Service and Sub-Services
Business Size considerations
The hardware device can be any vendor besides Cisco. Make sure the hardware chosen
supports the requirements and services in our design including considerations for the
business size of the network and the technical objectives.

4 Configuration
4.1 Initial Configuration

The first we need to do is console or connect into each device on our network based on the
information presented in the network diagram.
Second, complete all basic configurations for all devices based on the following:
Configure all interfaces based on the network diagram in terms of IP addressing and the
subnet mask.
Next enable all interfaces by issuing a no shutdown
Once that has been completed we need to check on two things.
First confirm that all interfaces are up and running. This command will show all interfaces
and there status in a basic or brief view. Confirm that all interfaces once configured shows
an UP UP status.
show ip interface brief
And second, confirm basic network connectivity by pinging the directed connected IP address
of the other router. Do this for each device.

4.2 MPLS VPN
STEP 1: NETWORK DESIGN
The network design for MPLS VPN will consist of the following details:
Requirements:
Our MPLS network will consist of a Service Provider network and two client networks.
Our Service Provider network will consist of a single Core router and two Aggregation routers
connecting to the client (CE sites) including the MPLS Core itself.
Our two clients will each have two locations and will communicate with each other via EIGRP
through the Service Provider's MPLS network. It's important that there is no route nor traffic
leakage between our two clients routing domains within the Service Provider network.
Topology:
Our solution in our design will be a WAN/MAN. From the two, we would be more of a
MAN solution since Ethernet will be our technology used across our MPLS network
and the distances are shorter.
Our WAN/MAN topology for our Service Provider network will be a two-tier model
consisting of a Core and two Aggregation routers. Our Aggregation routers will each
connect with two CE sites (one for each client)
Topology Services and Sub-Services

Below is a summary with our applicable services and sub-services used in our design:
Tunneling: We will use L3VPN MPLS VPN and VRF necessary for creating isolated
routing domains and MPLS LDP/TDP operations to make our VRF domains scalable.
Routing & Switching: We will use OSPF (required with MPLS services for MPLS
general routing) and BGP (required with MPLS services for MP-BGP PE peering).
We will use EIGRP routing for our client site routing protocol.
Bandwidth Services among our MAN will consist of Fast Ethernet connections for all
devices including downlinks to our Client devices since the anticipated traffic rate is
below FE bandwidth rates of 100Mbps for all clients.
Our IP Schema developed is a standard that will use the 10.0.0.0 /8 subnet with a
specific usage for each octet.
Hardware & Software:

Cisco 3660 Series Routers using IOS 12.4(15)T9 running the Advanced IP Services
Feature set for our MPLS routers to support the requirements and topology services
in our design.

Network Diagram
STEP 2: BASIC IP CONFIGURATION

Below is the basic configuration for our MPLS devices. A loopback interface will be
configured for management, MPLS peering, and MP-BGP peering used in a later step.
Below is our basic IP configuration for our MPLS Provider Core router, which will include
configuring the interface that will connect between the two PE routers.
ROUTEHUB-P
interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface FastEthernet0/0
ip address 10.1.2.1 255.255.255.0
ip address 10.1.3.1 255.255.255.0
Below is our basic IP configuration for our two MPLS Provider Edge routers:
ROUTEHUB-PE1
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.1.2.2 255.255.255.0
ROUTEHUB-PE2
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip address 10.1.3.3 255.255.255.0

STEP 3: OSPF CONFIGURATION ON MPLS NETWORK
Once all basic network details has been configured lets configure OSPF routing on all MPLS
devices.
Our OSPF configuration will include the subnets of the IP addresses we configured under the
Basic IP Configuration. These subnets will be advertised to all routers within the MPLS
network. The process ID used for enabling OSPF routing on each router will be unique to its
device ID.
All interfaces among our MPLS devices will exist within the OSPF backbone network or
AREA 0. The loopback interfaces will be added to their own area unique again to their
device ID.
Below is the OSPF configuration for our MPLS P router:
ROUTEHUB-P
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
Below is the OSPF configuration for both of the MPLS PE routers:
ROUTEHUB-PE1
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
ROUTEHUB-PE2
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
Once OSPF has been configured confirm if OSPF neighbors have been established between
the MPLS devices. You can do this by issuing the monitoring command
show ip ospf neighbor
Next confirm if OSPF routes exist in the global routing table on the MPLS devices especially
on the two PE devices, which should see each others loopback subnet route. You can do
this by issuing the command
show ip route

STEP 4: MPLS AND LDP CONFIGURATION
Once OSPF routing is configured, we should see our OSPF neighbors and OSPF routes in
our global routing table on each MPLS device.
Now it is time for us to enable MPLS LDP on all MPLS interfaces on our network. Label
Distribution Protocol (LDP) is an industry standard label switching protocol and TDP is
another label protocol supported on Cisco MPLS enabled routers. LDP is recommended
and we will specify this label protocol type globally on all MPLS routers.
Issuing mpls ip enables MPLS label switching capabilities on the MPLS router. LDP
neighbor adjacencies will soon be established which depend on OSPF routing to be up and
running.
Below is our LDP configuration on our MPLS Provider Core router:
ROUTEHUB-P
mpls label protocol ldp
mpls ip
mpls ip
Below is our LDP configuration for our two MPLS Provider Edge routers.
ROUTEHUB-PE1
mpls ip
ROUTEHUB-PE2
mpls ip
Once MPLS label switching has been setup along with OSPF from a previous step our LDP
neighbors should be established. We can confirm this by issuing the command:
show mpls ldp neighbor

STEP 5: VRF CONFIGURATION
We will configure two VRF instances on our MPLS network for two clients. VRF CEA will be
used for Client A and VRF CEB will be used for Client B.
An arbitrary number will be configured for the route distinguisher (RD) that is unique, but the
same for all VRF instances across our network similar to the concept of the VLAN ID for
Layer 2 networks. The route target reflects what traffic can be imported into a VRF or
exported from this VRF that is associated with this RD ID.
Once the VRF instance has been defined we will associate the VRFs to the physical interface
that the CE device is connected shown in our the diagram.
Below is our VRF configuration for our MPLS PE1 router:
ROUTEHUB-PE1
ip vrf CEA
rd 10:100
route-target export 10:100
route-target import 10:100
ip vrf CEB
rd 11:100
ip vrf forwarding CEA
ip address 10.2.4.2 255.255.255.0
ip vrf forwarding CEB
ip address 10.2.5.2 255.255.255.0
ROUTEHUB-PE2
ip vrf CEA
rd 10:100
ip vrf CEB
rd 11:100
ip address 10.3.7.3 255.255.255.0
ip address 10.3.6.3 255.255.255.0

VRF configuration is not required on our MPLS Provider Core and RR router.
Once our VRF instances have been configured our isolated routing tables has also been
created. However, to confirm that our VRF instances are configured and associated with the
correct interfaces we can use the commands
show ip vrf brief
show ip vrf interfaces
STEP 6: IGP EIGRP ROUTING FOR VRF

We will configure EIGRP routing to be our routing protocol that will be used for our two clients
in VRF "CEA" and VRF "CEB". EIGRP must be configured on the CE router and its
connected PE router. In return those PE routers will redistribute those learned IGP routes
from the CE devices into MP-BGP. IGP Routing is required for sites within a VRF domain to
communicate together.
On our PE router we will configure EIGRP routing for our two clients as a "address family"
similar to how we will configure MP-BGP for these two VRF instances. Once we issue router
eigrp then the ASN that will put us under the routing mode for EIGRP. There we can enter
our "address-family", VRF, and our VRF name to be able to communicate with one another.
All routes learned in each VRF will be isolated to that routing table only and not shared with
the other VRF domains.
Below is our VRF EIGRP configuration for our MPLS PE1 router:
ROUTEHUB-PE1
router eigrp 1
no auto-summary
address-family ipv4 vrf CEB

network 10.2.5.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
autonomous-system 10
exit-address-family
address-family ipv4 vrf CEA

network 10.2.4.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family

ROUTEHUB-PE2
router eigrp 1
no auto-summary

network 10.3.7.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family

network 10.3.6.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
IGP routing for VRF configuration is not required on our MPLS Provider Core and RR router.
Once EIGRP has been configured confirm if EIGRP neighbors have been established
between the PE and CE devices. However, no neighbors will be formed until we finish the
configuration on our CE devices, which is the next step. But, when the time comes we can
do this by issuing the command:
show ip eigrp neighbor
To confirm if EIGRP routes exist in the routing table for a particular VRF instance on our
MPLS PE device we can use the command:
show ip route vrf following by the VRF-name, for example we can issue the command
show ip route vrf CEA

STEP 7: CE DEVICE CONFIGURATION
In this step we will configure all of our basic IP details and the EIGRP routing protocol on all
of our CE routers shown in the network diagram.
No MPLS or VRF configuration is required or needed on CE devices.
Below is our configuration for our CE1-A router (for Client A):
ROUTEHUB-CE1-A
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip address 10.2.4.4 255.255.255.0
router eigrp 10
network 4.4.4.4 0.0.0.0
network 10.2.4.0 0.0.0.255
no auto-summary
no eigrp log-neighbor-changes
Below is our configuration for our CE2-A router (for Client A):
ROUTEHUB-CE2-A
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip address 10.3.6.6 255.255.255.0
router eigrp 10
network 6.6.6.6 0.0.0.0
network 10.3.6.0 0.0.0.255
no auto-summary
Below is our configuration for our CE1-B router (for Client B):
ROUTEHUB-CE1-B
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip address 10.2.5.5 255.255.255.0
router eigrp 10
network 5.5.5.5 0.0.0.0
network 10.2.5.0 0.0.0.255
no auto-summary
Below is our configuration for our CE2-B router (for Client B):
ROUTEHUB-CE2-B
interface Loopback0

ip address 7.7.7.7 255.255.255.255
ip address 10.3.7.7 255.255.255.0
router eigrp 10
network 7.7.7.7 0.0.0.0
network 10.3.7.0 0.0.0.255
no auto-summary
Confirm that all interfaces are up and running. We can do this by issuing the command from
the enable mode
show ip interface brief
Confirm all basic network connectivity by pinging the directed connected IP address of the
PE router in the MPLS cloud.
Once EIGRP has been configured confirm if EIGRP neighbors has been established between
the PE and CE devices. We can do this by issuing the command
show ip eigrp neighbor
STEP 8: MP-BGP CONFIGURATION

Once label switching is enabled and operational we can enable MP-BGP between our two
MPLS PE routers.
Multi-Protocol BGP (MP-BGP) or IBGP is configured between our two PE routers to

exchange VPN information on the configured VRF domains. The MP portion of the BGP
means that we will configure additional parameters with BGP that contains the address-
family. One of those address families enables vpnv4 between our two PE devices.
First we configure simple IBGP between the two PE devices using the Loopback
interface as the peering interface. These routers will exist in ASN 6778 within our
MPLS network.
Second, we will enable an address family class called VPNv4 that will send VPNv4
prefix information between the two PE devices.
Third, another address family for each VRF instance configured. This is where
routes learned from the CE devices via its IGP routing protocol is then redistributed
into BGP to be sent to the other PE device to allow our sites within their VRF domain
to communicate with one another.
Below is our MP-BGP configuration for our PE1 router peering with PE2:
ROUTEHUB-PE1
router bgp 6778
no synchronization
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 6778
neighbor 3.3.3.3 update-source Loopback0
no auto-summary

address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family

redistribute eigrp 10
no synchronization
exit-address-family

no synchronization
exit-address-family
router eigrp 1
redistribute bgp 6778
ROUTEHUB-PE2
router bgp 6778
no synchronization
no auto-summary
exit-address-family

no synchronization
exit-address-family

no synchronization
exit-address-family
router eigrp 1
MP-BGP configuration is not required on our MPLS Provider Core router.

Once this is completed we should be able to see routes between our two CEA devices.
Confirm if BGP peers has been successfully established between our PE routers and our
Route Reflector router. Basically under State/PfxRcd it should have some number and not
a word like Active or Idle present. You can do this by issuing the command:
show ip bgp summary
Confirm if all VPNv4 prefixes are learned via MP-BGP from the other PE router through the
Route Reflector for a particular VRF instance. We can do this by issuing the command:
show ip bgp vpnv4 vrf <vrf-name>. For example, show ip bgp vpnv4 vrf CEA
To confirm if EIGRP routes exist in the routing table for a particular VRF instance on our
MPLS PE device we can use the command:
show ip route vrf <vrf-name>
To view the routing table on our CE device we can simply use the command show ip route
to confirm if we are receiving EIGRP routes from our other CE site that are part of the same
VRF domain.

4.3 MPLS VPN: Using Route Reflectors
The network design for our MPLS network using Route Reflectors will consist of the following
details:
Requirements:
Our network consist of a Service Provider and a single Client network. Our Client network
will consist of two sites connecting into the ISP for IP WAN services via MPLS VPN. Our
Service Provider will be configured to virtualize client networks across the Service Provider
network without any route or traffic leakage between other clients added in the future. Our
ISP for simplicity reasons will be located across two locations connecting for the two client
sites.
Some of the requirements and expectations include:

Provide a separate routing domain for all clients (starting with a single client) on the
same network infrastructure and not create individual networks increasing network
management.
Client sites should be able to communicate with one another (routing and traffic).
There should be no route and traffic leakage between other client routing domains
Topology:
Solutions used in our design will be a WAN/MAN. From the two, we would be more
of a MAN solution since Ethernet will be our technology used across our MPLS
network and the distances are shorter.
Topology: our WAN/MAN topology within the ISP will be a 2Tier model with a Core
and 2 Aggregation routers. Our MAN Core will be our MPLS P router and our MAN
AGG will be our MPLS PE1 and PE2 routers. PE1 will connect to CE-1 and PE2 will
connect to CE-2.

As a best practice will include a single BGP Route Reflector router that our two PE
routers would peer with to provide better reliability and scalability on the MPLS
network.
EIGRP routing would be used for our client sites
specific usage for each octet

Feature set to support the requirements and topology services in our design.

Network Diagram

Below is the basic configuration for our MPLS devices on our network. A loopback interface
will be configured for management purposes, MPLS peering, and MP-BGP peering used in
later steps.
Below is our basic IP configuration for our MPLS Provider Core router:
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 10.1.2.1 255.255.255.0
ip address 10.1.4.1 255.255.255.0
ip address 10.1.3.1 255.255.255.0
ROUTEHUB-PE1
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.1.2.2 255.255.255.0

ROUTEHUB-PE2
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip address 10.1.3.3 255.255.255.0
Below is our basic IP configuration for our Route Reflector (RR) router on our MPLS network:
ROUTEHUB-RR
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip address 10.1.4.4 255.255.255.0

devices.
device ID.
device ID.
Below is the OSPF configuration for our P device that is connecting to both PE devices on
our network.
ROUTEHUB-P
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
network 10.1.4.0 0.0.0.255 area 0
Below is our OSPF configuration needed for our two MPLS Provider Edge routers:
ROUTEHUB-PE1
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0

ROUTEHUB-PE2
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
Below is our OSPF configuration for our Route Reflector router on the MPLS network:
ROUTEHUB-RR
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.1.4.0 0.0.0.255 area 0

Now it is time for us to enable MPLS LDP on all MPLS interfaces on our network. LDP
running.
ROUTEHUB-P
mpls ip
mpls ip
mpls ip
ROUTEHUB-PE1
mpls ip

ROUTEHUB-PE2
mpls ip
Below is our LDP configuration on our MPLS Route Reflector router:
ROUTEHUB-RR
mpls ip

We will configure one VRF instance on our MPLS network called CE.
Once the VRF instance has been defined we will associate the VRF to the physical interface
that the CE device is connected to base on the diagram.
Below is our VRF configuration for our two MPLS Provider Edge routers.
ROUTEHUB-PE1
ip vrf CE
rd 10:100
ip vrf forwarding CE
ip address 10.2.5.2 255.255.255.0
ROUTEHUB-PE2
ip vrf CE
rd 10:100
ip address 10.3.6.3 255.255.255.0

We will configure EIGRP routing to be our routing protocol that will be used for our clients in
VRF "CE". EIGRP must be configured on the CE router and its connected PE router. In
return those PE routers will redistribute those learned IGP routes from the CE devices into
MP-BGP. IGP Routing is required for sites within a VRF domain to communicate together.
All routes learned within this VRF will be isolated to that routing table only.
ROUTEHUB-PE1
router eigrp 1
auto-summary
address-family ipv4 vrf CE
network 10.2.5.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
ROUTEHUB-PE2
router eigrp 1
auto-summary
network 10.3.6.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
IGP routing for VRF configuration is not required on our MPLS Provider Core and RR router.

In this step we will configure the basic IP details and EIGRP routing protocol on all of our CE
routers shown in the network diagram.
Below is our configuration needed on our CE1 router (ROUTEHUB-CE1):
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip address 10.2.5.5 255.255.255.0
router eigrp 10
network 5.5.5.5 0.0.0.0
network 10.2.5.0 0.0.0.255
no auto-summary

Below is our configuration needed on our CE2 router (ROUTEHUB-CE2):
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip address 10.3.6.6 255.255.255.0
router eigrp 10
network 6.6.6.6 0.0.0.0
network 10.3.6.0 0.0.0.255
no auto-summary
STEP 8: MP-BGP CONFIGURATION WITH ROUTE REFLECTOR

MPLS PE routers.
As a recap, all MPLS PE routers (part of the same IBGP domain) must be fully-meshed to
exchange VPNv4 prefixes for the various configured VRF networks. This can cause a lot of
clutter and challenges for scalability, lack of reliability, and troubleshooting nightmares.
As a best practice Route Reflectors (RR) should be used whereall PE routers would connect
to for exchanging VPNv4 addresses among the PE devices. In our configuration we will
include a single RR router that our two PE routers would peer with.
1. First, we will configure a simple iBGP peer from our two PE devices using the
Loopback interface as the peering interface to our single Route Reflector router. All
of our BGP routers will exist in ASN 6778. Our Route Reflector router would peer
with the two PE routers.
2. Second, we will enable an address family class called VPNv4 that will send VPNv4
prefix information between the two PE devices and our Route Reflector router
3. Third, another address family for each VRF instance is configured. This is where
routes learned from the CE devices via the EIGRP routing protocol is then
redistributed into BGP to be sent to the other PE device to allow our sites within their
VRF domain to communicate with one another. This is not configured or required on
our Route Reflector router.
Below is our MP-BGP configuration for our two PE routers (which are identical) peering with
our RR router:
ROUTEHUB-PE1, ROUTEHUB-PE2
router bgp 6778
no synchronization
no auto-summary
exit-address-family

no synchronization
exit-address-family
router eigrp 1
Below is our MP-BGP configuration on our RR router peering with our two PE routers:
ROUTEHUB-RR
router bgp 6778
no synchronization
neighbor 2.2.2.2 route-reflector-client
no auto-summary
exit-address-family
MP-BGP configuration is not required on our MPLS Provider Core router.

CONFIGURATION SUMMARY
Below is the relevant configuration for using Route Reflectors in our MPLS network:
ROUTEHUB-PE1, ROUTEHUB-PE2
router bgp 6778
no synchronization
no auto-summary
exit-address-family

no synchronization
exit-address-family
router eigrp 1
ROUTEHUB-RR
router bgp 6778
no synchronization
no auto-summary
exit-address-family

4.4 MPLS over GRE
The network design for our MPLS over GRE will consist of the following details:
Requirements:
Our network will consist of two MPLS Service Provider networks and two Clients each with
two sites, soon to be one. One client site has two sites located with one MPLS network and
the other client has two sites with another MPLS network. Well two things recently evolved:
1) The two MPLS providers are merging together and need to quickly connect the two
MPLS networks together.
2) One of our client sites has acquired the business for the second client and during the
process they will need to merge that network with their current network infrastructure
connected into their MPLS provider.
Our two Service Provider networks that will be merged together exist in two different
locations, but connected via the global public network (Internet).
Our two Service Provider will be configured to virtualize client networks across the Service
Provider network without any route or traffic leakage between other clients added in the
future.

Merge the two MPLS networks together quickly
Provide a separate routing domain for all clients on the same network infrastructure
and not create individual networks increasing network management.
Our four Client sites should be able to communicate with one another (routing and
traffic) once merged.
Topology:
Topology: our WAN/MAN topology within each Service Provider will be a two-level
design model consisting of a Core and a single Aggregation router. Our MAN Core
will be our MPLS P router and our MAN AGG will be the local PE router in that MPLS
network. Once the two MPLS networks are merged it will still be a two-level design
where our MAN Core will be the MPLS P routers and our MAN Aggregation will be
the two PE routers only extended. Each PE router will connect to two CE sites.

Tunneling: We will use GRE to quickly build a virtual connection between our two
MPLS P routers to extend our VRF infrastructure.
OSPF routing would be used for our client sites


Feature set to support the requirements and topology services in our design.
Network Diagram:
STEP 2: BASIC IP CONFIGURATION FOR MPLS1 NETWORK

We will first configure our MPLS1 network for all necessary services then we will configure
our MPLS2 network same but with different IP and interface information.
Below is the basic configuration for our MPLS devices on the MPLS1 network. A loopback
interface will be configured used for management, MPLS peering, and MP-BGP peering used
in a later step.
configuring the interface that will connect into the Internet (another Service Provider tier).
ROUTEHUB-P1
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.2.4.2 255.255.255.0
ip address 10.1.2.2 255.255.255.0

Below is our basic IP configuration for our MPLS Provider Edge router:
ROUTEHUB-PE1
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip address 10.2.4.4 255.255.255.0
STEP 3: OSPF CONFIGURATION ON MPLS1 NETWORK

devices.
device ID.
device ID.
Below is the OSPF configuration for our P device that is connecting to the PE1 router on our
MPLS1 network.
ROUTEHUB-P1
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.2.4.0 0.0.0.255 area 0
Below is our OSPF configuration needed for our MPLS Provider Edge router:
ROUTEHUB-PE1
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.2.4.0 0.0.0.255 area 0

STEP 4: MPLS AND LDP CONFIGURATION ON MPLS1 NETWORK
running.
ROUTEHUB-P1
mpls ip
ROUTEHUB-PE1
mpls ip
STEP 5: VRF CONFIGURATION ON MPLS1 NETWORK

We will configure one VRF instance on our MPLS network called "CE".
Below is our VRF configuration for our MPLS Provider Edge router including applying the CE
VRF to our connected CE site interfaces.
ROUTEHUB-PE1
ip vrf CE
rd 10:100
ip address 10.4.6.4 255.255.255.0
ip address 10.4.8.4 255.255.255.0

STEP 6: IGP OSPF ROUTING FOR VRF ON MPLS1 NETWORK
We will configure OSPF routing to be our routing protocol that will be used for our clients in
VRF "CE". OSPF must be configured on the CE router and its connected PE router. In
All routes learned within a particular VRF will be isolated to that routing table only.
Below is our VRF OSPF configuration for our MPLS Provider Edge router:
ROUTEHUB-PE1
router ospf 10 vrf CE
network 10.4.6.0 0.0.0.255 area 0
network 10.4.8.0 0.0.0.255 area 0
STEP 7: CE CONFIGURATION ON MPLS1 NETWORK

The purpose of this configuration is to configure our client edge devices (or CE) that connects
into the Service Provider. No MPLS or VRF configuration exists on these devices.
This is essentially what the configuration looks like from the client side (on their Client Edge
or CE device). The configuration enables all IP addressing based on the network diagram
including the matching routing protocol that we enabled on our PE routers.
Once this configuration is completed our CE devices should have an OSPF neighbor peer
with its connected PE router.
Below is our configuration needed on our CE11 router:
ROUTEHUB-CE11
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip address 10.4.6.6 255.255.255.0
router ospf 6
network 6.6.6.6 0.0.0.0 area 6
network 10.4.6.0 0.0.0.255 area 0
Below is our configuration needed on our CE12 router:
ROUTEHUB-CE12
interface Loopback0
ip address 8.8.8.8 255.255.255.255
ip address 10.4.8.8 255.255.255.0
router ospf 8
network 8.8.8.8 0.0.0.0 area 8
network 10.4.8.0 0.0.0.255 area 0

STEP 8: COMPLETE MPLS2 NETWORK CONFIGURATION
Once our MPLS1 network has been configured we can configure our MPLS2 network for
OSPF routing, MPLS/LDP, VRF CE, and VRF routing for our CE routing domain using OSPF.
Identical to what we configured for our MPLS1 network, but based on the IP address and info
presented in the network diagram.
Below is our complete configuration for our second MPLS Provider Core router.
ROUTEHUB-P2
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip address 10.1.3.3 255.255.255.0
ip address 10.3.5.3 255.255.255.0
mpls ip
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.2.3.0 0.0.0.255 area 0
network 10.3.5.0 0.0.0.255 area 0
Below is our complete configuration for our second MPLS Provider Edge router.
ROUTEHUB-PE2
ip vrf CE
rd 10:100
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip address 10.3.5.5 255.255.255.0
mpls ip
ip address 10.5.7.5 255.255.255.0
ip address 10.5.9.5 255.255.255.0

network 10.5.7.0 0.0.0.255 area 0
network 10.5.9.0 0.0.0.255 area 0

router ospf 5
network 5.5.5.5 0.0.0.0 area 5
network 10.3.5.0 0.0.0.255 area 0
Below is our complete configuration for our second set of CE routers that will evidentially
connect with the other CE routers in the MPLS1 network.
ROUTEHUB-CE21
interface Loopback0
ip address 9.9.9.9 255.255.255.255
ip address 10.5.9.9 255.255.255.0
router ospf 9
network 9.9.9.9 0.0.0.0 area 9
network 10.5.9.0 0.0.0.255 area 0
ROUTEHUB-CE22
interface Loopback0
ip address 7.7.7.7 255.255.255.255
ip address 10.5.7.7 255.255.255.0
router ospf 7
network 7.7.7.7 0.0.0.0 area 7
network 10.5.7.0 0.0.0.255 area 0
STEP 9: INTERNET ROUTER CONFIGURATION

Next we will configure our INTERNET router that will emulate our INTERNET as a whole that
will connect our two MPLS networks together.
INTERNET
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 10.1.2.1 255.255.255.0
ip address 10.1.3.1 255.255.255.0

STEP 10: GRE TUNNEL
Once we have our INTERNET up and running for our network will be configure a GRE tunnel
between our two MPLS P routers in our design.
Our GRE tunnel will be built and terminated from the physical interface facing towards the
Internet. Building a GRE tunnel creates a virtual connection between our MPLS Provider
Core routers as if they are directly connected together part of the same network.
We will add a default route pointing to our INTERNET router to make sure both P routers
know how to route between each other for our GRE tunnel to be established.
Below is our configuration for the first MPLS P router:
ROUTEHUB-P1
ip route 0.0.0.0 0.0.0.0 10.1.2.1
interface Tunnel0
ip address 10.2.3.2 255.255.255.0
tunnel source FastEthernet0/1
tunnel destination 10.1.3.3
Below is our configuration for the second MPLS P router:
ROUTEHUB-P2
ip route 0.0.0.0 0.0.0.0 10.1.3.1
interface Tunnel0
ip address 10.2.3.3 255.255.255.0
No GRE configuration is needed on our PE routers.
To confirm if the GRE tunnel is up and running correct issue a "show interface tunnel 0" on
both P routers to confirm if the interface is up.
Next, from one of the P routers determine if we can ping the GRE IP address on the other
router. For example, from P1 confirm if you can ping 10.2.3.3 before we continue to the next
step.

STEP 11: OSPF ROUTING WITH GRE
Once our GRE tunnel is up and running we can now add that GRE subnet into our OSPF
routing domain for both MPLS P routers to be part of our OSPF Backbone (AREA 0).
ROUTEHUB-P1
router ospf 2
network 10.2.3.0 0.0.0.255 area 0
ROUTEHUB-P2
router ospf 3
network 10.2.3.0 0.0.0.255 area 0
Completing this configuration we will be able to see a new OSPF neighbor built between our
two MPLS P routers using the GRE tunnel. We can confirm this by issuing the command
"show ip ospf neighbor"
Once we have our neighbor established then we should see OSPF routes exchanged on
both ends for our MPLS network. We can issue the command "show ip route" or "show ip
route ospf" to confirm if all routes are received on both MPLS networks.
STEP 12: LDP ON GRE

Now it is time to enable label switching between our two MPLS networks. To do this we will
enable LDP on our GRE tunnel on both ends.
ROUTEHUB-P1
interface Tunnel0
mpls ip
ROUTEHUB-P2
interface Tunnel0
mpls ip
Doing this we should have a MPLS LDP peer established between our two P routers. We
can confirm this by issuing the command "show mpls ldp neighbor".
Now we can configure our MP-BGP session between our two PE routers to extend our VPN
route information for our CE domain between the two MPLS networks.

STEP 13: MP-BGP CONFIGURATION BETWEEN PE ROUTERS
MPLS PE routers which are able to communicate with one another through the GRE tunnel.
The purpose of this configuration is to setup iBGP between all PE devices in the diagram,
which depends on OSPF or ISIS routing within the MPLS network. MP-BGP sessions are
responsible for sending VPNv4 prefixes (VPN information) between PE devices on the
subnets learned from the CE then translated to a VPNv4 address (which means appending
the RD ID) and are sent across as MP-BGP updates.
First we configure simple iBGP between the two PE devices using the Loopback
MPLS network.
Once this is completed we should be able to see routes between our two CE devices.
Below is our MP-BGP configuration for our PE1 router:
ROUTEHUB-PE1
router bgp 6778
no synchronization
no auto-summary
exit-address-family

redistribute ospf 10 vrf CE
no synchronization
exit-address-family

redistribute bgp 6778 subnets
Below is our MP-BGP configuration for our PE2 router:
ROUTEHUB-PE2
router bgp 6778
no synchronization
no auto-summary

exit-address-family

no synchronization
exit-address-family


4.5 Extranet
The network design for our MPLS Extranet will consist of the following details:
Requirements:
We need to create two separate routing domains for at least two clients, Client A
(CEA) and Client B (CEB), on the same network infrastructure and not create
individual networks increasing network management.
Client A sites should be able to communicate with one another (routing and traffic).
Client A site CE1-A can also communicate with the Client B site CE1-B. Client A
site CE2-A should NOT communicate with CE1-B
There should be no route and traffic leakage between the two routing domains
Technical Objectives:
Performance: the bandwidth services utilized within our network will be FastEthernet
since traffic usage will be minimal and this is a test setup. No voice or video traffic
will exist across our network. However, our network is capable of supporting QoS if
necessary.
Reliability: hardware redundancy is not included in this design since the SLA
requirements are low and it is a test setup for our MPLS EXTRANET design. If any
MPLS component fails within our MPLS network then our entire network will be
inaccessible for Client A and Client B.
Scalability: no requirements for scalability are outlined and we are glad because we
would encounter some serious scalability issues. For one, Route Reflectors are
recommended for PE-to-PE peering for MP-BGP updates especially if our PE
devices grow within our MPLS design. However this is a small network design with
no growth expected. The environment can scale if the MPLS hardware devices are
upgraded to support higher port counts and performance resources such as
bandwidth and port buffers.
Security: MPLS provides a lot of security within its technology preventing the other
VRF networks to communicate with one another in regards to routing and traffic.
However, our design requires that one of the CEA sites need to communicate with
the CEB site, but not all CEA sites should communicate with CEB as that would not
align with the stated requirements. Hence, we will apply security policies within our
MPLS route-targets.
Flexibility: Additional services that may be included in the future will be QoS.
Network Management: No initial monitoring is needed today, but the network will be
managed by a consulting group.
Topology:
Solutions used in our design: WAN/MAN. From the two, we would be a MAN
solution since Ethernet will be our technology used across our MPLS network and
the distances are shorter.
Topology: our WAN/MAN topology will be a 2Tier model with a Core and 2
Aggregation routers. Our MAN Core will be our MPLS P router and our MAN AGG
will be our MPLS PE1 and PE2 routers. PE1 will connect to CEA-1 and PE2 will
connect to CEA-2 and CEB-1 devices.

Tunneling using L3VPN MPLS VPN using the VRF technology necessary for creating
isolated routing domains and MPLS LDP/TDP operations to make our VRF domains
scalable.

Routing & Switching using OSPF(required with MPLS services for MPLS general
routing) and BGP (required with MPLS services for MPLS MP-BGP peering among
PE devices).
MPLS VPN Sub-Services to include: MPLS Extranet to allow the first Client A site to
communicate with the Client B site. The second Client A site should NOT
communicate with Client B.
devices including downlinks to Client A and Client B devices since the anticipated
traffic rate is below FE bandwidth rates of 100Mbps for all clients.

Feature set to support the requirements and topology services.
Network Diagram
STEP 2: BASIC CONFIGURATION

Below is the basic configuration for our PE1 and PE2 devices. A loopback interface will be
configured as our management interface used for management, MPLS peering, and MP-BGP
peering used in a later step.
ROUTEHUB-PE1
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.1.2.2 255.255.255.0
no shutdown
ROUTEHUB-PE2
interface Loopback0
ip address 3.3.3.3 255.255.255.255

ip address 10.1.3.3 255.255.255.0
no shutdown
ROUTEHUB-P
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 10.1.2.1 255.255.255.0
no shutdown
ip address 10.1.3.1 255.255.255.0
no shutdown
STEP 3: OSPF CONFIGURATION AMONG THE MPLS ROUTERS

devices.
device ID.
device ID.
Below is the basic configuration for our P device that is connecting to both PE devices on our
network.
ROUTEHUB-PE1
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
ROUTEHUB-PE2
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
ROUTEHUB-P
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0

STEP 4: MPLS AND LDP CONFIGURATION ON MPLS ROUTERS
running.
ROUTEHUB-P
mpls ip
mpls ip
ROUTEHUB-PE1
mpls ip
ROUTEHUB-PE2
mpls ip
STEP 5: VRF CONFIGURATION ON MPLS PE ROUTERS

We will configure two VRF instances on our MPLS network. One will be for Client A (called
VRF CEA) and the other will be for Client B (called VRF CEB) based on the diagram. An
arbitrary number will be configured for the route distinguisher (RD) that is unique, but the
same for all VRF instances similar to the VLAN ID for Layer 2 networks. The route target
reflects what traffic can be imported into a VRF or exported from this VRF that is associated
with this RD ID.
Once the VRF instances have been defined we will associate the VRF to the physical
interface that the CE device is connected to. So, all traffic from these interfaces will be
associated to their corresponding VRF and RD. For example, CEA-1 is connected to PE1,
so it would be associated to VRF CEA which is then mapped to RD 10:100. So, any traffic
with RD 10:100 will be allowed to access CEA-1 and in return CEA-1 will be able to access
network resources in other VRF instances since if it mapped with RD 10:100.
ROUTEHUB-PE1
ip vrf CEA
rd 10:100
ip address 10.2.4.2 255.255.255.0

ROUTEHUB-PE2
ip vrf CEA
rd 10:100
ip vrf CEB
rd 20:200
ip address 10.3.5.3 255.255.255.0
duplex auto
speed auto
ip address 10.3.6.3 255.255.255.0
STEP 6: OSPF ROUTING FOR VRF DOMAINS

The purpose of this configuration is to configure the routing protocol that will be used
between the CE device (so they must be configured for the same routing protocol) and its
connected PE router. In return those PE routers will redistribute those learned IGP routes
from the CE devices via MP-BGP. IGP Routing is required for sites within a VRF domain to
communicate together.
We will configure OSPF routing to be our routing protocol used for our clients for each VRF
instance seen after we issue router ospf the process ID then VRF and our VRF name to be
able to communicate with one another. This configuration looks very similar to how we
configured OSPF among our MPLS, but this configuration includes the VRF instance and the
subnets it will advertise within that VRF domain.
ROUTEHUB-PE1
router ospf 20 vrf CEA
network 10.2.4.0 0.0.0.255 area 0
ROUTEHUB-PE2
network 10.3.5.0 0.0.0.255 area 0
router ospf 31 vrf CEB

network 10.3.6.0 0.0.0.255 area 0

The purpose of this configuration is to configure our client edge devices (or CE) that connects
into the Service Provider. No MPLS or VRF configuration exists on these devices.
This is essentially what the configuration looks like from the client side (on their Client Edge
or CE device). The configuration enables all IP addressing based on the network diagram
including the matching routing protocol that we enabled on our PE routers. Once this
configuration is completed our CE devices should have an OSPF neighbor peer with its
connected PE router.
ROUTEHUB-CE1-A
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 10.2.4.4 255.255.255.0
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.2.4.0 0.0.0.255 area 0
ROUTEHUB-CE2-A
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip address 10.3.5.5 255.255.255.0
router ospf 5
network 5.5.5.5 0.0.0.0 area 5
network 10.3.5.0 0.0.0.255 area 0
ROUTEHUB-CE1-B
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip address 10.3.6.6 255.255.255.0
router ospf 6
network 6.6.6.6 0.0.0.0 area 6
network 10.3.6.0 0.0.0.255 area 0

STEP 8: MP-BGP CONFIGURATION BETWEEN MPLS PE ROUTERS
MPLS PE routers.
MPLS network.
Third, another address family for the VRF instance configured. This is where routes
learned from the CE devices via its IGP routing protocol is then redistributed into
BGP to be sent to the other PE device to allow our sites within their VRF domain to
communicate with one another.
ROUTEHUB-PE1
router bgp 6778

no synchronization
no auto-summary
exit-address-family

redistribute ospf 20
no synchronization
exit-address-family
ROUTEHUB-PE2

router bgp 6778

no synchronization
no auto-summary
exit-address-family

redistribute ospf 31 vrf CEB
no synchronization
exit-address-family

redistribute ospf 30 vrf CEA
no synchronization
exit-address-family
STEP 9: MPLS VPN EXTRANET CONFIGURATION ON MPLS PE ROUTERS

The purpose of this configuration is to configure our route targets to allow routing and traffic
forwarding between other VRF instances on the network.
So as a recap, Client A sites should be able to communicate with one another, but not
communicate with the CE device for Client B. Now we want to change that to allow only our
first client A router and our client B router to communicate together. But, the second client A
router cannot communicate with the client B router.
Lets start on PE1, first lets define two access-lists. ACL 1 will define all subnets from the
first client A router, which is directly connected to PE1. The second ACL, ACL 2, will include
subnets from the client B router and the second client A router (because remember we still
want are two client A sites to communicate). Next, we will configure two policy routes (or
PBR). The first PBR will match ACL 1, which is the subnets from the first client A router that
will exported from its VRF domain mapped to RD ID 20:1. The second PBR is stating that it
will accept importing subnets that match ACL 2, which are the subnets from our second client
A router and the client B router. Thats the first part for the import piece, but the other
component tells us that they must contain either RD 10:100 (for the second client A router) or
10:1 (for the client B router). This is what we configured from the VRF step, except 10:1 is
added to the VRF configuration on PE1 because it will be unique only for the Client B router
to communicate with the first client A router.
ROUTEHUB-PE1
access-list 1 permit 4.4.4.4
access-list 1 permit 10.2.4.0 0.0.0.255
route-map ROUTEHUB-PBR-CEA-EXP permit 10

match ip address 1
set extcommunity rt 20:1
route-map ROUTEHUB-PBR-CEA-IMP permit 10

match ip address 2
ip vrf CEA
import map ROUTEHUB-PBR-CEA-IMP
export map ROUTEHUB-PBR-CEA-EXP

Next, the configuration for PE2 is similar to PE1. Again we define two access-lists. ACL 1
will include all subnets from the first Client A router (connected to PE1). ACL 2 will include
subnets from the client B router. Next, we will configure two policy routes (or PBR). The first
PBR will match ACL 2, which is the subnets from the Client B router that will be exported
from its VRF domain mapped to RD ID 10:1. The second PBR is stating that it will accept
imported subnets that match ACL 1, which are the subnets from the first Client A router.
Thats the first part for the import piece, but the other component tells us that they must
contain either RD 20:200 (if there were other client B sites), 10:100 (for the first client A
router) or 20:1 (for again the first client A router). This is what we configured from the VRF
step, except 20:1 is added to the VRF configuration on PE2 because it will be unique only for
the client B router to communicate with the first client A router. However, one thing is wrong
and that is with 10:100. Remember from our PE1 configuration all traffic exported from the
first client A router/PE1 will use RD 20:1 for all subnets it communicates with. Therefore, its
important that RD 20:1 is configured as a route target import for both VRF instances CEA
and CEB.
ROUTEHUB-PE2
route-map ROUTEHUB-PBR-CEB-EXP permit 10

match ip address 2
route-map ROUTEHUB-PBR-CEB-IMP permit 10

match ip address 1
ip vrf CEA
ip vrf CEB
import map ROUTEHUB-PBR-CEB-IMP
export map ROUTEHUB-PBR-CEB-EXP
No unique monitoring command is needed to view the operations with our MPLS Extranet
configuration. However, confirm the following scenarios below .
Confirm CE1-A can ping IP addresses located on CE2-A
Confirm CE1-A can ping IP addresses located on CE1-B
Confirm CE2-A cannot ping IP addresses located on CE1-B
Confirm CE1-B cannot ping IP addresses located on CE2-A

4.6 VRF Selection
The network design for our MPLS VRF Selection will consist of the following details:
Requirements:
Our network will consist of a Service Provider network and a single client network with two
different departments, Human Resources and Engineering. Our client network has three
locations, one is the HQ site with two remote offices. One of the remote offices is dedicated
for Human Resources (CE5) and the other remote office is dedicated for Engineering (CE6).
Here is the unique part, our client wants these two departments to be isolated from each
other with no route or traffic leakage between them. However, at the HQ office, the local CE
router (called CE1 in the diagram) only has one physical interface to the MPLS provider.
Our Service Provider will be configured to virtualize client networks across its network without
any route or traffic leakage between other clients added in the future.

management.
within the Service Provider network
Allow multiple VRF instances to be associated to the same physical interface on the
PE router connected to the HQ CE router.
Client network needs two separate routing domains (one for HR and the one of ENG)
with no route and traffic leakage between them either.
Topology:
Topology: our WAN/MAN topology within our Service Provider will be a 2Tier model
consisting of a Core and a two Aggregation routers. Our MAN Core will be our
MPLS P router and our MAN Aggregation will be the two PE routers in the MPLS
network giving us a two-tier topology. PE1 will connect with CE1 (HQ) and PE2 will
connect with two CE sites (CE5 and CE6).
As for subnet information for reference our Human Resources subnets will include the
following:
10.5.1.0 /24
10.5.2.0 /24
As for subnet information for reference our Engineering subnet will include the following:
10.6.1.0 /24
10.6.2.0 /24

MPLS VPN VRF Selection sub-service will be used to allow multiple VRF instances
to be associated to the same physical interface on the PE router.
Since we will be using VRF Selection within our MPLS design we will need to use
other IP and Security services to include Policy Base Routing and Access Lists.
As a best practice will include a single BGP Route Reflector router that our two PE
routers would peer with to provide better reliability and scalability on the MPLS
network.
We will use static routing where needed for our client site routing.

Feature set for our MPLS devices to support the requirements and topology services
in our design.
Network Diagram

configured used for management, MPLS peering, and MP-BGP peering used in a later step.
Below is our basic IP configuration for our MPLS Provider Core router:
ROUTEHUB-P
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 10.1.3.1 255.255.255.0
ip address 10.1.2.1 255.255.255.0
ROUTEHUB-PE1
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.1.2.2 255.255.255.0
ROUTEHUB-PE2
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip address 10.1.3.3 255.255.255.0

devices on our network.
Basic IP Configuration step. These subnets will be advertised to all routers within the MPLS
device ID.
device ID.
ROUTEHUB-P
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0

ROUTEHUB-PE1
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
ROUTEHUB-PE2
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0

running.
ROUTEHUB-P
mpls ip
mpls ip
ROUTEHUB-PE1
mpls ip
ROUTEHUB-PE2
mpls ip

We will configure two VRF instances on our MPLS network. One will be for Human
Resources (labeled as HR) and the other will be for Engineering (labeled as ENG) based on
the diagram.
Once the VRF instances have been defined we will associate the VRF to the physical
interface on our PE2 router that the CE device is connected to base on the diagram.
We will use VRF Selection on PE1 to associate the two VRF instances for the CE1 interface.
ROUTEHUB-PE1
ip vrf ENG
rd 60:600
ip vrf HR
rd 50:500
Below is our VRF configuration for our MPLS PE2 router and associate their corresponding
CE interfaces.
ROUTEHUB-PE2
ip vrf ENG
rd 60:600
ip vrf HR
rd 50:500
ip vrf forwarding HR
ip address 10.5.2.1 255.255.255.0
ip vrf forwarding ENG
ip address 10.6.2.1 255.255.255.0

STEP 5: IGP ROUTING FOR VRF
On our PE1 router will setup two static routes pointing to the CE1 router that has HOST5 and
HOST6 on its local LAN.
We need to add these routes to ensure that our PE1 router knows where to route the HR and
ENG subnets to.
ROUTEHUB-PE1
ip route vrf HR 10.5.1.0 255.255.255.0 10.2.4.4
ip route vrf ENG 10.6.1.0 255.255.255.0 10.2.4.4
STEP 6: CE AND HOST CONFIGURATION

In this step we will configure the basic IP details on all of our CE and HOST devices depicted
in the network diagram.
Below is our configuration for our CE1 router (ROUTEHUB-CE1):
ROUTEHUB-CE1
ip address 10.2.4.4 255.255.255.0
ip address 10.6.1.1 255.255.255.0 secondary
ip address 10.5.1.1 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.2.4.2
ROUTEHUB-CE5
ip address 10.5.2.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.5.2.1
ROUTEHUB-CE6
ip address 10.6.2.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.6.2.1

We will also include the configuration for our two HOST routers that will emulate as our
HOST computers or nodes on the LAN behind the CE1 router:
ROUTEHUB-HOST5
interface FastEthernet0
ip address 10.5.1.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.5.1.1
ROUTEHUB-HOST6
ip address 10.6.1.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.6.1.1

MPLS PE routers.
MPLS network.
Once this is completed we should be able to see a BGP peer established between the two
PE routers with some partial routes until VRF selection has been successfully configured.
Below is our MP-BGP configuration for our PE1 router peering to PE2:
ROUTEHUB-PE1
router bgp 6778
no synchronization
no auto-summary
exit-address-family
address-family ipv4 vrf HR

redistribute static
no synchronization
exit-address-family

address-family ipv4 vrf ENG
redistribute static
no synchronization
exit-address-family
Below is our MP-BGP configuration for our PE2 router peering to PE1:
ROUTEHUB-PE2
router bgp 6778
no synchronization
no auto-summary
exit-address-family

redistribute connected
no synchronization
exit-address-family

no synchronization
exit-address-family
STEP 8: VRF SELECTION CONFIGURATION

Now onto our VRF Selection configuration. First we need to configure two ACLs for the two
subnets on our CE1 LAN.
One for our HR LAN subnet, 10.5.0.0 /16 and the other for our ENG subnet of 10.6.0.0 /16.
Even though our configured LAN subnets for the HR and ENG are using /24 for their mask,
this ACL will summarize all subnets that fall within the /16 bit boundaries and our /24 subnets
fall into this range.
ROUTEHUB-PE1
Next we will configure two Policy Base Routes (PBR), one for HR and the other ENG. They
will be configured to match the previously configured ACL.
For the first PBR, any matches with the configured ACL with ID of 5 will use this policy will be
placed into the configured VRF HR instance.
route-map ROUTEHUB-PBR-VS permit 10

match ip address 5
set vrf HR

For the second PBR, any matches with the configured ACL with ID of 6 would use this policy
will be placed into the configured VRF ENG instance.

match ip address 6
set vrf ENG
Next we will enable VRF HR and ENG together on the same physical interface if there is
match from the applied policy map also configured under this interface.
ip vrf receive HR
ip vrf receive ENG
ip address 10.2.4.2 255.255.255.0
ip policy route-map ROUTEHUB-PBR-VS
The policy map applied to the interface basically tells us that it will match 10.5.0.0 and
10.6.0.0 subnets as the source, that would then be mapped to either the VRF HR or ENG
domain.
At this point HOST5 should be able to ping IP addresses located on the CE5 router, but it
should not be able to communicate with any nodes (HOST6 or CE6) on the ENG network.
Vice Versa HOST6 should be able to ping IP addresses located on the CE6 router, but it
should not be able to communicate with any nodes (HOST5 or CE5) on the HR network.
As a recap, below is the summary for the actual VRF Selection configured needed:
ROUTEHUB-PE1

match ip address 5
set vrf HR

match ip address 6
set vrf ENG
ip vrf receive HR
ip vrf receive ENG
ip address 10.2.4.2 255.255.255.0

4.7 Traffic Engineering (TE)
The network design for our MPLS Traffic Engineering (TE) will consist of the following details:
Requirements:
Our MPLS network will consist of a Service Provider network and a single client network.
Our Service Provider network will consist of two Core routers and three Aggregation routers
connecting to client locations and the MPLS Core itself.
Our Service Provider will be configured to virtualize client networks across the Service
Provider network without any route or traffic leakage between other clients added in the
future.
Our single client will have three locations and will communicate with each other via EIGRP
through the Service Provider's MPLS network. It's important that there is no route and traffic
leakage between other client routing domains within the Service Provider network. One of
the client sites will be HQ (CE-B) which consist of a data center hosting various user services
accessed by the two remote sites (CE-L and CE-R).
Our client will not be deploying QoS as of today, but do require a premium service for their
two remotes to the HQ/Data Center location with a certain amount of guarantee bandwidth
and delivery through the Service Provider's network. For simplicity in our design, since the
traffic flow is minimal, the client wants to reserve 150kbps of guarantee bandwidth between
CE-L and HQ (CE-B). And reserve 25Kbps of guarantee bandwidth between CE-R and HQ
(CE-B).
Communication for both remote sites is important, but CE-L should have a high priority over
the CE-R site if bandwidth resources cannot be allocated for both sites.

management.
within the Service Provider network.
Reserve 150kbps bandwidth between CE-L and CE-B sites. Reserve 25Kbps
between CE-R and CE-B sites.
If bandwidth resources are overwhelmed, the bandwidth reserve should be allocated
to the CE-L site over the CE-R site.
Topology:
Topology: our WAN/MAN topology for our Service Provider network will be a 2Tier
model consisting of the two Core and the two Aggregation routers. Our Aggregation
routers will each connect with one CE site.
In our network design, the naming standard will be based on the MPLS component type (e.g.
P, PE, or CE) followed by its location in the diagram (e.g. Top, Bottom, Left, Right). For

example, in our design MPLS router P-T stands for the MPLS Provider Core TOP since it is
located at the TOP in the design diagram.

MPLS VPN: Traffic Engineering (TE) sub-service will be used to provide InteServ
type QoS by using tunnel priority and reserve bandwidth for these tunnels using
RSVP.

Feature set for our MPLS devices to support the requirements and topology services
in our design.
Network Diagram

configured to be used for management, MPLS peering, and MP-BGP peering used in a later
step.
Below is our basic IP configuration for our two MPLS Provider Core routers in our network:
ROUTEHUB-P-T
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 10.1.2.1 255.255.255.0
ip address 10.1.3.1 255.255.255.0
ip address 10.1.4.1 255.255.255.0
ROUTEHUB-P-B
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.1.2.2 255.255.255.0
ip address 10.2.3.2 255.255.255.0
ip address 10.2.4.2 255.255.255.0
ip address 10.2.5.2 255.255.255.0
Below is our basic IP configuration for our three MPLS Provider Edge routers all connected
into MPLS Core:
ROUTEHUB-PE-L
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip address 10.1.3.3 255.255.255.0
ip address 10.2.3.3 255.255.255.0
ROUTEHUB-PE-R
interface Loopback0
ip address 4.4.4.4 255.255.255.255

ip address 10.1.4.4 255.255.255.0
ip address 10.2.4.4 255.255.255.0
ROUTEHUB-PE-B
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip address 10.2.5.5 255.255.255.0

devices on our network.
device ID.
device ID.
Below is the OSPF configuration for our two MPLS P routers:
ROUTEHUB-P-T
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
network 10.1.4.0 0.0.0.255 area 0
ROUTEHUB-P-B
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
network 10.2.3.0 0.0.0.255 area 0
network 10.2.4.0 0.0.0.255 area 0
network 10.2.5.0 0.0.0.255 area 0
Below is the OSPF configuration for the three MPLS PE routers:
ROUTEHUB-PE-L
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
network 10.2.3.0 0.0.0.255 area 0

ROUTEHUB-PE-R
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.1.4.0 0.0.0.255 area 0
network 10.2.4.0 0.0.0.255 area 0
ROUTEHUB-PE-B
router ospf 5
network 5.5.5.5 0.0.0.0 area 5
network 10.2.5.0 0.0.0.255 area 0

running.
Below is our LDP configuration for our two MPLS Provider Core routers:
ROUTEHUB-P-T
mpls ip
mpls ip
mpls ip
ROUTEHUB-P-B
mpls ip
mpls ip
mpls ip
mpls ip

Below is our LDP configuration for our three MPLS Provider Edge routers:
ROUTEHUB-PE-L
mpls ip
mpls ip
ROUTEHUB-PE-R
mpls ip
mpls ip
ROUTEHUB-PE-B
mpls ip

We will configure one VRF instance on our MPLS network called "private".
Below is our VRF configuration for our MPLS PE-L router:
ROUTEHUB-PE-L
ip vrf private
rd 10:100
ip vrf forwarding private
ip address 10.3.6.3 255.255.255.0

Below is our VRF configuration for our MPLS PE-R router:
ROUTEHUB-PE-R
ip vrf private
rd 10:100
ip address 10.4.8.4 255.255.255.0
Below is our VRF configuration for our MPLS PE-B router:
ROUTEHUB-PE-B
ip vrf private
rd 10:100
ip address 10.5.7.5 255.255.255.0
No VRF configuration is required on our MPLS P routers.

VRF "private". EIGRP must be configured on the CE router and its connected PE router. In
Below is our VRF EIGRP configuration for our MPLS PE-L router:
ROUTEHUB-PE-L
router eigrp 1
auto-summary
address-family ipv4 vrf private
network 10.3.6.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
Below is our VRF EIGRP configuration for our MPLS PE-R router:
ROUTEHUB-PE-R
router eigrp 1
auto-summary

network 10.4.8.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
Below is our VRF EIGRP configuration for our MPLS PE-B router:
ROUTEHUB-PE-B
router eigrp 1
auto-summary
network 10.5.7.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
No client VRF Routing for EIGRP is required on our MPLS P routers.

No MPLS or VRF configuration is required or needed on the CE devices.
Below is our IP and EIGRP configuration for our CE-L router:
ROUTEHUB-CE-L
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip address 10.3.6.6 255.255.255.0
router eigrp 10
network 6.6.6.6 0.0.0.0
network 10.3.6.0 0.0.0.255
no auto-summary
Below is our IP and EIGRP configuration for our CE-R router:
ROUTEHUB-CE-R
interface Loopback0
ip address 8.8.8.8 255.255.255.255
ip address 10.4.8.8 255.255.255.0
router eigrp 10
network 8.8.8.8 0.0.0.0
network 10.4.8.0 0.0.0.255
no auto-summary

Below is our IP and EIGRP configuration for our CE-B router:
ROUTEHUB-CE-B
interface Loopback0
ip address 7.7.7.7 255.255.255.255
ip address 10.5.7.7 255.255.255.0
router eigrp 10
network 7.7.7.7 0.0.0.0
network 10.5.7.0 0.0.0.255
no auto-summary

MPLS PE routers.
MPLS network.
PE routers with some partial routes until VRF selection has been successfully configured.
Below is our MP-BGP configuration for our MPLS PE-L router:
ROUTEHUB-PE-L
router bgp 6778
no synchronization
no auto-summary
exit-address-family

no synchronization
exit-address-family
router eigrp 1
auto-summary
Below is our MP-BGP configuration for our MPLS PE-R router:
ROUTEHUB-PE-R
router bgp 6778
no synchronization
no auto-summary
exit-address-family

no synchronization
exit-address-family
router eigrp 1
auto-summary
Below is our MP-BGP configuration for our MPLS PE-B router:
ROUTEHUB-PE-B
router bgp 6778
no synchronization
no auto-summary

exit-address-family

no synchronization
exit-address-family
router eigrp 1
auto-summary
STEP 9: ENABLE MPLS TE

Once MPLS VPN has been configured and confirmed that everything is working we can now
enable TE services on-top of our MPLS network.
First we need to enable MPLS TE globally on all MPLS P and PE routers including all
interfaces connected into the MPLS network. Not VRF enabled interfaces.
Below we will enable MPLS TE globally and enable TE under all MPLS interfaces for our
MPLS P-T router:
ROUTEHUB-P-T
mpls traffic-eng tunnels
MPLS P-B router:
ROUTEHUB-P-B

MPLS PE-L router:
ROUTEHUB-PE-L
MPLS PE-R router:
ROUTEHUB-PE-R
MPLS PE-B router:
ROUTEHUB-PE-B
STEP 10: CONFIGURE MPLS TE EXTENSION TO OSPF

Next we will configure MPLS TE extension into OSPF to allow TE to learn OSPF routing
topology for building TE tunnels through the MPLS network.
For the MPLS TE extension OSPF configuration, we will use the loopback interface as the TE
router ID since loopback interfaces do not physically go down. An OSPF best practice in
general.
Below is our MPLS TE extension into OSPF configuration on our MPLS P-T router:
ROUTEHUB-P-T
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0

Below is our MPLS TE extension into OSPF configuration on our MPLS P-B router:
ROUTEHUB-P-B
router ospf 2
Below is our MPLS TE extension into OSPF configuration on our MPLS PE-L router:
ROUTEHUB-PE-L
router ospf 3
Below is our MPLS TE extension into OSPF configuration on our MPLS PE-R router:
ROUTEHUB-PE-R
router ospf 4
Below is our MPLS TE extension into OSPF configuration on our MPLS PE-B router:
ROUTEHUB-PE-B
router ospf 5
STEP 11: CONFIGURE RSVP FOR MPLS TE TUNNELS

Next we will configure RSVP for managing bandwidth services for TE tunnels between PE
routers and signaling among the MPLS routers that resources are not available.
RSVP bandwidth for all interfaces will be 512Kbps.
Below is the RSVP configuration for our MPLS P-T router:
ROUTEHUB-P-T
ip rsvp bandwidth 512 512
Below is the RSVP configuration for our MPLS P-B router:
ROUTEHUB-P-B

Below is the RSVP configuration for our MPLS PE-L router:
ROUTEHUB-PE-L
Below is the RSVP configuration for our MPLS PE-R router:
ROUTEHUB-PE-R
Below is the RSVP configuration for our MPLS PE-B router:
ROUTEHUB-PE-B
As a best practice manage the RSVP bandwidth amount enough to accommodate the
configured TE tunnel bandwidth configured or will be configured.
Confirm the expected Label switch path (LSP) for the TE tunnels through the MPLS network.

STEP 12: DYNAMIC MPLS TE TUNNEL CONFIGURATION
As a recap our dynamic TE tunnel will be built from our PE-R router to our PE-B router
dynamically by providing a best service LSP for our CE-R and CE-B sites for data forwarding.
Using Dynamic TE tunnels allows our TE tunnel to be built in anyway or path through the
MPLS network unlike static TE tunnels which requires the same explicit path that is
configured.
For our dynamic tunnel it only needs to be configured on our PE-R router. No dynamic MPLS
TE tunnel configuration is needed on the PE-B router.
For our Dynamic MPLS TE Tunnel Configuration we will do the following:
1. We will configure a GRE tunnel on the MPLS router

2. We will use the loopback interface IP for the Dynamic MPLS TE tunnel. It will build
the dynamic TE tunnel through the MPLS network to MPLS router 5.5.5.5 (PE-B).
3. Last we will configure our Dynamic MPLS TE tunnel to use bandwidth amount of
25Kbps (RSVP is configured for 512kbps, so its within the boundaries) with a priority
of "5" meaning lower the priority the more preferred the TE tunnel will be established
over others.
Below is our Dynamic MPLS TE configuration on our MPLS PE-R router:
ROUTEHUB-PE-R
interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 5 5
tunnel mpls traffic-eng bandwidth 25
tunnel mpls traffic-eng path-option 1 dynamic
no routing dynamic

STEP 13: STATIC MPLS TE TUNNEL CONFIGURATION
As a recap our static TE tunnel will be built from the PE-L router to our PE-B router statically
by providing a best service LSP for our CE-L and CE-B sites for data forwarding.
Using Static TE tunnels we have to specify the exact path our TE tunnel will be built. If RSVP
signals anywhere along the LSP that there isn't enough bandwidth the static TE tunnel will
not be built as a best service and is routed normally through the MPLS network without any
bandwidth guarantee.
For our Static MPLS TE Tunnel Configuration we will do the following:
1. We will specify the actual path the static TE tunnel will be built. TE tunnel will be built
from PE-R --> P-T --> P-B --> PE-B routers where OSPF & dynamic TE tunnels
would likely choose a shorter path to the PE-B router.
2. We will configure a GRE tunnel on MPLS router.
3. We will use the loopback interface IP for the Static MPLS TE tunnel. Our static TE
will be built along its explicit path to MPLS router 5.5.5.5 (PE-B).
4. Lastly we will configure our static MPLS TE tunnel to use bandwidth amount of
150Kbps (RSVP is configured for 512kbps, so its within the boundaries). The Static
TE tunnel will use TE tunnel policy static-te for its actual switching path. We will
use a priority of "2" meaning lower the priority more preferred the TE tunnel will be
established over others. Therefore if our RSVP bandwidth number was lower our
Static TE tunnel would have preference over our configured Dynamic TE tunnel.
Below is our Static MPLS TE configuration on our MPLS PE-L router:
ROUTEHUB-PE-L
ip explicit-path name static-te enable
next-address 10.1.3.1

interface Tunnel2
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 2 2
tunnel mpls traffic-eng bandwidth 150
tunnel mpls traffic-eng path-option 1 explicit name static-te
no routing dynamic

4.8 MPLS QoS: Uniform Mode
The network design for MPLS QoS (using Uniform mode) will consist of the following details:
Requirements:
Our MPLS network will consist of a Service Provider network and a single client network.
Our Service Provider network will consist of a single Core router and two Aggregation routers
connecting to a client location and the MPLS Core itself.
Our Service Provider will also be configured to virtualize client networks its network without
any route or traffic leakage between other clients added in the future.
Our single client will have two locations and will communicate with each other via EIGRP
through the Service Provider's MPLS network. It's important that there is no route nor traffic
leakage between other client routing domains within the Service Provider network.
Within each site there will be a Core router that would connect into the Clients Edge Router
(connected into the MPLS network).
Our client will be deploying QoS across their sites for providing priority for certain traffic in the
event there is congestion anywhere within the network. Therefore, it will be important for our
client to understand the QOS mechanisms used with the MPLS provider.
Topology:
Our WAN/MAN topology for our Service Provider network will be a two-tier model
consisting of a Core and two Aggregation routers. Our Aggregation routers will each
connect with one CE site.

In our MPLS QoS design we will use Uniform mode for our ISP QoS deployment where the
ISP and the CE share the same DiffServ domain, meaning they both trust what their
markings and re-markings will be.
Our ISP will use a three-class policy consisting of real-time traffic, critical data, and best effort
(default if nothing is marked).
Our client is aware of this three-class policy and will adjust their outbound QoS policies out to
the IP WAN to reflect that for proper end-to-end QoS operations between the sites.
Below is a summary with our applicable services and sub-services used in our design:
MPLS QoS using Uniform mode.


Feature set for our MPLS routers to support the requirements and topology services
in our design.
Network Diagram:

configured to be used for management, MPLS peering, and MP-BGP peering used in a later
step.
configuring the interface that will connect between the two PE routers.
ROUTEHUB-P
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 10.1.2.1 255.255.255.0
no shutdown
ip address 10.1.3.1 255.255.255.0
no shutdown

ROUTEHUB-PE1
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 10.1.2.2 255.255.255.0
no shutdown
ROUTEHUB-PE2
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip address 10.1.3.3 255.255.255.0
no shutdown

devices.
device ID.
device ID.
ROUTEHUB-P
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
ROUTEHUB-PE1
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
ROUTEHUB-PE2
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0

running.
ROUTEHUB-P
mpls ip
mpls ip
ROUTEHUB-PE1
mpls ip
ROUTEHUB-PE2
mpls ip

We will configure one VRF instance on our MPLS network called "ClientA".
ROUTEHUB-PE1
ip vrf ClientA
rd 10:100

ip vrf forwarding ClientA
ip address 10.2.4.2 255.255.255.0
no shutdown
ROUTEHUB-PE2
ip vrf ClientA
rd 10:100
ip address 10.3.5.3 255.255.255.0
no shutdown
STEP 6: IGP ROUTING FOR VRF

VRF "ClientA". EIGRP must be configured on the CE router and its connected PE router. In
All routes learned within this VRF will be isolated to that routing table only.
ROUTEHUB-PE1
router eigrp 1
auto-summary
address-family ipv4 vrf ClientA
network 10.2.4.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
ROUTEHUB-PE2
router eigrp 1
auto-summary
network 10.3.5.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family

STEP 7: CE AND C ROUTER CONFIGURATION
ROUTEHUB-CE1
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip address 10.2.4.4 255.255.255.0
no shutdown
ip address 10.4.6.4 255.255.255.0
no shutdown
router eigrp 100

network 4.4.4.4 0.0.0.0
network 10.2.4.0 0.0.0.255
network 10.4.6.0 0.0.0.255
no auto-summary
Below is our configuration for the C1 router (ROUTEHUB-C1):
ROUTEHUB-C1
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip address 10.4.6.6 255.255.255.0
no shutdown
router eigrp 100

network 6.6.6.6 0.0.0.0
network 10.4.6.0 0.0.0.255
no auto-summary
ROUTEHUB-CE2
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip address 10.3.5.5 255.255.255.0
no shutdown
ip address 10.5.7.5 255.255.255.0
no shutdown

router eigrp 100
network 5.5.5.5 0.0.0.0
network 10.3.5.0 0.0.0.255
network 10.5.7.0 0.0.0.255
no auto-summary
Below is our configuration for the C2 router (ROUTEHUB-C2):
ROUTEHUB-C2
interface Loopback0
ip address 7.7.7.7 255.255.255.255
ip address 10.5.7.7 255.255.255.0
no shutdown
router eigrp 100

network 7.7.7.7 0.0.0.0
network 10.5.7.0 0.0.0.255
no auto-summary

MPLS PE routers.
MPLS network.
PE routers and our two client sites should be able to communicate with one another.
ROUTEHUB-PE1
router bgp 6778
no synchronization
no auto-summary

exit-address-family

no synchronization
exit-address-family
router eigrp 1
ROUTEHUB-PE2
router bgp 6778
no synchronization
no auto-summary
exit-address-family

no synchronization
exit-address-family
router eigrp 1
STEP 9: CLIENTA LAN CORE QOS POLICY

In this step we will start our QoS configuration starting with our LAN Core router at each site.
Lets start with the Core router at site 1.
We will configure a basic QoS policy where all ICMP (Ping) traffic from our LAN will be
marked with DSCP 25 outbound to the MPLS network to the other site while other traffic not
marked will use best effort (DSCP 0).
On our first LAN Core router we will enable CEF (which is required) and configure an access-
list defining what we want to classify, which will be ICMP traffic.
ROUTEHUB-C1
ip cef
access-list 100 permit icmp any any

We will associate our configured ICMP ACL to a class map:
class-map match-any RHG-CM-QOS

match access-group 100
Our configured class map will then be associated to a policy map where any matches to the
class map (any ICMP traffic out to the other site) will be marked with DSCP 25.
policy-map RHG-PM-QOS
class RHG-CM-QOS
set dscp 25
Our configured policy will be mapped to the uplink interface towards client edge router.
By default the total bandwidth allocated for a policy map is 75%. If the policy map total
bandwidth numbers (CBWFQ and LLQ) exceed 75% it won't allow us to apply the policy map
to the interface. Therefore, we can configure the option "max-reserved-bandwidth 100"
which changes the allocated number from 75% to 100%. This is also configured on our
interface.
max-reserved-bandwidth 100
service-policy output RHG-PM-QOS
We will make an addition to our with our QoS policy where we will mark all FTP traffic with
DSCP EF outbound to the MPLS network and the other CE site.
access-list 101 permit tcp any any eq 21
class-map match-any RHG-CM-QOS1

class RHG-CM-QOS1
set dscp ef
Below is the complete QoS configuration for our LAN Core router at the second site will be
identical to what we configured at the first site except we will not include marking of FTP
traffic:
ROUTEHUB-C2
ip cef

class RHG-CM-QOS
set dscp 25

STEP 10: CE QOS CONFIGURATION
The QoS markings from our LAN Core for each site will now reach the Edge router
(connected into the MPLS) whether it is ICMP or FTP traffic.
We will configure a similar QoS policy on our CE routers using a simple Three Class Policy.
Our three classes will be the following:

1) Real-Time
2) Critical Data
3) Best Effort
Essentially as you will see our ICMP traffic (marked with DSCP 25) will be re-marked on our
CE router to DSCP AF31 (part of our Critical Data class). Our FTP traffic (marked with
DSCP EF) will retain its markings through the CE router. The reason for the re-marking is for
two reasons:
1) Re-mark traffic to match MPLS EXP mappings when it reaches the PE router
2) Provide sufficient amount of queuing resources for certain traffic to the IP WAN
(MPLS) if congestion occurs on the CEs WAN interface.
First we will define our class-maps on our CE1 router matching what has or could be marked
from the C1 router:
ROUTEHUB-CE1
class-map match-all ROUTING
match ip dscp cs6
class-map match-all VOICE-DATA

match ip dscp ef
class-map match-all VIDEO

match ip dscp af41
class-map match-all DATA-CRITICAL

match ip dscp 25
class-map match-any VOICE-CONTROL

match ip dscp af31
match ip dscp cs3
class-map match-all DATA-TRANS

match ip dscp af21
class-map match-all DATA-MGMT

match ip dscp cs2
class-map match-all DATA-SCAVENGER

match ip dscp cs1
Next we will configure our policy map that will match the configured class maps, specify the
bandwidth reserve for certain traffic using LLQ (for Real Time traffic) or CBWFQ (Routing,
Critical Data, Transactional Data, Network Management, Scavenger, and Best Effort traffic).
policy-map CE-PM-THREE-CLASS
class ROUTING
bandwidth percent 3

class VOICE-DATA
priority percent 18
class VIDEO
priority percent 15
set ip dscp cs5
class VOICE-CONTROL
priority percent 2
set ip dscp cs5
class DATA-CRITICAL
bandwidth percent 20
random-detect
set ip dscp af31
class DATA-TRANS
random-detect
set ip dscp cs3
class DATA-MGMT
bandwidth percent 2
set ip dscp cs3
class DATA-SCAVENGER
bandwidth percent 1
class class-default
random-detect
Last we will enable our QOS policy out to the MPLS network.
service-policy output CE-PM-THREE-CLASS
Based on this configuration our ICMP traffic will be re-marked to DSCP AF31 and our FTP
traffic will still be DSCP EF going into the MPLS.
Below is the complete QoS configuration for our second CE router (CE2) at the second site,
which is identical to what we configured at the first site:
ROUTEHUB-CE2
match ip dscp cs6

match ip dscp ef

match ip dscp af41

match ip dscp 25

match ip dscp af31
match ip dscp cs3

match ip dscp af21

match ip dscp cs2

match ip dscp cs1
class ROUTING
bandwidth percent 3
class VOICE-DATA
priority percent 18
class VIDEO
priority percent 15
set ip dscp cs5
class VOICE-CONTROL
priority percent 2
set ip dscp cs5
class DATA-CRITICAL
random-detect
set ip dscp af31
class DATA-TRANS
random-detect
set ip dscp cs3
class DATA-MGMT
bandwidth percent 2
set ip dscp cs3
bandwidth percent 1
class class-default
random-detect

STEP 11: PE QOS POLICY
Now we start our QoS configuration in our MPLS. As we discussed in our requirements we
will use Uniform Mode for our QoS configuration.
Using Uniform mode means that the Service Provider trust and uses the marked QoS values
from the CE, but they are mapped to the MPLS EXP instead of DSCP or IP Precedence
values.
Therefore, our ICMP traffic marked with DSCP AF31 (from the CE router) will be mapped to
MPLS EXP 3. Our FTP traffic marked with DSCP EF (from C router) will be mapped to
MPLS EXP 5.
This is done automatically without any needed configuration on our PE router.
As the ICMP or FTP packet travels through the MPLS network it may run against a policer
that may re-mark the packet if it exceeded the configured bandwidth throughput. This would
re-mark the MPLS EXP in the top label that would later be pushed down to the actual clients
IP packet.
When the packet travels from the P to the PE2 router we know that the top label is POPPED
(or removed). Whatever MPLS EXP bits are marked will be copied to the bottom label. The
MPLS EXP from the bottom label will be copied to a temporary place because that bottom
label will soon be removed when it reaches the CE site. That is why we need to copy the
MPLS EXP info, so it can be copied to the client packet. This temporary place is called a
QoS Group.
So the configuration below copies the MPLS EXP from the bottom label to a QoS group
temporarily. This policy is always applied inbound from our Provider Core:
ROUTEHUB-PE1
policy-map RHG-PM-ME-QG
class class-default
set qos-group mpls experimental topmost
service-policy input RHG-PM-ME-QG
Next we will copy the contents in our QoS group to IP Precedence (or DSCP) to match the
last MPLS EXP values. This policy is applied on the downlink towards the CE device:
policy-map RHG-PM-QG-IPP
class class-default
set precedence qos-group
service-policy output RHG-PM-QG-IPP
Below is the same configuration needed on our PE2 router:
ROUTEHUB-PE2
class class-default

class class-default
STEP 12: MPLS QOS VALIDATION

The next thing to do, which will be listed also under the "Monitor" section for reference is how
do we confirm if QoS operations through the MPLS network is correct.
Well we can issue the command "show policy interface" to reflect stats on the applied policy
map in terms of the number of packets matching a specific class, but we don't know for sure
if our ICMP and FTP traffic, as an example, is actually being marked correctly using DSCP
(on our CE network) or MPLS EXP (on our MPLS network).
There are no good show commands to see what is marked in our packets, so we would need
to run a network sniffer on our Ethernet connections.
Let's confirm if our ICMP traffic is being marked correctly.
From our C1 router (10.4.6.6) we will ping the loopback interface IP on the C2 router, which
is 7.7.7.7.
Doing so from C1 we know that the traffic will be marked to DSCP 25 up to the CE1 router.
The CE1 router will re-mark that to AF31 up to the MPLS network.
Below is what we have captured between our PE1 and P routers:

Let's look at one of the ICMP request messages in this capture. Here we see the MPLS Top
Label (16), the MPLS Bottom Label (22), and our IP Header which consist of our ICMP data
encapsulated.
When we extend our IP Header detail there we can see that our ICMP message is marked to
DSCP AF31 from the CE. So we know that our CE1 router to PE1 (on the MPLS) has
successfully marked our ICMP traffic.
Since we are using Uniform mode our PE router will automatically map the IP Precedence
(DSCP) to MPLS EXP, which would be MPLS EXP 3.
Looking at the MPLS top label details we see that it is mapped to MPLS EXP 3, which is also
copied to the bottom label.

We can run other traces on other MPLS connections to confirm if our markings are still
retained (on the PE2 router for the P to PE2 connection):
And last it is important to confirm if our QoS markings are translated back from the MPLS to
our CE2 and C2 routers. Therefore, we want to confirm if our ICMP packet is still marked to
DSCP AF31.
Note: There may be a policer within the MPLS Provider Core that may mark down
our client data if traffic usage is exceeded to Best Effort. If this happens this would
be copied to the MPLS bottom label then later copied to our client's IP header which
would see the packet marked down to DSCP 0 or IP Precedence 0.
We can run the same traces to confirm our FTP traffic markings to use DSCP EF.

5 Monitor
5.1 Operations
5.1.1 show ip vrf brief

This command from PE2 shows brief info of what VRFs are configured including the RD ID
assigned and the interfaces they are mapped
5.1.2 show ip vrf detail

This command from PE2 shows detailed info of the VRF instance, CEA, including the RD ID
and what interface(s) it is mapped to. If polices for routing between other VRFs exist then
those details would be listed here.

5.1.3 show ip vrf interfaces
Similar command from a previous slide, but this command shows the interfaces and what
VRF it is associated with. Plus we can see the IP address configured on that interface and
the protocol status which is really a reflection of what you get when we issue the command
show ip interface brief.
5.1.4 show mpls ldp neighbor

This command from PE1 shows that we have one MPLS LDP peer established with 1.1.1.1,
which is our Provider Core router. Like OSPF, MPLS will choose the loopback IP as the
peering ID and IP address. This command will also show all IPs configured on that
connected neighbor, but will choose one for label switching peering. Use this command to
confirm that LDP peers are up and running, if not our MPLS operation will not work as
expected. Also note that routing among our MPLS network using OSPF or ISIS is required
before LDP neighbors can be established.

5.1.5 show mpls forwarding-table
The command show mpls forwarding table is available on all MPLS enabled routers. This
command is very important for viewing all MPLS tunnels established including the top labels
for MPLS delivery throughout the network including whether one label will be removed or
swapped when it is going to another MPLS device.
In this command, we know the last four entries in the list with a [V] at the end are subnets
associated or mapped to this PE device. We see that MPLS tunnels are built between a P
and another PE device.
This command also shows details on the amount of bytes switched, outgoing interface, and
next hop IP addresses.
5.1.6 show ip bgp summary

This command on PE2 shows that we have one iBGP or MP-BGP peer established with
another PE router at 2.2.2.2 (the loopback IP for PE1) both located in the same ASN, 6778.
This neighbor has been up for 6 seconds. We would use this command to confirm if MP-
BGP has been established in order to exchange VPN information on its configured VRF
instances.

5.1.7 show ip bgp vpnv4 vrf <vrf-name>
This command on PE2 shows all VPNv4 prefixes learned via MP-BGP from PE1. These
VPNv4 prefixes are translated back to IP (by stripping off the RD tag) learned from MP-BGP.
They are then redistributed into our IGP routing protocol configured for our VRF instance. If
we see routes listed here then we know that routes has been advertised successfully from
the other side. If not it could be an issue related to configuration or routes not properly
redistricted or advertised by the remote PE or CE device.
5.1.8 show ip route vrf <vrf-name>

This command on PE1 shows the routing table or RIB for the Client A VRF instance from a
PE device. PE1 is learning a BGP route from the other PE router and will then redistribute
this route into the IGP routing protocol isolated only Client A sites. Use this command to
confirm two things, is the PE device learning routes from its connected CE device and is the
PE device learning BGP routes from the other PE devices that has CE devices in the same
VRF instance. If not check configuration with the routing protocols including proper
redistribution.

5.1.9 show ip eigrp neighbor
This command on the Client B router configured for EIGRP as its IGP routing protocol for that
routing domain shows that we have an EIGRP neighbor established with its PE router, which
is important especially if we want to send and receive routes to all other Client B sites on the
network.
5.1.10 show ip cef vrf <vrf-name>

When data is being forwarded between sites through the MPLS network it uses the LFIB
table or CEF table for that VRF instance for its forwarding decision. This
shows the LFIB for VRF Client B prefixes which are isolated from Client As FIB. These
packets are hardware switched when IP CEF is enabled.

5.1.11 show mpls traffic-eng tunnels brief
This command from PE-R router shows the status for all dynamic and static tunnels built
across the MPLS network. This shows one active TE tunnel (which is a dynamic tunnel) to
the PE-B router (5.5.5.5). It shows that RSVP is running, which is important for maintaining
our LSPs.
5.1.12 show mpls traffic-eng link-management bandwidth-allocation

This command from PE-L shows the bandwidth details of TE tunnels built through the MPLS
network. Here we see that we have one TE tunnel using the Fa0/0 interface and reserving
29% (150kbps) of the configured RSVP bandwidth which is 512Kbps.

5.1.13 show ip cef vrf <vrf-name>
This command from PE-B shows the MPLS TE topology, which shows a tunnel with router
4.4.4.4 (PE-R) using 25kbps of bandwidth leaving 487kbps available bandwidth that we
configured RSVP to have 512kbps.

5.1.14 show mpls traffic-eng tunnels Tunnel 1
This is a great command to use to verify if the TE tunnel configured is up and running best of
service. If there any issues such as bandwidth resources not being available it would tell us
that the Path is down or not valid. We would also see the Signaling being down.
ROUTEHUB-PE-R#show mpls traffic-eng tunnels Tunnel 1

Name: ROUTEHUB-PE-R_t1 (Tunnel1) Destination: 5.5.5.5
Status:
Admin: up Oper: down Path: not valid Signalling: Down
path option 1, type dynamic
When we see this we can do a few things:

1. Confirm that all our configuration is correct with the TE deployment
2. Confirm if RSVP is enabled on all applicable MPLS interfaces and if the correct
bandwidth number is configured.
3. Another likely issue could be related to exactly what we described earlier, not enough
bandwidth resources, so we can determine what resources are being overwhelmed
or try increasing the RSVP number or lowering the TE tunnel bandwidth.
4. There may be other TE tunnels, confirm if those tunnels are up by using the same
command. If they are up then we know that either our down TE has a lower TE
priority (configured with a higher value) or there isnt enough bandwidth.
5.1.15 show policy-map interface for MPLS QoS

The command "show policy interface" is the best command to use for viewing the operations
of our applied policy map on our interfaces.
Using this command we can confirm if our marked traffic is reaching the correct class that is
using the applied queuing, policing, or re-marking policy that is configured.
We would look at the number of packets to confirm if our policy is working, though, we don't
know for sure if our packets are being marked correctly. This output maybe reflecting some
other traffic.
ROUTEHUB-PE1#show policy-map interface fastEthernet 0/0

FastEthernet0/0
Service-policy output: RHG-PM-QG-IPP
Class-map: class-default (match-any)

241 packets, 21400 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
precedence qos-group
Packets marked 18
FastEthernet0/1

Service-policy input: RHG-PM-ME-QG

Match: any
QoS Set
qos-group mpls experimental topmost
Packets marked 18

FastEthernet0/0
Service-policy input: RHG-PM-ME-QG

Match: any
QoS Set
qos-group mpls experimental topmost
Packets marked 40
ROUTEHUB-PE2#
ROUTEHUB-PE2#
FastEthernet0/1
Service-policy output: RHG-PM-QG-IPP

Match: any
QoS Set
precedence qos-group
Packets marked 40
ROUTEHUB-PE2#
The best way to confirm QoS markings through a network is to use a network sniffer to view
what our traffic is being marked to.

5.2 Traffic Flow for MPLS
5.2.1 Understanding MPLS Labels

TOP LABEL : placed by Label Protocol (e.g. LDP)
BOTTOM LABEL : placed by MP-BGP (VPNv4)
As MPLS packets travel through the network they consist of labels which may contain a TOP
LABEL and a BOTTOM LABEL.
The TOP label is placed by the Label protocol which can be TDP or LDP
The Bottom label is placed by the MP-BGP protocol
5.2.2 MPLS Labels in Traceroutes

If we do a traceroute for a specific network on the VRF:
traceroute vrf <vrf-name> IP address
The traceroute will show us the top and bottom labels
5.2.3 MPLS: Bottom Label

First, to determine/confirm the BOTTOM LABEL (MP-BGP) we use:
show ip bgp vpnv4 vrf <vrf-name> <ip-address/subnet>
That will show us the label and the next hop along the Label Switch Path (LSP)
5.2.4 MPLS: Top Label

Then, we can see the TOP LABEL (LDP) by issuing:
show mpls forwarding-table
There we look for that next-hop IP address along our LSP showing us our TOP LABEL

5.2.5 MPLS: PUSH, SWAP, and POP
Labels exchanged from PE to P
Are PUSHED
Labels exchanged from P to P

Are SWAPPED
Labels exchanged from P to PE

Are POPPED
As MPLS packets travel through the MPLS networks the top label can be added, removed, or
swapped with a different top label. You can see MPLS labels as a mechanism for knowing
how to forward MPLS packets through a network.
How MPLS labels are handled is based on what MPLS components it travels through.
Labels exchanged from PE to P devices, the top label is PUSHED or ADDED to the MPLS
packet.
Labels exchanged from P to P devices, the top label is SWAPPED with a different top label
unique for that second P device.
Labels exchanged from P to PE device, the top label is POPPED or REMOVED leaving only
our bottom label which then on our PE device knows how to handle the MPLS packet.

5.2.6 Traffic Flow Example
Step 1: Do traceroute from MPLS PE router
Now lets show an example to further explain this process based on the network design we
setup for the MPLS VPN module.
Starting with PE1 we will do a traceroute to 6.6.6.6 sourced within the VRF instance CEA.
Doing the traceroute we see the labels assigned for each hop throughout the MPLS network.
Line 1 goes to the P router hence the TOP label is placed or PUSHED to the P router. Line
2 goes from the P to the PE2 router where the TOP label is removed or POPPED leaving
only the bottom label to PE2 which then knows how to route it.
Step 2: Checking the Bottom Label on MPLS PE router

To confirm the BOTTOM label (which happens first) we will issue this following command
using the subnet 6.6.6.6 that exists within our VRF network CEA. We also see that the next
hop to 6.6.6.6 along the LSP is 3.3.3.3., our PE2 device This is important for the next step.
The bottom line reflects the BOTTOM label, which is 21.

Step 3: Checking the Top Label on MPLS PE router
To confirm the TOP label we will issue the following command and look for the IP address of
the next hop IP along the LSP, which was 3.3.3.3. Therefore, since this is Outgoing
towards its destination it will be assigned (or PUSHED) a TOP label of 17. That is shown in
the traceroute.
Step 4: Checking the Top Label on the MPLS P router at the next hop
We reach the P router and we find our TOP label of 17 listed. Since this will be switched
from P to PE our TOP label is removed (or POPPED), which is reflected as Pop tag leaving
behind our bottom label of 21 when is then matched locally on our PE2 router for the subnet
6.6.6.6 found in VRF instance CEA.

5.3 Traffic Flow for MPLS QoS
The next thing to do is to we confirm if QoS operations through the MPLS network is correct.
Well we can issue the command "show policy interface" to reflect stats on the applied policy
map in terms of the number of packets matching a specific class, but we don't know for sure
if our ICMP and FTP traffic, as an example, is actually being marked correctly using DSCP
(on our CE network) or MPLS EXP (on our MPLS network).
There are no good show commands to see what is marked in our packets, so we would need
to run a network sniffer on our Ethernet connections.
Let's confirm if our ICMP traffic is being marked correctly.
From our C1 router (10.4.6.6) we will ping the loopback interface IP on the C2 router, which
is 7.7.7.7.
Doing so from C1 we know that the traffic will be marked to DSCP 25 up to the CE1 router.
The CE1 router will re-mark that to AF31 up to the MPLS network.
Below is what we have captured between our PE1 and P routers:
Let's look at one of the ICMP request messages in this capture. Here we see the MPLS Top
Label (16), the MPLS Bottom Label (22), and our IP Header which consist of our ICMP data
encapsulated.

When we extend our IP Header detail there we can see that our ICMP message is marked to
DSCP AF31 from the CE. So we know that our CE1 router to PE1 (on the MPLS) has
successfully marked our ICMP traffic.
Since we are using Uniform mode our PE router will automatically map the IP Precedence
(DSCP) to MPLS EXP, which would be MPLS EXP 3.
Looking at the MPLS top label details we see that it is mapped to MPLS EXP 3, which is also
copied to the bottom label.
We can run other traces on other MPLS connections to confirm if our markings are still
retained (on the PE2 router for the P to PE2 connection):

And last it is important to confirm if our QoS markings are translated back from the MPLS to
our CE2 and C2 routers. Therefore, we want to confirm if our ICMP packet is still marked to
DSCP AF31.
Note: There may be a policer within the MPLS Provider Core that may mark down
our client data if traffic usage is exceeded to Best Effort. If this happens this would
be copied to the MPLS bottom label then later copied to our client's IP header which
would see the packet marked down to DSCP 0 or IP Precedence 0.
We can run the same traces to confirm our FTP traffic markings to use DSCP EF.

5.4 Troubleshooting
5.4.1 Root Causes

Once a network has been deployed and working operational any issue that will occur will
likely be due to one of the following below:
1. User Error
2. Software Error or Failure
3. Hardware Error or Failure
4. Power Error or Failure
5. Traffic Increase
6. Security Related
7. Third-Party Components
5.4.2 Initial questions to ask

Once a network has been deployed and working operational any issue that will occur will
likely be due to the following:
1. What has changed recently anywhere on the network?
a. Not just routers or switch, but with servers and various services such as
DNS, SMTP, etc. This tends to be the most common issue we have seen
where different groups make services changes like DNS, as an example, and
certain things on the network break where nothing was changed on the
routers or firewalls. However, the DNS changes affected some of the other
services on the network. That group who made the change will assume that
they didn't think that change would affect the network. Remember, IT is all
connected in more than one way, so validating all changes with all IT groups
is critical to confirm what could break including other considerations. Plus
any changes should rerun (or test) there baseline punch list to confirm that
all services outlined in the baseline are operational as they were before and
after any changes.
2. Confirm for any network changes? If so, check for configuration syntax errors and
cross check against a known working configuration.

5.4.3 Typical fixes
Identifying the root cause and resolving it are two separate things. Fixing a problem will
usually involve one or more of the following
Configuration change or rollback

Reboot
Software upgrade
Hardware replacement
It may require a configuration change or a rollback to a previously working configuration

known to work.
A reboot may do it or a software upgrade may be needed where a bug has emerged and/or a
hardware replacement may be needed, though is very rare.
5.4.4 General MPLS Troubleshooting
Identifying the root cause and resolving it are two separate things. Fixing a problem will
usually involve one or more of the following
Matching route distinguisher (RD) for VRF

Correct route-target import and export for VRF
VRF interface association
MP-BGP peering and VPNv4 announcements
Other troubleshooting relating to MPLS can include the following:
Make sure to use the same RD or route distinguisher for the same VRF configured.
Remember a VRF is a like a VLAN but for Layer 3 networks.
Confirm that you have the correct route-targets for import and export especially if routing
between VRFs occurs. Follow the configuration for MPLS EXTRANET for those details.
Also make sure to have the right interfaces associated or mapped to the right VRF instance.
If routes are not being received for CE devices within a VRF domain confirm that we have our
iBGP session established between all applicable PE devices. Make sure that mutual route
redistribution is configured between the BGP and the VRF IGP routing protocol.

6 Full Configuration
6.1 MPLS VPN
6.1.1 ROUTEHUB-P
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ROUTEHUB-P
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255

!
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.1.3.1 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
!
ip http server
no ip http secure-server
ip forward-protocol nd
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.1.2 ROUTEHUB-PE1
!
version 12.4
!
hostname ROUTEHUB-PE1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model

memory-size iomem 5
!
!
ip cef
!
!
ip vrf CEA
rd 10:100
!
ip vrf CEB
rd 11:100
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 10.2.4.2 255.255.255.0
duplex auto
speed auto
!
ip address 10.2.5.2 255.255.255.0
duplex auto
speed auto
!
ip address 10.1.2.2 255.255.255.0
duplex auto
speed auto

mpls ip
!
router eigrp 1
no auto-summary
!
network 10.2.5.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
network 10.2.4.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!
exit-address-family
!
no synchronization
exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!

!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.1.3 ROUTEHUB-PE2
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf CEA
rd 10:100
!
ip vrf CEB
rd 11:100
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive

log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 10.1.3.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.3.7.3 255.255.255.0
duplex auto
speed auto
!
ip address 10.3.6.3 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
no auto-summary
!
network 10.3.7.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
network 10.3.6.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!

exit-address-family
!
no synchronization
exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.1.4 ROUTEHUB-CE1-A
!
version 12.1
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
!
hostname ROUTEHUB-CE1-A
!
!
!
!
!
!
memory-size iomem 15
ip subnet-zero
!
ip audit notify log
ip audit po max-events 100

!
!
!
!
!
!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 10.2.4.4 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 10
network 4.4.4.4 0.0.0.0
network 10.2.4.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
!
version 12.1
!
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!

!
!
!
!
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 10.3.6.6 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 10
network 6.6.6.6 0.0.0.0
network 10.3.6.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.1.6 ROUTEHUB-CE1-B
!
version 12.1
!
hostname ROUTEHUB-CE1-B
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!

!
!
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 10.2.5.5 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 10
network 5.5.5.5 0.0.0.0
network 10.2.5.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
!
version 12.1
!
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!
!
!

!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
ip address 10.3.7.7 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 10
network 7.7.7.7 0.0.0.0
network 10.3.7.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end

6.2 MPLS using Route Reflectors
6.2.1 ROUTEHUB-P
!
version 12.4
!
hostname ROUTEHUB-P
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
mpls ip

!
ip address 10.1.4.1 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.1.3.1 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
network 10.1.4.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.2.2 ROUTEHUB-PE1
!
version 12.4
!

!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf CE
rd 10:100
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 10.1.2.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.2.5.2 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
auto-summary

!
network 10.2.5.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!
exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.2.3 ROUTEHUB-PE2

!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf CE
rd 10:100
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 10.1.3.3 255.255.255.0
duplex auto
speed auto
mpls ip
!

ip address 10.3.6.3 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
auto-summary
!
network 10.3.6.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!
exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end

6.2.4 ROUTEHUB-RR
!
version 12.4
!
hostname ROUTEHUB-RR
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 10.1.4.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
no ip address

shutdown
duplex auto
speed auto
!
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.1.4.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.2.5 ROUTEHUB-CE1
!
version 12.1

!
hostname ROUTEHUB-CE1
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!
!
!
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 10.2.5.5 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 10
network 5.5.5.5 0.0.0.0
network 10.2.5.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.2.6 ROUTEHUB-CE2
!
version 12.1
!

!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!
!
!
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 10.3.6.6 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 10
network 6.6.6.6 0.0.0.0
network 10.3.6.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.3 MPLS over GRE
6.3.1 INTERNET
!
version 12.1

!
hostname INTERNET
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
!
ip address 10.1.3.1 255.255.255.0
duplex auto
speed auto
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.3.2 ROUTEHUB-P1
!
version 12.4
!
hostname ROUTEHUB-P1
!

boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
ip address 10.2.3.2 255.255.255.0
mpls ip
!
ip address 10.2.4.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.1.2.2 255.255.255.0
duplex auto
speed auto
!
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.2.3.0 0.0.0.255 area 0

network 10.2.4.0 0.0.0.255 area 0
!
ip http server
ip route 0.0.0.0 0.0.0.0 10.1.2.1
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.3.3 ROUTEHUB-PE1
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf CE
rd 10:100
!
!
!
!

!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 10.4.6.4 255.255.255.0
duplex auto
speed auto
!
ip address 10.2.4.4 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.4.8.4 255.255.255.0
duplex auto
speed auto
!
network 10.4.6.0 0.0.0.255 area 0
network 10.4.8.0 0.0.0.255 area 0
!
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.2.4.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!

exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.3.4 ROUTEHUB-CE11
!
version 12.4
!
!
boot-start-marker
boot-end-marker

!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 10.4.6.6 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router ospf 6
network 6.6.6.6 0.0.0.0 area 6
network 10.4.6.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!

!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.3.5 ROUTEHUB-CE12
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!

!
!
!
!
!
!
!
interface Loopback0
ip address 8.8.8.8 255.255.255.255
!
ip address 10.4.8.8 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router ospf 8
network 8.8.8.8 0.0.0.0 area 8
network 10.4.8.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.3.6 ROUTEHUB-P2
!
version 12.4
!

!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
ip address 10.2.3.3 255.255.255.0
mpls ip
!
ip address 10.1.3.3 255.255.255.0
duplex auto
speed auto
!
ip address 10.3.5.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 3

network 3.3.3.3 0.0.0.0 area 3
network 10.2.3.0 0.0.0.255 area 0
network 10.3.5.0 0.0.0.255 area 0
!
ip http server
ip route 0.0.0.0 0.0.0.0 10.1.3.1
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.3.7 ROUTEHUB-PE2
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf CE
rd 10:100
!
!

!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 10.3.5.5 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.5.7.5 255.255.255.0
duplex auto
speed auto
!
ip address 10.5.9.5 255.255.255.0
duplex auto
speed auto
!
network 10.5.7.0 0.0.0.255 area 0
network 10.5.9.0 0.0.0.255 area 0
!
router ospf 5
network 5.5.5.5 0.0.0.0 area 5
network 10.3.5.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary

!
exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.3.8 ROUTEHUB-CE21
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!

!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 9.9.9.9 255.255.255.255
!
ip address 10.5.9.9 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router ospf 9
network 9.9.9.9 0.0.0.0 area 9
network 10.5.9.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!
!

!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.3.9 ROUTEHUB-CE22
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!

!
!
!
!
!
!
!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
ip address 10.5.7.7 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router ospf 7
network 7.7.7.7 0.0.0.0 area 7
network 10.5.7.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.4 Extranet

6.4.1 ROUTEHUB-P
!
version 12.4
!
hostname ROUTEHUB-P
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.1.3.1 255.255.255.0
duplex auto
speed auto

mpls ip
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.4.2 ROUTEHUB-PE1
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf CEA
import map ROUTEHUB-PBR-CEA-IMP
export map ROUTEHUB-PBR-CEA-EXP
rd 10:100

!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 10.1.2.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.2.4.2 255.255.255.0
duplex auto
speed auto
!
network 10.2.4.0 0.0.0.255 area 0
!
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary

!
exit-address-family
!
redistribute ospf 20
no synchronization
exit-address-family
!
ip http server
!
!
!
!
route-map ROUTEHUB-PBR-CEA-EXP permit 10
match ip address 1
!
route-map ROUTEHUB-PBR-CEA-IMP permit 10
match ip address 2
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end

6.4.3 ROUTEHUB-PE2
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf CEA
rd 10:100
!
ip vrf CEB
rd 20:200
import map ROUTEHUB-PBR-CEB-IMP
export map ROUTEHUB-PBR-CEB-EXP
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 10.1.3.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.3.5.3 255.255.255.0
duplex auto
speed auto
!
ip address 10.3.6.3 255.255.255.0
duplex auto
speed auto
!
network 10.3.5.0 0.0.0.255 area 0
!
network 10.3.6.0 0.0.0.255 area 0
!
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!
exit-address-family
!
redistribute ospf 31 vrf CEB
no synchronization
exit-address-family
!
redistribute ospf 30 vrf CEA
no synchronization
exit-address-family
!
ip http server
!
!

!
!
route-map ROUTEHUB-PBR-CEB-EXP permit 10
match ip address 2
!
route-map ROUTEHUB-PBR-CEB-IMP permit 10
match ip address 1
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
!
version 12.1
!
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!

!
!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 10.2.4.4 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router ospf 4
network 4.4.4.4 0.0.0.0 area 4
network 10.2.4.0 0.0.0.255 area 0
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
!
version 12.1
!
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!

!
!
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 10.3.5.5 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router ospf 5
network 5.5.5.5 0.0.0.0 area 5
network 10.3.5.0 0.0.0.255 area 0
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
!
version 12.1
!
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!

!
!
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
ip address 10.3.6.6 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router ospf 6
network 6.6.6.6 0.0.0.0 area 6
network 10.3.6.0 0.0.0.255 area 0
!
ip classless
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.5 VRF Selection

6.5.1 ROUTEHUB-P
!
version 12.4
!
hostname ROUTEHUB-P
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 10.1.3.1 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto

mpls ip
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.5.2 ROUTEHUB-PE1
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf ENG
rd 60:600
!

ip vrf HR
rd 50:500
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip vrf receive HR
ip vrf receive ENG
ip address 10.2.4.2 255.255.255.0
duplex auto
speed auto
!
ip address 10.1.2.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!

exit-address-family
!
redistribute static
no synchronization
exit-address-family
!
redistribute static
no synchronization
exit-address-family
!
ip http server
ip route vrf HR 10.5.1.0 255.255.255.0 10.2.4.4
ip route vrf ENG 10.6.1.0 255.255.255.0 10.2.4.4
!
!
!
!
match ip address 5
set vrf HR
!
match ip address 6
set vrf ENG
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.5.3 ROUTEHUB-PE2
!
version 12.4

!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf ENG
rd 60:600
!
ip vrf HR
rd 50:500
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 10.1.3.3 255.255.255.0
duplex auto
speed auto
mpls ip

!
ip vrf forwarding HR
ip address 10.5.2.1 255.255.255.0
duplex auto
speed auto
!
ip vrf forwarding ENG
ip address 10.6.2.1 255.255.255.0
duplex auto
speed auto
!
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!
exit-address-family
!
no synchronization
exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!

!
end
6.5.4 ROUTEHUB-CE1
!
version 12.1
!
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!
!
!
!
ip address 10.2.4.4 255.255.255.0
duplex auto
speed auto
!
ip address 10.6.1.1 255.255.255.0 secondary
ip address 10.5.1.1 255.255.255.0
duplex auto
speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.2.4.2
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.5.5 ROUTEHUB-CE5
!

version 12.1
!
!
!
!
!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!
!
!
!
ip address 10.5.2.2 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.5.2.1
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.5.6 ROUTEHUB-CE6
!
version 12.1
!
!
!
!

!
!
!
ip subnet-zero
!
ip audit notify log
!
!
!
!
!
!
!
ip address 10.6.2.2 255.255.255.0
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.6.2.1
ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.5.7 ROUTEHUB-HOST5
!
version 12.2
!
hostname ROUTEHUB-HOST5
!
logging queue-limit 100
!
ip subnet-zero
!
!
!
!
!
!
!
interface Ethernet0
no ip address

shutdown
half-duplex
!
ip address 10.5.1.10 255.255.255.0
speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.5.1.1
no ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
no scheduler allocate
end
6.5.8 ROUTEHUB-HOST6
!
version 12.2
!
hostname ROUTEHUB-HOST6
!
!
ip subnet-zero
!
!
!
!
!
!
!
interface Ethernet0
no ip address
shutdown
half-duplex
!
ip address 10.6.1.10 255.255.255.0
speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.6.1.1
no ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!

end
6.6 MPLS QoS: Uniform Mode
6.6.1 ROUTEHUB-P
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5

class-map match-any DATA-CRITICAL
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
!
!
policy-map RHG-PM-POLICE
class REALTIME
police cir 100000
conform-action set-mpls-exp-topmost-transmit 5
exceed-action set-mpls-exp-topmost-transmit 0
class DATA-CRITICAL
police cir 8000
class class-default
police cir 8000
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
mpls ip
service-policy input RHG-PM-POLICE
!
ip address 10.1.3.1 255.255.255.0
duplex auto
speed auto
mpls ip
service-policy input RHG-PM-POLICE
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.1.2.0 0.0.0.255 area 0
network 10.1.3.0 0.0.0.255 area 0
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!

!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.6.2 ROUTEHUB-PE1
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf ClientA
rd 10:100
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!

!
class class-default
class class-default
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip address 10.2.4.2 255.255.255.0
duplex auto
speed auto
!
ip address 10.1.2.2 255.255.255.0
duplex auto
speed auto
mpls ip
!
router eigrp 1
auto-summary
!
network 10.2.4.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
router ospf 2
network 2.2.2.2 0.0.0.0 area 2
network 10.1.2.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization
no auto-summary
!
exit-address-family
!
no synchronization
exit-address-family
!
ip http server

!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.6.3 ROUTEHUB-PE2
!
version 12.4
!
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip vrf ClientA
rd 10:100
!
!
!
!
!
!
!
!

!
!
!
!
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
class class-default
class class-default
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 10.1.3.3 255.255.255.0
duplex auto
speed auto
mpls ip
!
ip address 10.3.5.3 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
auto-summary
!
network 10.3.5.0 0.0.0.255
default-metric 10000 1 255 1 1500
no auto-summary
exit-address-family
!
router ospf 3
network 3.3.3.3 0.0.0.0 area 3
network 10.1.3.0 0.0.0.255 area 0
!
router bgp 6778
no synchronization

no auto-summary
!
exit-address-family
!
no synchronization
exit-address-family
!
ip http server
!
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
6.6.4 ROUTEHUB-CE1
!
version 12.2
!
!
!
ip subnet-zero
!
!
!
ip audit notify log
!

call rsvp-sync
!
!
!
!
!
!
!
match ip dscp cs2
match ip dscp 25
match ip dscp af31
match ip dscp cs3
match ip dscp af41
match ip dscp cs6
match ip dscp cs1
match ip dscp af21
match ip dscp ef
!
!
class ROUTING
bandwidth percent 3
class VOICE-DATA
class VIDEO
set ip dscp cs5
class VOICE-CONTROL
set ip dscp cs5
class DATA-CRITICAL
random-detect
set ip dscp af31
class DATA-TRANS
random-detect
set ip dscp cs3
class DATA-MGMT
bandwidth percent 2
set ip dscp cs3
bandwidth percent 1
class class-default
random-detect
!
!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ip address 10.4.6.4 255.255.255.0
duplex auto
speed auto
!
ip address 10.2.4.4 255.255.255.0

duplex auto
speed auto
!
router eigrp 100
network 4.4.4.4 0.0.0.0
network 10.2.4.0 0.0.0.255
network 10.4.6.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
dial-peer cor custom
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.6.5 ROUTEHUB-C1
!
version 12.2
!
hostname ROUTEHUB-C1
!
!
ip subnet-zero
!
!
!
ip cef
!
!
!
!
!
class RHG-CM-QOS
set dscp 25
!
!
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!

ip address 10.4.6.6 255.255.255.0
speed auto
!
router eigrp 100
network 6.6.6.6 0.0.0.0
network 10.4.6.0 0.0.0.255
no auto-summary
!
ip classless
no ip http server
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.6.6 ROUTEHUB-CE2
!
version 12.2
!
!
!
ip subnet-zero
!
!
!
ip audit notify log
!
call rsvp-sync
!
!
!
!
!
!
!
match ip dscp cs2
match ip dscp 25
match ip dscp af31
match ip dscp cs3
match ip dscp af41

match ip dscp cs6
match ip dscp cs1
match ip dscp af21
match ip dscp ef
!
!
class ROUTING
bandwidth percent 3
class VOICE-DATA
class VIDEO
set ip dscp cs5
class VOICE-CONTROL
set ip dscp cs5
class DATA-CRITICAL
random-detect
set ip dscp af31
class DATA-TRANS
random-detect
set ip dscp cs3
class DATA-MGMT
bandwidth percent 2
set ip dscp cs3
bandwidth percent 1
class class-default
random-detect
!
!
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
ip address 10.3.5.5 255.255.255.0
duplex auto
speed auto
!
ip address 10.5.7.5 255.255.255.0
duplex auto
speed auto
!
router eigrp 100
network 5.5.5.5 0.0.0.0
network 10.3.5.0 0.0.0.255
network 10.5.7.0 0.0.0.255
no auto-summary
!
ip classless
ip http server
!
!
dial-peer cor custom
!

!
!
!
!
line con 0
line aux 0
line vty 0 4
!
end
6.6.7 ROUTEHUB-C2
!
version 12.2
!
hostname ROUTEHUB-C2
!
!
ip subnet-zero
!
!
!
ip cef
!
!
!
!
!
class RHG-CM-QOS
set dscp 25
!
!
!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
ip address 10.5.7.7 255.255.255.0
speed auto
!
router eigrp 100
network 7.7.7.7 0.0.0.0
network 10.5.7.0 0.0.0.255
no auto-summary
!
ip classless
no ip http server
!
!

!
line con 0
line aux 0
line vty 0 4
!
end

Routehub TUNNEL L3VPN MPLS PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Routehub TUNNEL L3VPN MPLS PDF

Cargado por

Copyright:

Formatos disponibles

MPLS VPN

RouteHub Group, LLC

January 23, 2009

END USER LICENSE FOR ONE (1) PERSON ONLY

2. Price and Payment

4. Replacement, Modification and/or Upgrades

13. Entire Agreement

6 Full Configuration 121

RouteHub Group, LLC Page 8 www.routehub.net

2.1 MPLS VPN

2.2 MPLS VPN: Infrastructure Components

Provider Core (P)

2.2.1 Provider Core or P router

2.2.2 Provider Edge or PE router

2.2.3 Customer Edge or CE router

RouteHub Group, LLC Page 9 www.routehub.net

2.3 MPLS VPN: Services

MPLS VPN consists of the following components:

VPN Routing and Forwarding (VRF)

2.3.1 VPN Routing and Forwarding (VRF)

2.3.2 IGP Routing: OSPF, IS-IS

TOP and BOTTOM Labels

RouteHub Group, LLC Page 10 www.routehub.net

PUSH, SWAP, and POP

2.3.4 VPNv4 prefixes

2.3.5 Multi-Protocol BGP (MP-BGP)

RouteHub Group, LLC Page 11 www.routehub.net

2.4.1 Route Reflectors

2.4.2 VRF Selection

2.4.3 Traffic Engineering (TE)

RouteHub Group, LLC Page 12 www.routehub.net

2.4.5 MPLS over GRE, MPLS over DMVPN

2.4.6 MPLS and Quality of Service (QoS)

2.4.6.1 Uniform Mode

RouteHub Group, LLC Page 13 www.routehub.net

Remember they share and trust the same DiffServ domain.

2.4.6.2 Short Pipe Mode

2.4.6.3 Pipe Mode

2.4.6.4 Short Pipe vs. Pipe Mode

2.5 MPLS VPN: Best Practices

RouteHub Group, LLC Page 14 www.routehub.net

RouteHub Group, LLC Page 15 www.routehub.net

RouteHub Group, LLC Page 16 www.routehub.net

Below are the solutions we can choose from.

RouteHub Group, LLC Page 17 www.routehub.net

This can include the following services:

RouteHub Group, LLC Page 18 www.routehub.net

RouteHub Group, LLC Page 19 www.routehub.net

4.1 Initial Configuration

Next enable all interfaces by issuing a no shutdown

Once that has been completed we need to check on two things.

RouteHub Group, LLC Page 20 www.routehub.net

Topology Services and Sub-Services

Hardware & Software:

RouteHub Group, LLC Page 21 www.routehub.net

STEP 2: BASIC IP CONFIGURATION

RouteHub Group, LLC Page 22 www.routehub.net

Below is the OSPF configuration for our MPLS P router:

Below is the OSPF configuration for both of the MPLS PE routers:

RouteHub Group, LLC Page 23 www.routehub.net

Below is our LDP configuration on our MPLS Provider Core router:

RouteHub Group, LLC Page 24 www.routehub.net

Below is our VRF configuration for our MPLS PE1 router: