1

Ver: 1

642- 691: Quick ReferenceBy Gaurav Vasudeva

CCNP, CCIP

Contact: 2gauravvasudeva@gmail.com

Chicago, USA

Path attributes are sent in an UPDATE message, and fall into one of four classes:

Well-known mandatory: Must be recognized by all BGP routers, present in all BGP updates,

and passed on to other BGP routers. For example, AS path, origin, and next hop.

Well-known discretionary: Must be recognized by all BGP routers and passed on to other BGP

routers but need not be present in an update, for example, local preference.

Optional transitive: Might or might not be recognized by a BGP router but is passed on to other

BGP routers. If not recognized, it is marked as partial, for example, aggregator, community.

Optional nontransitive: Might or might not be recognized by a BGP router and is not passed on

to other routers, for example, Multi-Exit Discriminator (MED), originator ID.

-Mandatory attribute must be present in an update, a discretionary doesn’t have to.

Various Attributes:-

Weight is a Cisco-defined attribute that is local to a router. The weight attribute is not advertised to neighboring routers.

The local preference attribute is used to prefer an exit point from the local autonomous system (AS). Unlike the weight attribute, the local preference attribute is propagated throughout the local AS.

The multi-exit discriminator (MED) or metric attribute is used as a suggestion to an external AS regarding the preferred route into the AS that is advertising the metric.

The origin attribute indicates how BGP learned about a particular route. The origin attribute can have one of three possible values:

When a route advertisement passes through an autonomous system, the AS number is added to an ordered list of AS numbers that the route advertisement has traversed

The EBGP next-hop attribute is the IP address that is used to reach the advertising router. For EBGP peers, the next-hop address is the IP address of the connection between the peers. For IBGP, the EBGP next-hop address is carried into the local AS

BGP Path Selection

BGP could possibly receive multiple advertisements for the same route from multiple sources. BGP selects only one path as the best path. When the path is selected, BGP puts the selected path in the IP routing table and propagates the path to its neighbors. BGP uses the following criteria, in the order presented, to select a path for a destination:

• If the path specifies a next hop that is inaccessible, drop the update.

• Prefer the path with the largest weight.

• If the weights are the same, prefer the path with the largest local preference.

• If the local preferences are the same, prefer the path that was originated by BGP running on this router.

• If no route was originated, prefer the route that has the shortest AS_path.

• If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is lower than EGP and EGP is lower than incomplete).

• If the origin codes are the same, prefer the path with the lowest MED attribute.

• If the paths have the same MED, prefer the external path over the internal path.

• If the paths are still the same, prefer the path through the closest IGP neighbor.

• Prefer the path with the lowest IP address, as specified by the BGP router ID.

EBGP Multihop (Load Balancing)

RTA#int loopback 0ip address 150.10.1.1 255.255.255.0router bgp 100neighbor 160.10.1.1 remote-as 200neighbor 160.10.1.1 ebgp-multihopneighbor 160.10.1.1 update-source loopback 0network 150.10.0.0

ip route 160.10.0.0 255.255.0.0 1.1.1.2ip route 160.10.0.0 255.255.0.0 2.2.2.2RTB#int loopback 0ip address 160.10.1.1 255.255.255.0router bgp 200neighbor 150.10.1.1 remote-as 100neighbor 150.10.1.1 update-source loopback 0neighbor 150.10.1.1 ebgp-multihopnetwork 160.10.0.0

ip route 150.10.0.0 255.255.0.0 1.1.1.1ip route 150.10.0.0 255.255.0.0 2.2.2.1

Match and set Configuration Commands

Each route map consists of a list of match and set configuration commands. The match specifies a match criteria, and set specifies a set action if the criteria that the match command enforces are met.

The "AS1 i" means that the next AS path is 1 and the origin of the route is IGP

Disable Synchronization

In some cases, you do not need synchronization. If you do not pass traffic from a different AS through your AS, you can disable synchronization. You can also disable synchronization if all routers in your AS run BGP. The disablement of this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly.

