Versatile Routing and Services with BGP E-Book

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 393

Veröffentlichungsjahr: 2014

Beschreibung

Design a robust BGP control plane within a secure, scalable network for smoother services A robust Border Gateway Protocol setup is vital to ensuring reliable connectivity, an essential capability for any organization. The Internet has become a necessary, always-on service in homes and businesses, and BGP is the protocol that keeps communication flowing. But BGP also has become crucial to delivery of intra-domain business services. But the network is only as reliable as BGP, so service enablement depends upon making BGP more stable, reliable, and service-rich. Alcatel-Lucent Service Router Operating System is engineered to bear the load of the most demanding networks. The system features support for Symmetric Multiprocessing and unprecedented depth of advanced routing features, all within a single OS that's supported across the entire Alcatel-Lucent IP/MPLS router portfolio. Versatile Routing and Services with BGP provides guidance toward implementation of BGP within SR-OS, and details the use and control of each feature. The book provides in-depth coverage of topics such as: * BGP/MPLS IP-VPN, VPLS, VPWS * Labeled Unicast IPv4, reconvergence, and multicast * Security, graceful restart and error handling * IPv6 PE (6PE) and IPv6 extensions to BGP/MPLS IP-VPN * A look at forthcoming features such as Ethernet VPN Basic BGP competency is assumed, but the book is accessible even to those with zero familiarity with Alcatel-Lucent's SR-OS. It underscores the idea that BGP is more than just service enablement, and can also be used for infrastructure layer transport - but both layers must be solid, scalable, and able to quickly reconverge. Versatile Routing and Services with BGP demonstrates the creation of a robust BGP control plane within a, secure network, allowing the delivery of flawless, uninterrupted service.

Leseprobe

Table of Contents

Foreword

Introduction

Chapter 1: Getting Started

Session Negotiation and Capabilities

Chapter 2: BGP/MPLS IP-VPN

Basic Configuration

Prefix Dissemination

Extensions for IPv6 VPN (6VPE)

Multi-AS Backbones (Inter-AS)

Chapter 3: Using BGP in VPLS

BGP Auto-Discovery with LDP Signaling

BGP Auto-Discovery and Signaling

BGP Multi-Homing

Chapter 4: BGP Signaling for VPWS

BGP VPWS

Dynamic Multi-Segment Pseudowire

Chapter 5: Labeled Unicast IPv4

Seamless MPLS

Inter-AS Type C

Carriers' Carrier

Notes

Chapter 6: Reconvergence

Advertisement of Multiple Paths

Best External

Next-Hop Tracking

Prefix Independent Convergence (PIC)

Minimum Route Advertisement Interval

BGP Anycast

Chapter 7: Multicast

Inter-Domain IPv4-IPv6 PIM

Multicast in MPLS/BGP IP-VPNs

Chapter 8: Graceful Restart and Error Handling

Graceful Restart Mechanism

Error Handling

Chapter 9: Security

FlowSpec

Remote Triggered Blackholing

Generalized TTL Security Mechanism

Auto-Generation of Filters for BGP Peers

Chapter 10: General Applicability

IPv6 PE Router (6PE)

Load-Balancing

IGP Shortcuts

Split Horizon

Peer Groups

BGP in Residential Broadband Networks

QoS Policy Propagation Using BGP

Route Policy Framework

Notes

Chapter 11: Looking Ahead

Ethernet VPN (EVPN)

Control-Plane-Only Route-Reflection

Prefix Origin Validation

Link State Information Distribution Using BGP

Appendix A: Path Selection Process

Best-Path Selection Algorithm

Always-Compare-MED

Deterministic MED

References and Glossary

References

Glossary

Advertisement

Foreword

Over the past decade we have witnessed an exciting evolution of Internet Protocol (IP) networks from best-effort networks providing basic Internet access services to true multi-service networks providing fixed residential and mobile broadband services, business Virtual Private Network (VPN) services, cloud services, and carrying more and more mission-critical applications.

IP networks have gradually replaced most of the legacy networks of the past, resulting in more efficient and converged network infrastructures. This is not only the case for service provider and enterprise networks; the same evolution applies to strategic industry networks such as defense, energy, health care, transportation, and government networks.

When it comes to IP networking, there is arguably no protocol more important or successful than the Border Gateway Protocol (BGP)—it is the protocol that has tied the Internet together over the course of its impressive development in the past 20-plus years.

