Versatile Routing and Services with BGP: Understanding and Implementing BGP in SR-OS

By Alcatel-Lucent and Colin Bookham

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.

• Language: English
• Publisher: Wiley
• Release date: Jan 29, 2014
• ISBN: 9781118875629

Book preview

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).

Debug 1-1: OPEN message with Capabilities Negotiation

135 2013/04/18 14:47:00.98 BST MINOR: DEBUG #2001 Base BGP

"BGP: OPEN

Peer 1: 192.168.0.2 - Send (Active) BGP OPEN: Version 4

  AS Num 64496: Holdtime 90: BGP_ID 192.0.2.46: Opt Length 16

  Opt Para: Type CAPABILITY: Length = 14: Data:

    Cap_Code MP-BGP: Length 4

      Bytes: 0x0 0x1 0x0 0x1

    Cap_Code ROUTE-REFRESH: Length 0

    Cap_Code 4-OCTET-ASN: Length 4

      Bytes: 0x0 0x0 0x11 0xed

"

137 2013/04/18 14:47:00.97 BST MINOR: DEBUG #2001 Base BGP

"BGP: OPEN

Peer 1: 192.168.0.2 - Received BGP OPEN: Version 4

  AS Num 64510: Holdtime 30: BGP_ID 192.168.0.2: Opt Length 16

  Opt Para: Type CAPABILITY: Length = 14: Data:

    Cap_Code MP-BGP: Length 4

      Bytes: 0x0 0x1 0x0 0x1

    Cap_Code MP-BGP: Length 4

      Bytes: 0x0 0x2 0x0 0x1

    Cap_Code ROUTE-REFRESH: Length 0

"

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 that are being withdrawn from service. The Network Layer Reachability Information (NLRI) field contains a list of IP prefixes, again in the form , 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.

Output 1-3: UPDATE Message with NLRI

1 2013/06/09 09:07:10.11 BST MINOR: DEBUG #2001 Base Peer 1: 192.168.0.2

"Peer 1: 192.168.0.2: UPDATE

Peer 1: 192.168.0.2 - Received BGP UPDATE:

    Withdrawn Length = 0

    Total Path Attr Length = 18

    Flag: 0x40 Type: 1 Len: 1 Origin: 0

    Flag: 0x40 Type: 3 Len: 4 Nexthop: 192.168.0.2

    Flag: 0x40 Type: 2 Len: 4 AS Path:

        Type: 2 Len: 1 < 64510 >

    NLRI: Length = 4

        172.16.0.0/20

"

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).

Debug 1-3: UPDATE Message with Withdrawn Routes

3 2013/06/09 09:09:06.50 BST MINOR: DEBUG #2001 Base Peer 1: 192.168.0.2

"Peer 1: 192.168.0.2: UPDATE

Peer 1: 192.168.0.2 - Received BGP UPDATE:

    Withdrawn Length = 4

        172.16.0.0/20

    Total Path Attr Length = 0"

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.

Debug 1-4: NOTIFICATION Message

11 2013/06/09 09:14:03.48 BST MINOR: DEBUG #2001 Base Peer 1: 192.168.0.2

"Peer 1: 192.168.0.2: NOTIFICATION

Peer 1: 192.168.0.2 - Received BGP NOTIFICATION: Code = 6 (CEASE) Subcode

= 4 (Administrative Reset)

  Data Length = 16  Data: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

0x0 0x0 0x0 0x0"

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.

Debug 1-5 UPDATE with MP_REACH_NLRI attribute

1 2013/05/02 13:54:46.39 BST MINOR: DEBUG #2001 Base Peer 1: 192.168.0.2

"Peer 1: 192.168.0.2: UPDATE

Peer 1: 192.168.0.2 - Received BGP UPDATE:

    Withdrawn Length = 0

    Total Path Attr Length = 42

    Flag: 0x40 Type: 1 Len: 1 Origin: 0

    Flag: 0x40 Type: 2 Len: 4 AS Path:

        Type: 2 Len: 1 < 64510 >

    Flag: 0x80 Type: 14 Len: 28 Multiprotocol Reachable NLRI:

        Address Family IPV6

        NextHop len 16 Global NextHop 2001:db8:1C00::3

        2001:db8:1B00::/48"

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.

Basic Configuration

Output 2-1 shows the base level of configuration required in order to configure a VPRN. The route-distinguisher (RD) is a required parameter when configuring a VPRN, and the VPRN will not become operational until it is configured. When a VPRN is configured with a Route-Distinguisher but without any Route Target parameters, the VPRN does not rely on any BGP/MPLS IP-VPN control plane for learning prefixes but simply creates a separate routing context frequently referred to as VRF-lite. The route-distinguisher command is followed by a value that can take three formats but typically uses the type 0 format of a 2-byte ASN subfield followed by a 4-byte assigned number subfield (the remaining 2 bytes are used to define the actual type).

To participate in the BGP/MPLS IP-VPN control plane, the definition of Route Target values is required for import and export of VPN-IPv4 prefixes. The simplest method is using the vrf-target command followed by a Route Target value that has the same format as the Route Distinguisher. The vrf-target command allows for definition of a single value applicable to import and export Route Targets as shown in Output 2-1, or it allows for definition of different import and export Route Target values using the export and import keywords after the vrf-target command, followed by the relevant Route Target values. An alternative to the vrf-target approach for defining Route Target values is to use the vrf-import and vrf-export commands to reference policies constructed within the policy framework.

When prefixes are learned in VPN-IPv4, the receiving PE router must resolve the BGP Next-Hop to a GRE or MPLS tunnel before the prefix is considered valid. The auto-bind command tells the system to automatically bind the Next-Hop to an LSP in the LSP tunnel-table, and the keyword mpls means to use any form of LSP, with a preference for RSVP over LDP, and LDP over BGP.

Output 2-1: VPRN Base Configuration

    service

        vprn 4001

            autonomous-system 64496

            route-distinguisher 64496:4001

            auto-bind mpls

            vrf-target target:64496:4001

            no shutdown

One last optional parameter is the definition of an autonomous-system number in the VPRN. This parameter is required only if BGP is used as a PE-CE routing protocol. This parameter is used as the source ASN in the OPEN exchange unless the local-as parameter is also configured, in which case the ASN defined as the local-as is used in the OPEN exchange. (This also applies to the use of local-as in the global BGP context.)

At face value, both the VPRN autonomous-system ASN and local-as ASN appear to serve the same purpose of mimicking an ASN that differs from the global ASN defined in the router context. In fact, they can have different impacts on the AS_PATH of UPDATE messages propagated to connected CE routers depending on two things:

Their co-existence in configuration

Whether the no-prepend-global-as argument is specified as part of the local-as definition

If configured on their own (they do not co-exist) the VPRN-level ASN or local-as ASN is appended to the AS_PATH advertised to the CE and overrides the global ASN. If they are configured to co-exist, the behavior differs depending on the setting of the local-as no-prepend-global-as parameter. If the no-prepend-global-as parameter is disabled, the local-as AS number is appended to the AS_PATH along with the VPRN-level AS number if it differs from the VPRN-level ASN. If the no-prepend-global-as parameter is enabled, the local-as AS number overrides the VPRN-level AS number.

The local-as parameter can be considered useful if a VPRN context needs to appear to be more than one ASN to its peers. If not, the VPRN-level ASN is sufficient. To consolidate the various options, consider the