The disablement of synchronization is not automatic. If all your routers in the AS run BGP and you do not run IGP at all, the router has no way to know. Your router waits indefinitely for an IGP update about a certain route before the router sends the route to external peers. You have to disable synchronization manually in this case so that routing can work correctly:

router bgp 100no synchronization

Note:There are two BGP configuration commands that can influence the multi-exit discriminator (MED)-based path selection. The commands are the bgp deterministic-med command and the bgp always-compare-med command. An issue of the bgp deterministic-med command ensures the comparison of the MED variable at route choice when different peers advertise in the same AS. An issue of the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different ASs. The bgp always-compare-med command is useful when multiple service providers or enterprises agree on a uniform policy for how to set MED.

Community Attribute

The community attribute is a transitive, optional attribute in the range of 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions according to those communities. The routing decisions are accept, prefer, and redistribute, among others.

You can use route maps to set the community attributes. The route map set command has this syntax:

set community community-number [additive] [well-known-community]

A few predefined, well known communities for use in this command are:

no-export—Do not advertise to eBGP peers. Keep this route within an AS. no-advertise—Do not advertise this route to any peer, internal or external. internet—Advertise this route to the Internet community. Any router belongs to this community. local-as—Use in confederation scenarios to prevent the transmit of packets outside the local AS.

Here are two examples of route maps that set the community:

route-map communitymapmatch ip address 1

set community no-advertise

or

route-map setcommunitymatch as-path 1set community 200 additive

If you do not set the additive keyword, 200 replaces any old community that already exits. If you use the keyword additive, an addition of 200 to the community occurs. Even if you set the community attribute, this attribute does not transmit to neighbors by default. In order to send the attribute to a neighbor, you must use this command:

neighbor {ip-address | peer-group-name} send-community

Here is an example:

RTA#router bgp 100neighbor 3.3.3.3 remote-as 300neighbor 3.3.3.3 send-communityneighbor 3.3.3.3 route-map setcommunity out

BGP Filtering

-Route Filtering

neighbor {ip-address | peer-group-name} distribute-list access-list-number {in | out}

RTC#router bgp 300network 170.10.0.0neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 distribute-list 1 out

access-list 1 deny 160.10.0.0 0.0.255.255

access-list 1 permit 0.0.0.0 255.255.255.255

!--- Filter out all routing updates about 160.10.x.x.

-Path Filtering

Another type of filtering is path filtering.

You can specify an access list on both incoming and outgoing updates with use of the BGP AS paths information. In the diagram in this section, you can block updates about 160.10.0.0 so that they do not go to AS100. To block the updates, define an access list on RTC that prevents the transmit to AS100 of any updates that have originated from AS200. Issue these commands:

ip as-path access-list access-list-number {permit | deny} as-regular-expression

neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}

This example stops the RTC send of updates about 160.10.0.0 to RTA:

RTC#router bgp 300neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 filter-list 1 out

!--- The 1 is the access list number below.

ip as-path access-list 1 deny ^200$ip as-path access-list 1 permit .*

A regular expression comprises:

Range

A range is a sequence of characters within left and right square brackets. An example is [abcd].

Atom

An atom is a single character. Here are some examples:

.

o The . matches any single character.

^

o The ^ matches the start of the input string.

$

o The $ matches the end of the input string.

\

o The \ matches the character.

-

o The _ matches a comma (,), left brace ({), right brace (}), the start of the input string, the end of the input string, or a space.

Piece

A piece is one of these symbols, which follows an atom:

*

o The * matches 0 or more sequences of the atom.

+

o The + matches 1 or more sequences of the atom.

?

o The ? matches the atom or the null string.

-BGP Community Filtering

In this example, you want RTB to set the community attribute to the BGP routes that RTB advertises such that RTC does not propagate these routes to the external peers. Use the no-export community attribute.

RTB#router bgp 200network 160.10.0.0

neighbor 3.3.3.1 remote-as 300neighbor 3.3.3.1 send-communityneighbor 3.3.3.1 route-map setcommunity out