As the scope of IP networking has evolved over time, so has BGP. BGP has been extended to enable new services such as IP VPN (BGP/MPLS IPv4 VPN and 6VPE) and Layer 2 VPN (Virtual Private LAN, Virtual Leased Line, and BGP/MPLS based Ethernet VPN) services, to support network optimizations such as those provided by large-scale MPLS network designs—now commonly known as seamless MPLS—to simplify operations, to enhance network security and to improve network stability, resiliency and reconvergence performance. There is no other protocol that carries such a large and varied set of networking information and that is so central to many networking functions and services, both internally and between Autonomous Systems (AS).

This book deals with all aspects of this evolved BGP in a practical, hands-on manner, using the Alcatel-Lucent Service Router OS (SR-OS) implementation of BGP as the basis for a wealth of configuration examples. It's a great reference for networking engineers who require a comprehensive and current review on BGP and the specifics of the BGP implementation in SR-OS. I hope you will enjoy reading this book as much as I have.

Rudy Hoebeke Vice President of Product Management Alcatel-Lucent IP Routing & Transport Division

Introduction

As defined in the base specification for the Border Gateway Protocol (BGP), the primary function of a BGP speaking system is to exchange network reachability information with other BGP speakers while including information on the list of Autonomous Systems that the reachability information traverses. This information can be used to construct a graph of AS connectivity for this reachability, while at the same time removing routing loops and providing operators the ability to implement local policy.

The intention was clear. At its conception, BGP was to be used for exchanging Internet routes between Autonomous Systems/Internet Service Providers. As a result, the protocol was built with characteristics that above all provided a level of stability among the constant churn of the Internet routing table.

During the last 15 or so years the use of BGP has evolved significantly. From a deployment perspective, operators have learned from experience and shared those experiences with the wider community to everybody's mutual benefit. BGP is well understood and is considered a mature protocol. From a service delivery perspective, the evolution is two-fold:

The Internet is no longer perceived as a best-effort service. Instead, it has become a must-have, always-on service for businesses and homes.

BGP's scalability and flexibility, together with its numerous hooks that allow for application of policy, have made it the Service Provider's protocol of choice for service enablement.

So, while BGP remains the primary protocol for inter-domain route exchange, its use for delivery of intra-domain services has increased significantly. The base protocol has been extended many times to provide the ability to carry new reachability information. It thereby enables Service Providers to effectively deliver new services with minimum impact on their existing IP infrastructure using a known and deployed protocol. In addition, the protocol is evolving into new areas such as Data Centers with the advent of Ethernet VPN.

While this is happening and BGP is being used more and more to deliver business critical services, other base characteristics have changed. BGP is historically a slow-converging protocol, but fast-reconvergence upon failure has become an absolute requirement for delivery of high-profile services. Many potential consumers use fast reconvergence upon failure as a measuring stick of network performance. Incidents that result in the failure of BGP have become totally unacceptable, and so the base protocol has had to become more robust than early implementations.

Objective

The purpose of this book is to provide you with an all-encompassing single reference guide to the BGP implementation within Alcatel-Lucent SR-OS. It aims to equip you with sufficient knowledge to feel competent and confident about the technology you are addressing, and be able to maximize and optimize your implementation of BGP using SR-OS.

The book looks at how services can be delivered and how efficient routing can be achieved in both native IP networks and MPLS networks. It covers how you can use BGP to provide services such as Layer-2 VPNs and Layer-3 VPNs, as well as native or VPN-aware multicast and IPv6. At the core infrastructure layer, it looks at how you can use BGP to deliver scalable IP/MPLS networks using inter-AS and inter-domain scenarios.

In addition, the book covers techniques that you can use to improve path visibility and improve reconvergence times. It also looks at how procedures for error handling have evolved from the base BGP specification. It aims to detail the implications and considerations for each technology, and it gives design tips where appropriate.

For each feature, function, or technology that the book covers, the aim is to provide an overview of what it is and how it operates at a protocol level. The book then details the configuration requirements with CLI and debug outputs used to aid understanding. The objective is that you have a full understanding of the technology in question together with the knowledge of how to implement it in SR-OS.

Audience

The book is primarily intended for IP design and engineering communities. Familiarity with Alcatel-Lucent SR-OS is not a requirement, although readers who are familiar with SR-OS will recognize configuration examples and Command Line Interface (CLI) outputs.