route-map setcommunitymatch ip address 1set community no-export

access-list 1 permit 0.0.0.0 255.255.255.255

Note: This example uses the route-map setcommunity command in order to set the community to no-export.

Note: The neighbor send-community command is necessary in order to send this attribute to RTC.

When RTC gets the updates with the attribute NO_EXPORT, RTC does not propagate the updates to external peer RTA.

In this example, RTB has set the community attribute to 100 200 additive. This action adds the value 100 200 to any existing community value before transmission to RTC.

RTB#router bgp 200network 160.10.0.0neighbor 3.3.3.1 remote-as 300neighbor 3.3.3.1 send-communityneighbor 3.3.3.1 route-map setcommunity out

route-map setcommunitymatch ip address 2set community 100 200 additive

access-list 2 permit 0.0.0.0 255.255.255.255

A community list is a group of communities that you use in a match clause of a route map. The community list allows you to filter or set attributes with different lists of community numbers as a basis.

ip community-list community-list-number {permit | deny} community-number

For example, you can define this route map, match-on-community:

route-map match-on-communitymatch community 10

!--- The community list number is 10.

set weight 20ip community-list 10 permit 200 300

!--- The community number is 200 300.

You can use the community list in order to filter or set certain parameters, like weight and metric, in certain updates with the community value as a basis. In the second example in this section, RTB sent

updates to RTC with a community of 100 200. If RTC wants to set the weight with those values as a basis, you can do this:

RTC#router bgp 300neighbor 3.3.3.3 remote-as 200neighbor 3.3.3.3 route-map check-community in

route-map check-community permit 10match community 1set weight 20

route-map check-community permit 20match community 2 exactset weight 10

route-map check-community permit 30match community 3

ip community-list 1 permit 100ip community-list 2 permit 200ip community-list 3 permit internet

In this example, any route that has 100 in the community attribute matches list 1. The weight of this route is set to 20. Any route that has only 200 as community matches list 2 and has a weight of 20. The keyword exact states that the community consists of 200 only and nothing else. The last community list is here to make sure that other updates do not drop. Remember that anything that does not match drops, by default. The keyword internet indicates all routes because all routes are members of the Internet community.

BGP Neighbors and Route Maps

You can use the neighbor command in conjunction with route maps to either filter or set parameters on incoming and outgoing updates.

Route maps associated with the neighbor statement have no effect on incoming updates when you match based on the IP address:

neighbor ip-address route-map route-map-name

Assume that, in the diagram in this section, you want RTC to learn from AS200 about networks that are local to AS200 and nothing else. Also, you want to set the weight on the accepted routes to 20. Use a combination of neighbor and as-path access lists:

RTC#router bgp 300network 170.10.0.0neighbor 3.3.3.3 remote-as 200neighbor 3.3.3.3 route-map stamp in

route-map stampmatch as-path 1set weight 20

ip as-path access-list 1 permit ^200$

Any updates that originate from AS200 have path information that starts with 200 and ends with 200. These updates are permitted. Any other updates drop.

Assume that you want:

An acceptance of updates that originate from AS200 and have a weight of 20 The drop of updates that originate from AS400 A weight of 10 for other updates

RTC#router bgp 300network 170.10.0.0neighbor 3.3.3.3 remote-as 200neighbor 3.3.3.3 route-map stamp in

route-map stamp permit 10match as-path 1set weight 20

route-map stamp permit 20match as-path 2set weight 10

ip as-path access-list 1 permit ^200$ ip as-path access-list 2 permit ^200 600 .*

This statement sets a weight of 20 for updates that are local to AS200. The statement also sets a weight of 10 for updates that are behind AS400, and drops updates that come from AS400.

Use of set as-path prepend Command

In some situations, you must manipulate the path information in order to manipulate the BGP decision process. The command that you use with a route map is:

set as-path prepend as-path# as-path#

Suppose that, in the diagram in the section BGP Neighbors and Route Maps, RTC advertises its own network 170.10.0.0 to two different ASs, AS100 and AS200. When the information is propagated to AS600, the routers in AS600 have network reachability information about 150.10.0.0 via two different