You can read each chapter as a standalone chapter if, for example, you need some guidance on how to implement and configure a particular service and/or function, or even just to learn how a particular technology works. On the other hand, an avid reader passionate about BGP may choose to read from cover to cover.

To keep this book to a manageable size, I do not discuss the basic operation of BGP as a path vector protocol. Numerous other reference books provide this introductory information, and I assume that knowledge to be a prerequisite.

Want to Practice Some of These Configs?

You may want to try some of what you learn in this book in an SR-OS lab. Alcatel-Lucent can help you with its MySRLab Service.

The MySRLab Service provides you with remote access to a hosted Service Router lab so you can:

Test new network and service features.

Build your service routing knowledge and configuration skills.

MySRLab features include:

Remote, private access to a service router lab, available 24x7

Separate labs for wire-line and mobility lab applications

More than 50 lab practice scenarios and solution keys (optional)

Access to traffic simulation and analysis tools

Get started today by visiting:

www.alcatel-lucent.com/src/mysrlab

Chapter 1

Getting Started

Although this book does not discuss the operation of BGP as a path-vector protocol, it's worth a quick recap on how a BGP speaker processes and stores routes in the Routing Information Bases (RIBs). The RIB within a BGP speaker is made up of three distinct parts: the Adj-RIB-In, the Loc-RIB, and the Adj-RIB-Out. The Adj-RIB-In stores routing information learned from inbound UPDATE messages advertised by peers to the local router. The routes in the Adj-RIB-In represent routes that are available to the path decision process. The Loc-RIB contains routing information the local router selected after applying policy to the routing information contained in the Adj-RIB-In. These are the routes that will be used by the local router. The Adj-RIB-Out stores information the local router selected for advertisement to its peers. This information is carried in UPDATE messages sourced by this router when advertising to peers. In summary, the Adj-RIB-In contains unprocessed routing information advertised by peers to the local router, the Loc-RIB contains the routes that have been selected by the local BGP speaker's best-path decision process, and the Adj-RIB-Out contains the routes for advertisement to peers in UPDATE messages. I'll use this terminology throughout the book, and may interchangeably use Adj-RIB-In or simply RIB-In, and Adj-RIB-Out or simply RIB-Out.

Enabling BGP in its most basic form is a very simple exercise. All you need is an IP interface toward a BGP peer and some minimal BGP configuration. For conciseness, Output 1-1 does not show the IP interface configuration. For exchange of IPv4 reachability, the only parameters required are an Autonomous System (AS) number defined within the global router context (or Virtual Private Routed Network [VPRN] context), an IP address for the peer, and a peer AS number. The IP address and peer AS number are entered in a BGP group context, often referred to as a peer group. Peer groups allow you to group together a set of peers that have a common administrative configuration, and are discussed further in Chapter 10.

Output 1-1: Basic BGP Configuration

router autonomous-system 64496 bgp group “EBGP” neighbor 192.168.0.2 peer-as 64510 exit exit no shutdown exit exit

Session Negotiation and Capabilities

A Finite State Machine (FSM) is maintained for each BGP peer, and there are six possible states in the FSM. Initially, the FSM for the BGP peer is in the Idle state. In this state, the router listens for a TCP connection initiated by the remote peer or initiates the TCP connection itself. The second state is the Connect state, where the FSM is waiting for the TCP three-way handshake to be completed. If the TCP connection is not successfully established, the state is changed to Active and a further attempt is made to establish the TCP connection to the remote peer. (If the connection continues to fail, the FSM reverts to the Idle state.) If the TCP connection is successfully established, the FSM completes the BGP initialization, generates an OPEN message toward the peer, and changes its state to OpenSent. If an OPEN message is also received from the remote peer and the parameters contained in the OPEN message are acceptable, the router generates a KEEPALIVE message and changes its state to OpenConfirm. If the parameters of the OPEN message are not acceptable, a NOTIFICATION message is sent with the appropriate error code, and the state is reverted to Idle. While in the OpenConfirm state, if the router receives a KEEPALIVE message from the remote peer, it moves to the Established state. In the Established state, peers can send UPDATE messages to exchange routing information.

The OPEN message sent by each peer contains its AS number, Hold Time, BGP identifier, and some optional parameters. The notable optional parameter is the Capabilities parameter. The Capabilities parameter is defined in RFC 5942 and allows BGP speakers to exchange capability sets in the OPEN exchange. If both peers advertise a given capability, the peers can use that advertised capability on the peering. If either peer did not advertise the capability, it cannot be used.

The Capabilities parameter is encoded as a code, a length, and a value. The output in Debug 1-1 is taken from an OPEN negotiation between an SR-OS router and a test device. The SR-OS router sends its OPEN message with capability codes indicating support for IPv4 unicast Multi-Protocol (MP)-BGP, Route-Refresh, and 4-byte ASN support. The capability code for MP-BGP encodes a value (0x0 0x1 0x0 0x1) that represents an Address Family Identify (AFI) of IPv4 (0x0 0x01) and a Subsequent Address Family Identifier (SAFI) of unicast (0x0 0x1) indicating support only for IPv4 unicast MP-BGP. (The use of the AFI and SAFI for Multi-Protocol BGP is discussed in further detail later in this chapter.) The capability code for 4-Octet ASN also encodes a value indicating its 4-byte Autonomous System number. In this case the SR-OS router only has a 2-byte Autonomous System number; therefore, it is converted into a 4-byte Autonomous System number by setting the two high-order octets of the 4-octet field set to zero.

Figure 1-1 Finite State Machine

Conversely, the test device peer sends its OPEN message indicating support for IPv4 unicast MP-BGP, IPv6 unicast MP-BGP, and Route Refresh. In this OPEN message the capability code for MP-BGP appears twice; each occurrence contains a different capability value. The first occurrence indicates support for IPv4 unicast. The second occurrence, with value (0x0 0x2 0x0 0x1), represents an AFI of IPv6 (0x0 0x2) and a SAFI of unicast (0x0 0x1).

This asymmetric capability negotiation is acceptable from the perspective of the peering session, providing that the only optional capabilities used are IPv4 MP-BGP and Route-Refresh. If, for example, the peer advertises an IPv6 prefix using MP-BGP, this results in a NOTIFICATION message being sent. The integrity of the peering session thereafter is dependent on supported and configured error handling capabilities. Standard capabilities' codes are maintained by the Internet Assigned Numbers Authority (IANA) at www.iana.org/assignments/capability-codes/capability-codes.xml but vendor-specific capability codes are in widespread use. During capability exchange these should be ignored by a BGP speaker if not recognized.

Output 1-2: Local/Remote Capabilities

*A:R1# show router bgp neighbor 192.168.0.2 | match expression “Local|Remote” Local AS : 64496 Local Port : 179 Local Address : 192.168.0.1 Local Family : IPv4 Remote Family : IPv4 IPv6 Local Capability : RtRefresh MPBGP 4byte ASN Remote Capability : RtRefresh MPBGP Local AddPath Capabi*: Disabled Remote AddPath Capab*: Send - None

The Hold Times negotiated in the OPEN exchange do not have to be the same for the BGP session to be established. The BGP speaker calculates the active Hold Time value by using the smaller of its configured value and the value received in the OPEN message. In the OPEN exchange shown in Debug 1-1, SR-OS uses the default Hold Time of 90 seconds while the peer advertises a Hold Time of 30 seconds. This exchange results in both peers using a Hold Time of 30 seconds, with KEEPALIVE messages exchanged every (30/3) 10 seconds.

As previously described, when a BGP speaker has sent an OPEN message it moves to the OpenSent state, and when it has received a corresponding OPEN message from its peer it moves to OpenConfirm state. If the BGP speaker is happy with the contents of the received OPEN message, it responds with a KEEPALIVE message. When each BGP speaker has sent and received an OPEN message and KEEPALIVE message, they move to the ESTABLISHED state and can then exchange reachability information.

UPDATE Messages

This book does not explicitly detail all BGP message formats, but it's useful to review the basic BGP UPDATE format so you can understand the differences between it and the general format of Multi-Protocol BGP UPDATE messages. The Withdrawn Routes field contains a list of IP prefixes in the form <length, prefix> that are being withdrawn from service. The Network Layer Reachability Information (NLRI) field contains a list of IP prefixes, again in the form <length, prefix>, that can be reached from a given BGP speaker (subject to policy).

Debug 1-2: Active Hold Time