routes. The first route is via AS100 with path (100, 300), and the second one is via AS400 with path (400, 200, 300). If all other attributes are the same, AS600 picks the shortest path and chooses the route via AS100.

AS300 gets all traffic via AS100. If you want to influence this decision from the AS300 end, you can make the path through AS100 appear to be longer than the path that goes through AS400. You can do this if you prepend AS numbers to the existing path information that is advertised to AS100. A common practice is to repeat your own AS number in this way:

RTC#router bgp 300network 170.10.0.0neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 route-map SETPATH out

route-map SETPATHset as-path prepend 300 300

Because of this configuration, AS600 receives updates about 170.10.0.0 via AS100 with path information of: (100, 300, 300, 300). This path information is longer than the (400, 200, 300) that AS600 received from AS400.

A BGP peer group is a group of BGP neighbors with the same update policies. Route maps, distribute lists, and filter lists typically set update policies. You do not define the same policies for each separate neighbor; instead, you define a peer group name and assign these policies to the peer group.

Aggregate Commands

There is a wide range of aggregate commands. You must understand how each one works in order to have the aggregation behavior that you desire.

The first command is the one from the example in the section CIDR and Aggregate Addresses:

aggregate-address address-mask

This command advertises the prefix route and all the more-specific routes. The command aggregate-address 160.0.0.0 propagates an additional network 160.0.0.0 but does not prevent the propagation of 160.10.0.0 to RTA. The outcome is the propagation of both networks 160.0.0.0 and 160.10.0.0 to RTA, which is the advertisement of both the prefix and the more-specific route.

Note: You cannot aggregate an address if you do not have a more-specific route of that address in the BGP routing table.

An injection of the more-specific route into the BGP table is possible. The route injection can occur via:

Incoming updates from other ASs Redistribution of an IGP or static into BGP The network command, for example, network 160.10.0.0

If you want to suppress more-specific routes when you do the aggregation, define a route map and apply the route map to the aggregates. The action allows you to be selective about which more-specific routes to suppress.

aggregate-address address-mask suppress-map map-name This command advertises the prefix and the more-specific routes. But the command suppresses

advertisement with a route map basis. Suppose that, with the diagram in the section CIDR and Aggregate Addresses, you want to aggregate 160.0.0.0, suppress the more-specific route 160.20.0.0, and allow the propagation of 160.10.0.0. Use this route map:

route-map CHECK permit 10match ip address 1

access-list 1 permit 160.20.0.0 0.0.255.255access-list 1 deny 0.0.0.0 255.255.255.255

Then, apply the route map to the aggregate statement.

RTC#router bgp 300neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 remote-as 100network 170.10.0.0aggregate-address 160.0.0.0 255.0.0.0 suppress-map CHECK

Here is another variation: aggregate-address address-mask attribute-map map-name

Network Diagram

RTC# router bgp 300 neighbor 2.2.2.2 remote-as 100 neighbor 3.3.3.3 remote-as 200 neighbor 4.4.4.4 remote-as 400 aggregate-address 160.0.0.0 255.0.0.0 summary-only

RTD will only see aggregate address as as show below:

RouterD# show ip bgpBGP table version is 6, local router ID is 4.4.4.4Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 160.0.0.0/8 4.4.4.1 0 300 i

The route has lost all the specific AS_PATH information of the individual prefixes 160.10.0.0/16, of AS-200, and 160.20.0.0/16, of AS-100.

To preserve, AS info use “as-set” in aggregate-address command in RTC.i.e. aggregate-address 160.0.0.0 255.0.0.0 summary-only as-set

Now, look at the same show command on RTD.

RouterD# show ip bgpBGP table version is 2, local router ID is 4.4.4.4Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 160.0.0.0/8 4.4.4.1 0 300 {200,100} i

BGP Confederation