*A:R1# show router bgp neighbor 192.168.0.2 | match "Hold Time" Hold Time : 90 Keep Alive : 30 Min Hold Time : 0 Active Hold Time : 30 Active Keep Alive : 10

Figure 1-2 UPDATE Message Format

The Path attributes field contains a sequence of attributes associated with an NLRI and each attribute can be placed into one of four categories: well-known mandatory, well-known discretionary, optional transitive, and optional non-transitive. Non-transitive simply refers to the fact that this attribute may be advertised into an AS but may not leave that AS.

Mandatory attributes must be present in the UPDATE message if NLRI is present (that is, the UPDATE does not purely carry Withdraw routes) and include the ORIGIN, AS_PATH, and NEXT_HOP attributes. Examples of well-known discretionary attributes include LOCAL_PREF and ATOMIC_AGGREGATE.

At the beginning of the path attribute field there is a 2-octet field that contains an Attribute Flags octet followed by the Attribute Type Code octet as shown in Figure 1-3.

Figure 1-3 Path Attribute Flags

The Attribute Type Code is a value defining the type of Attribute. Within the Attribute Flags octet the high-order bit (bit 0) is the Optional bit and defines whether the attribute is optional (1) or well-known (0). Bit 1 is the Transitive bit and defines whether an optional attribute is transitive (1) or non-transitive (0). Bit 2 is the Partial bit and defines whether an optional transitive attribute is recognized by a BGP speaker when advertising it to peers (0), or unrecognized (1). Note that if a BGP speaker recognizes the optional transitive attribute (and would therefore set the partial bit to 0), but the partial bit has already been set to 1 by some other AS, it must not be set back to zero by the processing speaker. In effect, when set, the partial bit provides visibility that some BGP speaker along the path didn't recognize the attribute. Bits 4-7 are reserved and should be set to zero (some early Internet drafts on error handling for optional-transitive attributes proposed the use of bit 4, but this proposal was largely superseded through widespread adoption of other error handling drafts discussed in Chapter 8).

Examples of optional non-transitive attributes include the MED, ORIGINATOR_ID, CLUSTER, MP_REACH, and MP_UNREACH attributes, while examples of optional transitive attributes include the AGGREGATOR and COMMUNITY attributes.

In order to withdraw a route from service once it has been advertised, the IP prefix previously advertised as NLRI in the UPDATE message can be advertised in the Withdrawn Routes field of an UPDATE message, or a replacement route with the same NLRI can be advertised. Equally, if the BGP session between two peers is closed, all routes advertised to each other are implicitly removed. If an UPDATE message carries only Withdrawn Routes and no NLRI, the mandatory attributes such as NEXT_HOP, ORIGIN, and AS_PATH need not be present.

NOTIFICATION Messages

A NOTIFICATION message is sent when an error condition is detected and causes the BGP session to close. The NOTIFICATION message contains fields for error codes, one or more error sub-codes associated with that error code, and a data field that provides some indication of the error condition. Error codes and sub-codes are contained in section 4.5 of RFC 4271, updated by RFC 4486 (Subcodes for BGP Cease NOTIFICATION Message).

Error conditions that require a NOTIFICATION message to be sent are categorized into three types:

Those experienced during processing of the generic BGP message header

Those experienced in processing of the OPEN message

Those experienced in processing of UPDATE messages

When the BGP session is closed, the associated TCP connection is closed, the RIB-IN entries with the peer are cleared, and all resources allocated to that particular peer are released. Errors in the BGP message header are uncommon and indicate a fairly fundamental problem. Errors in the OPEN message are typically due to misconfiguration of peer parameters. However, errors in UPDATE messages are not uncommon, and have the potential to be extremely disruptive.

The original BGP specification called for a NOTIFICATION message to be generated under a number of conditions during error checking of attributes within UPDATE messages. More recent work (draft-ietf-grow-ops-reqs-for-bgp-error-handling) has called for alternative measures to be implemented under these circumstances in order to avoid this level of disruption. This point is discussed further in Chapter 8.

Multi-Protocol BGP

The Multi-Protocol extensions to BGP defined in RFC 4760 provide the capability for BGP to carry routing information for multiple network layer protocols such as IPv6, VPN-IPv4, VPN-IPv6, L2VPN, and Multicast-VPN, to name but a few. To identify individual network layer protocols and be able to associate them with Next-Hop information and the semantics of the NLRI, the extensions to Multi-Protocol BGP specified the use of the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).

AFI and SAFI assignments are administered by IANA at www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml and www.iana.org/assignments/safi-namespace/safi-namespace.xhtml. By way of example, a VPN-IPv4 prefix is represented as AFI 1 (IPv4), SAFI 128 (MPLS-labeled VPN address).

Two optional transitive attributes were introduced to support Multi-Protocol extensions to BGP: Multi-Protocol Reachable NLRI and Multi-Protocol Unreachable NLRI. The Multi-Protocol Reachable NLRI (MP_REACH_NLRI) is used to carry the set of reachable destination prefixes together with the Next-Hop information to be used for forwarding to those destination prefixes. Each MP_REACH_NLRI UPDATE message contains a single Next-Hop address and a list of NLRIs associated with that Next-Hop address.

At a minimum, an UPDATE message that carries the MP_REACH_NLRI must also carry the Next-Hop, Origin, and AS_PATH attributes in both EBGP and IBGP, and the LOCAL-PREF attribute in IBGP.

In contrast, Multi-Protocol Unreachable NLRI (MP_UNREACH_NLRI) is used to withdraw one or more unfeasible routes and has much the same format as the MP_REACH_NLRI attribute without the requirement to signal Next-Hop information.

Figure 1-4 MP_REACH_NLRI Encoding

Figure 1-5 MP_UNREACH_NLRI Encoding

Unlike the MP_REACH_NLRI, an UPDATE message containing the MP_UNREACH_NLRI attribute is not required to carry any other path attributes.

The capability to support Multi-Protocol BGP is negotiated in the OPEN exchange on an Address Family basis. By default, SR-OS signals the Multi-Protocol BGP capability for AFI/SAFI unicast IPv4 only. If other Address Families are added or removed at BGP/group/neighbor level, the OPEN exchange is renegotiated. To illustrate the encoding of the Multi-Protocol BGP MP_REACH_NLRI, Debug 1-5 shows an UPDATE message for IPv6 prefix 2a00:8010:1b00::/48. Note the Address Family, Next-Hop information, and prefix are all contained within the single MP_REACH_NLRI attribute.

The introduction of Multi-Protocol BGP was significant. BGP was already considered a very flexible protocol and relatively lightweight to support, and with the introduction of Multi-Protocol BGP AFI/SAFI and different NLRI it had become extensible to support any other network layer as you'll see in the following chapters.

UPDATE or MP_REACH, and Withdraw or MP_UNREACH are referred to interchangeably throughout this book.

Chapter 2

BGP/MPLS IP-VPN

The framework for building BGP/Multi-Protocol Label Switching (BGP/MPLS) based IP Virtual Private Networks (IP-VPNs) relies on Multi-Protocol BGP (RFC 4760) and the optional-transitive BGP Extended Communities (RFC 4360) attribute “Route Target.”

Multi-Protocol BGP is used for advertising of VPN-IPv4/VPN-IPv6 prefixes, and, because both are labeled prefixes, they follow the encoding of labeled BGP (RFC 3107), where the prefix is constructed of an 8-byte Route-Distinguisher followed by a 4-byte IPv4 prefix or 16-byte IPv6 prefix. The purpose of the RD is to allow the concatenation of RD and IPv4/IPv6 prefixes to create a unique VPN-IPv4/VPN-IPv6 prefix.

For VPN-IPv4 the AFI is 1 (IPv4), and for VPN-IPv6 the AFI is 2 (IPv6). Both VPN-IPv4 and VPN-IPv6 use a SAFI of 128 (MPLS-labeled VPN address).

Figure 2-1 VPN-IPv4/IPv6 NLRI Encoding

When a route is redistributed into VPN-IPv4, a Route Target Extended Community is appended to the prefix. The Route Target Extended Community is a transitive attribute (RFC 4360) used to define the set of sites belonging to a given VPN. When a VPN-IPv4 prefix is received at a Provider Edge (PE) router, it parses the Route Target value and checks whether any locally configured VRFs have an import policy that matches that value. If it does, the route is imported into that VPRN. If it doesn't, the route is not imported into any VPRNs. In short, associating a particular Route Target attribute with a prefix allows that route to be placed into VRFs serving that VPN. If ten sites in a VPN all have a common export and import Route Target value, the result is an “any-to-any” VPN.