The implementation of BGP confederation reduces the iBGP mesh inside an AS. The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Each AS alone has iBGP fully meshed and has connections to other ASs inside the confederation. Even though these ASs have eBGP peers to ASs within the confederation, the ASs exchange routing as if they used iBGP. In this way, the confederation preserves next hop, metric, and local preference information. To the outside world, the confederation appears to be a single AS.

In order to configure a BGP confederation, issue this command:

bgp confederation identifier autonomous-system

The confederation identifier is the AS number of the confederation group.

The issue of this command performs peering between multiple ASs within the confederation:

bgp confederation peers autonomous-system [autonomous-system]

Route Reflectors

Another solution for the explosion of iBGP peering within an AS is Route Reflectors (RRs). As the iBGPsection demonstrates, a BGP speaker does not advertise a route that the BGP speaker learned via another iBGP speaker to a third iBGP speaker. You can relax this restriction a bit and provide additional control, which allows a router to advertise, or reflect, iBGP learned routes to other iBGP speakers. This route reflection reduces the number of iBGP peers within an AS.

When an RR receives a route, the RR routes as this list shows. However, this activity depends on the peer type:

1. Routes from a nonclient peer—Reflects to all the clients within the cluster.2. Routes from a client peer—Reflects to all the nonclient peers and also to the client peers.3. Routes from an eBGP peer—Sends the update to all client and nonclient peers.

Because there is a reflection of the iBGP learned routes, there can be a routing information loop. The RR scheme has a few methods to avoid this loop:

originator-id—This is an optional, nontransitive BGP attribute that is 4 bytes long. An RR creates this attribute. The attribute carries the router ID (RID) of the originator of the route in the local AS. If, due to poor configuration, the routing information comes back to the originator, the information is ignored.

cluster-list

A cluster list is a sequence of cluster IDs that the route has passed. When an RR reflects a route from the RR clients to nonclients outside of the cluster, the RR appends the local cluster ID to the cluster list. If this update has an empty cluster list, the RR creates one. With this attribute, an RR can identify if the routing information has looped back to the same cluster due to poor configuration. If the local cluster ID is found in the cluster list, the advertisement is ignored.

Route Flap Dampening

Cisco IOS Software Release 11.0 introduced route dampening. Route dampening is a mechanism to minimize the instability that route flapping causes. Route dampening also reduces oscillation over the network. You define criteria to identify poorly behaved routes. A route that flaps gets a penalty of 1000 for each flap. As soon as the cumulative penalty reaches a predefined "suppress limit", suppression of the route advertisement occurs. The penalty decays exponentially based on a preconfigured "half-life time". Once the penalty decreases below a predefined "reuse limit", unsuppression of the route advertisement occurs.

Route dampening does not apply to routes that are external to an AS and learned via iBGP. In this way, route dampening avoids a higher penalty for the iBGP peers for routes external to the AS.

The penalty decays at a granularity of 5 seconds. Unsuppression of the routes is at a granularity of 10 seconds. The router keeps the dampening information until the penalty becomes less than half of the "reuse limit". At that point, the router purges the information.

This list details the syntax:

half-life-time —The range is 1–45 minutes, and the current default is 15 minutes. reuse-value —The range is 1–20,000, and the default is 750. suppress-value —The range is 1–20,000, and the default is 2000. max-suppress-time —This is the maximum duration for the suppression of a route. The range is

1–255 minutes, and the default is 4 times the half-life time

-In an AS , to ensure full mesh among ‘n’ routers, we need n(n-1)/2 links.

i.e. with 10 routers in an AS, we need 10*9/2=45 links for full mesh.

BGP-ORF

The goal of ORF is the ability of the neighbors to tell each other what prefixes they want BEFORE they are sent. This saves bandwidth and processing.

The BGP prefix-based outbound route filtering can be configured with send or receive ORF capabilities. The local peer advertises the ORF capability in send mode. The remote peer receives the ORF capability in receive mode and applies the filter as an outbound policy. The local and remote peers exchange updates to maintain the ORF on each router. Updates are exchanged between peer routers by address family depending on the ORF prefix list capability that is advertised. The remote peer starts sending updates to the local peer after a route refresh has been requested with the clear ip bgp in prefix-filter command or after an ORF prefix list with immediate status is processed. The BGP peer will continue to apply the inbound prefix list to received updates after the local peer pushes the inbound prefix list to the remote peer.

The following example configures Router-A to advertise prefix-based ORF send capabilities to Router-B (172.16.1.2):

router bgp 100address-family ipv4 unicastneighbor 172.16.1.2 remote-as 200neighbor 172.16.1.2 capability orf prefix-list sendexit

The following example configures Router-B to advertise prefix-based ORF receive capabilities to Router-A (10.1.1.1). This example also creates the prefix filter to permit route from the 192.168.1.0 network.

router bgp 200address-family ipv4 unicastneighbor 10.1.1.1 remote-as 100neighbor 10.1.1.1 capability orf prefix-filter receiveneighbor 10.1.1.1 distribute-list 10 inexitaccess-list 10 permit 192.168.1.0 0.0.0.255

MPLS FRAME FORMAT

Once the routing table is populated, CEF (Cisco Express Forwarding) uses thatinformation to enable MPLS label switching. Simply put, CEF is required to be able tolabel switch in an MPLS network. CEF has two components, the Forwarding InformationBase (FIB) and the adjacency table.

The FIB (located in the data plane) is responsible for maintaining next hop IP addressesfor all the routes in the routing table. The adjacency table is responsible for maintainingthe layer 2 information for each FIB entry.

Mainly 2 kinds of label distribution protocol

1.) LDP

2.) TDP

LDP Hello messages are UDP messages that are sent on the links to the “all routers on this subnet”multicast IP address—in other words, to the 224.0.0.2 group IP multicast address. The UDP portused for LDP is 646.

Notice that LSRs that are running LDP have an LDP Identifier, or LDP ID. This LDP ID is a 6- byte field that consists of 4 bytes identifying the LSR uniquely and 2 bytes identifying the label space that the LSR is using. If the last two bytes are 0, the label space is the platform-wide or per platform label space. If they are non-zero, a per-interface label space is used. If that is the case, multiple LDP IDs are used, where the first 4 bytes are the same value, but the last two bytes indicate a different label space. Per-interface label space is used for LC-ATM links

The LFIB is the table used to forward labeled packets. It is populated with the incoming andoutgoing labels for the LSPs.

In Cisco IOS, all Label Switching Controlled-ATM (LC-ATM) interfaces have a per-interface label space, whereas all ATM frame-based and non-ATM interfaces have a per-platform label space.

An LSR can use different modes when distributing labels to other LSRs. This section covers three distinct modes, as follows:

■ Label distribution mode■ Label retention mode■ LSP control mode

Label distribution mode

The MPLS architecture has two modes to distribute label bindings:

■ Downstream-on-Demand (DoD) label distribution mode : Labels are distributed as per request from each LSR.■ Unsolicited Downstream (UD) label distribution mode : labels are distributed freely hence each LSR has more than one remote bindings.

Label Retention Modes

Two label retention modes are possible:■ Liberal Label Retention (LLR) mode : Stores all labels of adjacent as well as remote routers.■ Conservative Label Retention (CLR) mode : Only stores labels bindings associated to next-hop LSR.

LSP Control Modes

LSRs can create a local binding for a FEC in two ways:■ Independent LSP Control mode: In this control mode, each LSR creates a local binding for aparticular FEC as soon as it recognizes the FEC. Usually, this means that the prefix for the FEC isin its routing table.■ Ordered LSP Control mode: In Ordered LSP Control mode, an LSR only creates a local binding for a FEC if it recognizes that it is the egress LSR for the FEC or if the LSR has received a label binding from the next hop for this FEC.

You can see an extract from the LFIB, by issuing the command show mpls forwarding-table.

label operations:■ Pop—The top label is removed. The packet is forwarded with the remaining label stack or asan unlabeled packet.■ Swap—The top label is removed and replaced with a new label.■ Push—The top label is replaced with a new label (swapped), and one or more labels are added(pushed) on top of the swapped label.■ Untagged/No Label—The stack is removed, and the packet is forwarded unlabeled.■ Aggregate—The label stack is removed, and an IP lookup is done on the IP packet.

NOTE PHP is the default mode in Cisco IOS. In the case of IPv4-over-MPLS, Cisco IOS onlyadvertises the implicit NULL label for directly connected routes and summarized routes

Labels 0 through 15 are reserved labels. An LSR cannot use them in the normal case forforwarding packets. An LSR assigns a specific function to each of these labels.

Label 0 is the explicit NULL label, whereas label 3 is the implicit NULL label. Label 1 is the router alert label,whereas label 14 is the OAM alert label. The other reserved labels between 0 and 15 have not been assigned yet.

Although the label value 3 signals the use of the implicit NULL label, the label 3 will never be seen as a label in the label stack of an MPLS packet. That is why it is called the implicit NULL label.

the router can derive the QoS information of the received packet by looking at the EXP bits of the explicit NULL label.

Controlling LDP Advertisement:Configure the mpls ldp advertiselabels for prefix-access-list to peer-access-list command.

Do not forget to configure no mpls ldp advertise-labels, too

Following is the command to enable the inbound label binding filtering:

mpls ldp neighbor [vrf vpn-name] nbr-address labels accept acl

On the ATM LSR, you can change the VPI/VCI range that MPLS uses for the LVCs per ATMinterface. The default VPI used for MPLS is 1. The Cisco IOS interface command to change theVPI/VCI range is as follows:mpls atm vpi vpi [- vpi] [vci-range low - high]

To avoid unnecessary label advertisement for prefixes in the routing table, the ATM LSR does notoperate in Unsolicited Downstream (UD) label advertisement mode. Rather, it operates inDownstream-on-Demand (DoD) label advertisement mode.

A loop is detected when a configured maximumhop count value is reached. Following is the command to enable loop detection by means of theHop Count TLV in Cisco IOS:mpls ldp maxhops numberThe default value for the maximum hop count argument (number) is 254.

The procedure of buffering the cells and only using one outgoing label per prefix for all upstream ATM LSRs is called VCMerge. Different incoming LVCs are merged into one outgoing LVC.

VC-Merge is on by default on Cisco ATM Switches.

Packets can be forwarded through the router in three basic ways: process switching, interruptswitching, or through an application-specific integrated circuit (ASIC).

ASIC Fast switching :The command to enable fast switching on the interface is ip route-cache CEF : the switching table is no longer built on demand, but it is built in advance.

CEF Table or FIB : #show ip cef

VRFA virtual routing/forwarding (VRF) is a VPN routing and forwarding instance. It is the name forthe combination of the VPN routing table, the VRF Cisco Express Forwarding (CEF) table, andthe associated IP routing protocols on the PE router.

You create the VRF on the PE router with the ip vrf command.

Configuring a VRF:ip vrf cust-onerd 1:1route-target export 1:1route-target import 1:1!interface Serial5/1ip vrf forwarding cust-oneip address 10.10.4.1 255.255.255.0

RD

You can enter an RD in either of these formats:

Enter a 16-bit autonomous system number, a colon, and a 32-bit number. For example: 45000:3 Enter a 32-bit IP address, a colon, and a 16-bit number. For example: 192.168.10.15:1

If the customers had overlapping IP addressing, the routing wouldbe wrong. To solve this problem, the concept of RDs was conceived to make IPv4 prefixes unique.The basic idea is that each prefix from each customer receives a unique identifier (the RD) todistinguish the same prefix from different customers.

RT

An RT is a BGP extended community that indicates which routes should be imported from MPBGPinto the VRF.

RTs control which routes are imported into which VRFs from the remotePE routers and with which RTs the vpnv4 routes are exported toward the remote PE routers.

Configuring RTssydney#conf tEnter configuration commands, one per line. End with CNTL/Z.sydney(config)#ip vrf cust-onesydney(config-vrf)#route-target ?ASN:nn or IP-address:nn Target VPN Extended Communityboth Both import and export Target-VPN communityexport Export Target-VPN communityimport Import Target-VPN communitysydney(config-vrf)#route-target both 1:1

PE-CE Routing ProtocolsRouting needs to occur between the PE and CE routers. The PE-CE routing protocols that CiscoIOS supports are static routing, RIPv2, Open Shortest Path First (OSPF), Enhanced InteriorGateway Routing Protocol (EIGRP), Intermediate System-to-Intermediate System (IS-IS), andeBGP.

The sham link is not a real link buta fake one between two PE routers. It is an OSPF intra-area link created between the two PE routers so that they can flood this link in the area connected to both the PE routers.

The syntax of the sham link command is area area-id sham-link source-addressdestination-address cost number.

The down bit is a bit that is set in the Options field of an OSPF LSA type 3. It indicates thedirection that the route has been advertised. If the OSPF route has been advertised from a PE routerinto an OSPF area, the down bit is set.

The domain tag (also known as the VPN route tag) serves the same purpose as the down bit, butfor OSPF external routes. You can set it manually on the PE routers with the command domaintagtag-value.

Autonomous System OverrideIf the customer has the same ASN at different sites, the CE routers drop the BGP routes.

The command that you need to configure on the PE router to override the ASN is neighbor ipaddressas-override.

The safeguard against possible routing loops and suboptimal routing thatcomes from the as-path verification is now gone. Therefore, when using the as-overridefunctionality, it is advisable to deploy the SOO feature for BGP.router bgp 100neighbor 192.168.255.255 remote-as 100neighbor 192.168.255.255 update-source loopback0address-family ipv4 vrf vpn1neighbor 192.168.255.255 activateneighbor 192.168.255.255 as-override

Allowas-inInstead of overriding autonomous system numbers in the as-path, you can instruct the PE router to loosen the check of the as-path.

You can configure the command neighbor allowas-in number on thePE router that connects to the VRF hub site. The allowas-in command permits multipleoccurrences of the same ASN (in this case the ASN of the service provider) in the as-path as theASN of the BGP speaker without BGP denying the route. The number you can configure is from1 to 10, specifying the number of times that the ASN is allowed in the as-path.

R3(config)#router bgp 1R3(config-router)#neighbor 192.168.1.5 allowas-in

NOTE Current Cisco IOS does not support internal BGP as the PE-CE routing protocol. Itsupports only external BGP.

SOOSOO uniquely identifies the site that originates a route. It is a BGP extended community thatprevents routing loops or suboptimal routing, specifically when a backdoor is present betweenVPN sites. SOO provides loop prevention in networks with dual-homed sites (sites that areconnected to two or more PE routers).

There are three ways to configure an SoO value for a BGP neighbor:

• BGP peer policy template—A peer policy template is created, and an SoO value is configured as part of the peer policy. Under address family IPv4 VRF, a neighbor is identified and is configured to inherit the peer policy that contains the SoO value.

• BGP neighbor command—Under address family IPv4 VRF, a neighbor is identified, and an SoO value is configured for the neighbor.

• BGP peer group—Under address family IPv4 VRF, a BGP peer group is configured, an SoO value is configured for the peer group, a neighbor is identified, and the neighbor is configured as a member of the peer group.

INTERNET VPN:Internet Access Through the Global Routing Table with Static Routeslondon#!interface Ethernet0/1/2ip vrf forwarding cust-oneip address 10.10.2.2 255.255.255.0

!router bgp 1bgp log-neighbor-changesredistribute staticneighbor 10.200.254.3 remote-as 1no auto-summary!ip route vrf cust-one 0.0.0.0 0.0.0.0 10.200.254.5 globalip route 192.168.1.0 255.255.255.0 Ethernet0/1/2 10.10.2.1

The Multi-VRF CE featurealso known as VRF-Lite—is a feature whereby the VPN functionality is extended to the CE router in a cheap way.

Sources: cisco.com/univercd.

MPLS Fundamentals. By Ghein

Various RFCs Blogs