ROUTE REDISTRIBUTION

Overview

Redistribution is the process of taking routes from the routing table and injecting them into a routing protocol. The source of the injected routes could be any of: connected routes, static routes or routes from another routing protocol that are in the routing table (RIB). Sourcing routes from the RIB implies that;

1. the best routes are redistributed.
2. Loop-free routes are redistributed.

The routing device performing the redistribution participates in the routing domain of the source and destination of the redistributed routes; for instance, if redistributing routes from OSPF into BGP, the redistributing device participates in the OSPF routing domain as well as the BGP routing domain.

Reasons for Redistribution

An enterprise may implement redistribution for one or more of the following reasons:

1. A company merger where the networks of both companies run different routing protocols.
2. Different organizational department networks are under different network administrative control perhaps based on geography.
3. An organization inter-connecting with partner networks
4. Hardware constraints such routing devices with low memory, CPU.
5. During conversion or migration from one routing protocol to another.
6. Mixed vendor environment.
7. Support for legacy equipment in the network.
8. Application-specific protocols support.
9. IGP routes may need to be advertised into BGP.
10. Some BGP routes may need to be advertised into an IGP.
11. Political boundaries.

Types of Redistribution

Redistribution can be implemented in two ways:

• Unidirectional Redistribution (one-way redistribution): routes are redistributed from the source to the destination protocol on a single routing device in one direction. Conceptually, this type of redistribution is similar to multipoint one-way redistribution where redistribution is implemented on more than one routing device but in the same direction i.e. from source X to destination Y.

  Creation of routing loops in one-way redistribution is not possible. Usually one way redistribution occurs when redistributing from a source that is not a routing protocol such as default routes or static routes. Rarely is one-way redistribution implemented with the source being a routing protocol.

• Mutual Redistribution (two-way redistribution): Mutual redistribution occurs when routes from routing protocol X are injected into routing protocol Y and routes sourced from routing protocol Y are injected into routing protocol X on the same routing device. Mutual redistribution can be thought of as a form of route connversion. Mutual redistribution can be implemented on a single routing device in the network (single-point two-way redistribution) or on two or more routing devices (multipoint two-way redistribution).

  Multipoint mutual redistribution has a high-potential for introducing routing loops. These routing loops can be prevented from occuring using: access-lists or prefix-lists referenced by route-maps. One of the most scalable solutions for preventing routing loops introduced by route redistribution is through the use of route-tags.

Mutual multipoint redistribution provides the benefit of fault-tolerence where the failure of a redistributing device at one point does not affect traffic across both routing domains.

Sources of Routes

Route Source	Description
Connected	Any interface in an "Up" state that is not associated with the destination protocol. Secondary IP addresses are also redistributed.
Static	Any static route that is present in the RIB. Static routes can only be a source i.e. mutual redistribution can not be implemented with static routes.
OSPF	Any routes in the RIB sourced from OSPF. If redistributing from OSPF to BGP, by default, OSPF external routes are not redistributed into BGP unless the match external option is used.
EIGRP	Any routes in the RIB sourced from EIGRP including connected interfaces. Any route that is in the topology table will be redistributed.
BGP	Any routes in the RIB sourced from BGP. By default, routes learned from iBGP peers are not redistributed into IGP protocols unless the command redistribute internal is configured.
IS-IS	Any routes in the RIB sourced from IS-IS. Only routes from the L2 link-state database are selected. Directly connected networks are not included during redistribution.

Redistribution Rules

1. Redistribution is not transitive: Routes that have been redistributed into a routing protocol can not be further redistributed into a third routing protocol on the same routing device. To resolve this, mutual redistribution should be configured between routing protocol A and B, B and C and A with C.
2. Sequential redistribution is allowed when it is spread across multiple routers: Redistributed routes from protocol A into Protocol B on Router R1. These routes can be redistributed into protocol C on router R2.
3. Routes to be redistributed must be in the routing table.

Seed Metric

During redistribution, metric information of the redistributed routes is lost because the different routing protocols calculate route metrics using different methods. Route metrics are only maintained when redistribution occurs from one routing process or autonomous system to another with the same routing protocol.

Seed metric is assigned, by default, to redistributed routes, when no metric is manually configured. The redistribution metric of redistributed routes can be configured in the following ways:

• Using the metric keyword of the redistribution command.
• Configuration of a default metric where all redistributed routes into the destination routing protocol receive the configured default seed metric. This can be implemented using the command default-metric.
• Using a route-map with the metric command.

The recommended best practice from Cisco is to set a default metric when redistributing routes.

The following table shows the seed metric of routes when redistributing from one routing protocol to another.

	DESTINATION
SOURCE	RIP	EIGRP	OSPF	IS-IS	BGP
RIP	Metric maintained	Infinity	20	0	RIP Metric*
EIGRP	Infinity	Metric maintained	20	0	EIGRP Metric*
OSPF	Infinity	Infinity	Metric maintained	0	OSPF Metric*
BGP	Infinity	Infinity	1	0	Path attributes maintained

* The IGP metric becomes the MED path attribute of the prefix.

Routes with the default redistribution metric of infinity are installed into the Link-state database (OSPF), BGP table (BGP) or similar data structures of the destination routing protocol. These routes are not inserted into the routing table because they are considered unreachable due to their metric of infinity. EIGRP does not add routes with infinity metric to its topology table.

When redistributing between two same routing protocols but different processes or autonomous systems, the metric remains unchanged because the destination protocol understands the metric of the source protocol. For example OSPF process 1 to OSPF process 2, the metric of the redistributed routes remains the same.

When redistributing connected networks (on local interfaces),

Configuration of Redistribution

When redistributing routes into a routing protocol from another routing domain, there are many controls that can be implemented that the redistribution point such as tagging, metric configuration, filtering of redistributed routes.

When configuring redistribution, redistribution commmands are entered into the router configuration mode of the destination routing protocol. In a way, the redistribution configuration command says: "Redistribute routes from the specified routing source into this routing source."

EIGRP

Any route that is in the EIGRP topology table is a candidate for redistribution. Routes redistributed into EIGRP are given a default seed metric of infinity. This prevents the routes from being installed into the EIGRP topology table. The exception to this is when redistributing routes from one EIGRP autonomous system to another. In such a scenario, the path metric is maintained.

In IOS, routes redistributed into EIGRP have an administrative distance of 170. This administrative distance is the same regardless of the source routing protocol i.e. even if the source of the prefixes was another EIGRP autonomous system.

Redistribution is configured under the EIGRP router command:

redistribute <source> <metric> <bandwidth> <delay> <reliability> <load> <mtu> route-map <route-map_name>

where <source> is the source of the redistributed routes.

In EIGRP named mode, redistribution is configured under topology base configuration mode as shown below:

R2(config)#router eigrp EIGRP_NAMED
R2(config-router)#address-family ipv4 unicast autonomous-system 1
R2(config-router-af-topology)#redistribute ospf 1


In EIGRP classic mode, redistribution is configured under EIGRP router configuration mode as shown below:

R2(config)#router eigrp 1
R2(config-router)#redistribute ospf 1


When configuring the EIGRP redistribution seed metric, delay value is in tens of microseconds.

When redistributing BGP routes into EIGRP, the administrative tag is set to the autonomous system number of the BGP device that sent the prefixes.

EIGRP requires the configuration of a seed metric during redistribution. If the seed metric is not included in the redistribution, EIGRP will give the route a metric of infinity.

In IPv4, by default, connected routes that are associated with EIGRP will have their configured network addresses included in a redistribution. However, with IPv6, by default, they are not included redistributed. Some connected interfaces may not necessarily be destination networks for network traffic such as transit networks. However, during redistribution, it may be a good idea to redistribute these networks as well as it may sometimes result in traffic blackholing. This is especially likely when utilising some tunneling techniques such as MPLS tunneling.

Redistribution of routers into EIGRP can be implemented using the following EIGRP routing device command: redistribute <source> metric <bandwidth delay reliability load mtu>

Command	Description
BGP	redistribute bgp <ASN> where <ASN> is the BGP autonomous system number.

OSPF

In OSPF, the routing device that redistributes external routes into OSPF is referred to as an autonomous system boundary router (ASBR).

When redistributing routes into OSPF, redistributed routes are given an administrative distance of 110 and are flagged as OSPF external routes. The AD is similar to the administrative distance of intra-area and inter-area routes. When making forwarding decisions for routes from multiple sources, OSPF's prefix selection process gives preference in the following order:

1. intra-area routes
2. inter-area routes
3. external routes
1. external type 1 routes
2. external type 2 routes

The metric for OSPF external type 1 routes equals the redistribution metric plus the total path metric to the autonomous system boundary router. The metric for OSPF external type 2 metric equals only the redistribution metric. If two type 2 routes have the same metric, then the one with the lower forwarding cost is preferred. This is the default external metric type used by OSPF.

When configuring redistribution into OSPF, the OSPF router mode command redistribute is used.

redistribute <source> subnets metric <metric> metric-type (<1 | 2>) tag <0 - 4294967295> route-map <route-map-name>

Where:

• source: the source of routes
• metric: seed metric of the redistributed routes
• route-map: filtering can be applied using the route-map or route path information

In older IOS versions, if the optional subnets command is excluded, only classful routes are advertised. In newer IOS versions, the subnets keyword is automatically added by the IOS into the running configuration.

Redistributing routes between OSPF processes will preserve the path metric during redistribution regardless of the metric type.

To inject EIGRP sourced routes into OSPF:

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 1 subnets

OSPF Forwarding Address

By default, packets destined for external destinations are routed through the advertising autonomous system boundary router (ASBR). Scenarios like this are not optimal in certain circumstances. By default, OSPF sets the forwarding address value to 0.0.0.0. The forward address can be viewed using the command show ip ospf database external.

OSPF will change the forwarding address from 0.0.0.0 to the next-hop IP address in the source routing protocol when:

• OSPF is enabled on the ASBR's interface that points to the next-hop IP address of the redistributed routes.
• The interface is not set to passive.
• The OSPF interface type is set to a broadcast or non-broadcast type.

Enabling OSPF on R2's interface facing towards R1 (10.123.1.1) changes the forwarding address from 0.0.0.0 to the interface pointed towards R1. The forwarding-address changes on R3 irrespective of whether redistribution is configured on R3.

When redistributing OSPF prefixes into another routing protocol, IOS provides the option to match internal, external or NSSA-external routes. This can be useful in preventing the redistribution of external OSPF routes into another routing protocol.

When redistributing into OSPF, the optional subnets keyword results in subnets being included in the redistribution. In newer IOS versions the subnets keyword is automatically included by default if the keyword was not configured.

OSPF External Route Types

OSPF classifies redistributed routes as external type 1 and external type 2 routes. By default, OSPF classifies routes as external type 2 routes.

OSPF issues redistributed routes with a default metric of 20. OSPF external type 1 routes are redistributed with the default metric of 20 and maintain this same metric throughout the OSPF autonomous system. OSPF external type 2 routes have a default metric of 20 or configured redistribution metric. However, as the routes are distributed within the OSPF domain, the metric does not increase.

Command	Description
BGP	redistribute bgp <ASN> where <ASN> is the BGP autonomous system number. When redistributing BGP into OSPF, the subnets keyword is automatically added to the redistribution command.
EIGRP	redistribute eigrp

BGP

Redistributing routes into BGP does not require a seed metric because it is a path vector protocol. Redistributed routes have the following BGP attributes set:

• Origin is set to incomplete
• Next-hop address is set to the next-hop IP address identified in the source protocol.
• The weight is set to 32,768.
• The MED is set to the path metric of the source protocol.

Redistributing routes from OSPF to BGP does not include OSPF external routes by default. The optional match external (1 | 2) keyword is required to redistribute OSPF external routes. The type of OSPF external routes can be configured using 1 or 2 to redistribute type-1 or type-2 routes only.

Protocol	Command
OSPF	redistribute ospf <process> where <process> is the OSPF process ID. When redistributing OSPF routes into BGP, by default, only internal OSPF routes are redistributed into BGP. To redistribute external and nssa-external OSPF routes into BGP, list route type after the redistribute match keyword. With the match keyword external type 1 and/or type 2 routes can be matched. Additionally, the route match can be configured in a route-map.

Formation of Loops

If redistribution happens at one point (one routing device) or two points in one direction, the possibility of a routing loop does not exist. If mutual redistribution at more than one point occurs, then the possibility of loop formation exists.

Route feedback occurs when a redistributed route is advertised back into the original source routing protocol. Route feedback is likely to occur in networks where mutual redistribution is implemented in more than one device i.e. multipoint mutual redistribution. Route feedback causes:

• Sub-optimal routing
• Routing loops
• Invalid routing tables

Types of Loops

Loops exist in two categories:

• Control-plane: exist when routing information is looping. Control-plane loops are detected using the debug ip routing command. This command is largely silent. However, it will display when a route is added or removed from the routing table. If this happens repeatedly, then we can be certain that we are dealing with a loop. Redistribution should be done after observing the debug ip routing output for a while.
• Data-plane: occur when data packets are looping. The best way to detect data-plane loops is to use the ping and traceroute commands. If traffic is being dropped, then a black hole exists. Looped packets may include packets for known networks (in RIB) or unknown networks (default route). With mutual multipoint redistribution, it is also likely that the default route may be looped.

Troubleshooting Loops

Mutual multipoint route redistribution usually forms routing loops. The following techniques can be used to prevent the formation of routing loops during redistribution:

1. Filtering of network prefixes during redistribution.
2. Filtering by route tag during redistribution
3. Increasing the seed metric
4. Modifying the administrative distance.
5. Route summarization

When troubleshooting routing loops:

• Multiple techniques can be combined.
• Document the physical and logical topology to include the routing protocols and desired traffic flows.
• Focus on keeping the source routing domain loop-free.

The underlying principle in preventing the formation of loops in a multipoint mutual redistribution network, at each redistribution point, routes from a source protocol need to be allowed into the destination protocol and these routes prevented from returning from the destination routing protocol back to the source protocol.

Prefix Filtering

Prefixe filtering can be implemented during the redistribution with some prefixes filtered (preventing from being redistributed) on one redistribution device and permitted to be redistributed on another device. This can be used for controlled path manipulation.

Route filtering can be implemented during redistribution through the configuration of a route-map. The prefixes to be filtered are identified through the use of a prefix-list or access control list (ACL).

Filtering Connected Networks

Explicit configuration always overrides implicit configuration. When redistributing the networks assigned to connected interfaces, the use of the network command advertises the networks of the connected interfaces. However, when filtering, if a filter excludes these networks, the networks configured on these interfaces will not be advertised. This affects all IGP protocols that use interfaces to form neighborships such as OSPF, EIGRP. BGP behaves a little different as it is enabled on a per neighbor- basis and not per interface basis. If a route-map references an access list or prefix-list to identify interfaces to be filtered (not redistributed), these interfaces should be identified using the permit ACL keyword.

Route Tagging

A route tag is associated with routes during redistribution. A route-tag is a numeric value associated with a route. Use of the AD of the source protocol for the route-tag is a good technique.

The use of route-tags is a more scalable solution. In the case of prefix-lists and ACLs, everytime a new prefix is added, the prefix-list or ACL needs to be updated to reflect this new addition. When creating route-tags, a recommended best practice is to tag routes using the administrative distance of the routing protocol. This way, it is easier to tell the origin of the route.

Increase Seed Metric

Increase the seed metric to a value higher and less preferred to locally originated routes.This can be done through any of the seed metric configuration methods.

Configuring different seed metric values for different prefixes helps with preventing sub-optimal routing through traffic shaping. The redistribution metric on one redistributing device can be made lower so that to reach these prefixes, traffic transits through a specific path.

The seed metric can be modified through a route-map using the set metric command.

R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.12.2 12 msec 16 msec 20 msec
  2 10.0.24.2 28 msec 64 msec 44 msec
  3 10.0.49.2 52 msec 16 msec 72 msec
  4 10.0.59.1 48 msec 68 msec 60 msec
  5 10.0.35.1 88 msec 28 msec 36 msec

R3(config)#ip access-list standard ACL_10.3
R3(config-std-nacl)#permit 10.0.35.0 0.0.0.3
R3(config-std-nacl)#20 permit 10.3.0.0 0.0.255.255
R3(config-std-nacl)#30 permit 10.0.59.0 0.0.0.3
R3(config-std-nacl)#40 permit 10.5.0.0 0.0.255.255
R3(config-std-nacl)#exit
R3(config)#route-map O2E permit 10
R3(config-route-map)#match ip address ACL_10.3
R3(config-route-map)#set metric 1000000 1 255 1 1500
R3(config-route-map)#set tag 110
R3(config)#router eigrp 1
R3(config-router)#redistribute ospf 1 route-map O2E

R1#show ip eigrp topology 10.0.35.0/30
EIGRP-IPv4 VR(EIGRP_NAMED) Topology Entry for AS(1)/ID(10.1.13.1) for 10.0.35.0/30
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1966080, RIB is 15360
  Descriptor Blocks:
  10.0.13.2 (GigabitEthernet1/0), from 10.0.13.2, Send flag is 0x0
      Composite metric is (1966080/1310720), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 3.3.3.3
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 0
        Administrator tag is 110 (0x0000006E)
  10.0.12.2 (GigabitEthernet0/0), from 10.0.12.2, Send flag is 0x0
      Composite metric is (7864320/7208960), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 110000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.2.13.1
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 4
        Administrator tag is 0 (0x00000000)
R1#

R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.13.2 8 msec 44 msec 16 msec
R1#


Administrative Distance

Increase the administrative distance for external routes on routing protocols that support it. Alternatively, the AD can be modified for preferred routes.

External Route Summarization

Summarizing routes as they are redistributed into the second domain if they are re-inserted back to primary routing domain. They are less specific and not taken.

Route-Maps

Route-maps can be used to prevent the formation of routing loops. Tools to match the traffic include: access-lists, prefix-lists, route-tags, communities (BGP), administrative distance, distribute-lists(ACLs, prefix-lists), offset-lists(ACLs, prefix-lists).

In redistribution of EIGRP to OSPF, using route-tags, the tag for EIGRP is permitted on one mutually redistributing routing device and denied on another redistributing routing device.

For two protocols mutual redistribution at two points: R1 BLUE:
route-map o2E deny 10
match tag 90
route-map O2E permit 20
set tag 110
R1 RED
riyte-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90
R2 RED
route-map O2E deny 10
match tag 90
route-map O2E permit 20
set tag 110

R2 BLUE
route-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90


Redistribution Scenarios

Two-point Mutual Redistribution

Three-point Mutual Redistribution

If three protocols are involved in mutual redistribution at three points. The generic method to prevent the formation of routing loops when redistributing mutually between three or more protocols inside a route map:

1. deny destination protocol
2. match protocol 2
3. match protocol 3
4. match protocol 4
5. match protocol n

The challenge with this redistribution is if the tag will be maintained when redistributing from protocol 1 to protocol 2 and then to protocol 3. For example when redistributing from OSPF into EIGRP and subsequently into RIP. The tag is maintained when copying the routes from:

This may be IOS specific

Source	Destination	Tag Maintained
RIP	OSPF	Yes
RIP	OSPF	YES
EIGRP	RIP	NO
OSPF	RIP	NO
EIGRP	OSPF	YES
OSPF	EIGRP	YES

A solution would be for the following:

route-map O2E deny 10
match tag 90
route-map O2E permit 20
match tag 120
set tag 120
route-map O2E permit 30
set tag 110


The above route-maps will only operate if configured as a system on all the mutually redistributing routers. The route-maps will operate as a system and potentially prevent loops in 99.999% of the cases.

However, some situations exist where the above route-map will not succeed in preventing a routing loop.

When configuring redistribution, the configuration commands should be entered inside the destination routing protocol.

IPv6

By default, IPv6 does not include connected networks when doing redistribution. IPv6 does not include the subnets keyword in OSPFv3. This is because IPv6 does not necessarily use the concept of classful networks. To redistribute connected networks, use the keyaword include-connected.

IOS XE no longer redistributes the connected subnets on the interfaces over which the protocol is enabled. IOS XE routers will only redistribute route entries that exactly match the source protocol in the route table.

The keyword included-connected can be used with the redistribution command to include the locally connected prefixes in the dynamic routing protocol redistribution. The include-connected keyword only injects prefixes for interfaces that have a dynamic routing protocol enabled. To inkect networks for interfaces without a dynamic protocol the redistribute connected command is still required.

TODO : Redistribute some local interfaces and not others. This results in the IP address of the excluded connected interfaces being removed from the routing table. The solution is to include a match statement for that interface in the route map. Redistribution lABS ----------------------------------- -Configure RIP, redistribute OSPF -Configure EIGRP. redistribute to/from RIP, redistribute to/from OSPF -Configure OSPF: redistribute where possible for full connectivity.

BiDirectional Forwarding Detection (BFD)

Introduction and Overview

Bidirectional Forwarding Detection (BFD) is a light-weight standards-based protocol, defined by RFC 5880, that detects failure in the forwarding path on a layer 3 network between two adjacent routers. These failures may be on the connecting interfaces, data links, tunnels, and forwarding planes of devices not directly connected to the routers in a layer 2 network. BFD is capable of working on multiple media types. BFD uses UDP packets to exchange control information with peers on port 49152 as the source port and destination port of 3784.

BFD's primary goal is to detect loss of connectivity between two devices quickly and efficiently. BFD notifies client protocols of the link failure. BFD client protocols include OSPF, IS-IS RSVP, EIGRP, HSRP, BGP, static routes that have registered to receive BFD notifications. BFD provides faster and more consistent failure detection than the hello and keepalive timers of routing protocols. Failure detection in BFD can be in the millisecond range. Most routing protocol timers will detect a link failure at a minimum of one second after it has occurred. It is up to these client protocols to determine how to recover from the failure of the link between the two devices. The client protocols may try to find alternative paths for routes that were initially accessible through the failed device. The client protocols use the BFD-provided information independently. BFD runs to serve these client protocols. It is pointless to run BFD without client protocols.

Networks carrying realtime traffic such as video and voice need speedy network convergence. Link failure detection time usually delays convergence of networks. Traditional link failure detection relies on:

• Hello message timeouts of routing protocols.
• Transmission technology capability to detect failure.

BFD runs independent of routing protocol hello messages and notifies the client protocols of link failure by sending rapid failure detection notices to routing protocols and reducing convergence time through routing table recalculation. BFD can be used in place of routing protocol timers and can act as a single method of liveliness detection between nodes irrespective of media type.

On distributed platforms, BFD packets can be processed on interface modules of the line card hence it is not CPU intensive. In most cases, routing protocol hello packets are processed by the control plane (CPU).

BFD also provides failure detection on virtual circuits such as MPLS LSP, Ethernet virtual circuits tunnels.

By default, BFD topology is primarily point-to-point running on a link between two devices.

BFD can be implemented in multiple ways:

1. Single-hop BFD: BFD for IPv4 and IPv6
2. Generic Application of BFD
3. BFD for MPLS (LSPs)
4. Multihop BFD for peers that are several hops away from each other

Benefits of BFD

The closest alternative to using BFD for failure detection is the hello packet of routing protocols EIGRP, OSPF, IS-IS and BGP keepalive messages. If configured to their minimum supported values, these routing protocol timers usually detect failures of peers or their links within one second of the failure. With OSPF though, configuration of sub-second values is possible using the interface command ip ospf dead-interval minimal hello-multiplier <multiplier> where multiplier is the number of hello packets sent per second;

BFD does have some advantages over the aforementioned failure detection techniques:

• BFD is protocol independent and can therefore act as a generic failure detection mechanism for various routing protocols.
• Parts of BFD failure mechanisms can be configured to operate at the data-plane reducing or eliminating CPU involvement in failure detection. This can be contrasted with failure detection methods of routing protocols that largely operate at the control plane.
• BFD is able to detect failures in the sub-second range compared to most routing protocol failure detection which is usually at a minimum of one second.

Prerequisites for BFD

• Cisco Express Forwarding (CEF) needs to be enabled.
• The client routing protocol should be configured on the router before BFD is deployed.

Restrictions of BFD

• When BFD is enabled on an interface, an access control list (ACL) with the "log" opton is not supported on that interface.
• BFD is not supported in IPSec.

BFD Modes

BFD operates in one of two modes: asynchronous or demand mode. BFD also offers an echo function which works with both modes. Most vendors support asynchronous mode operating with or without echo function enabled.

Asynchronous Mode

BFD control packets are exchanged by neighboring systems at pre-agreed time intervals which is usually in milliseconds. If a specified number of sequential packets are not received from the BFD peer, BFD declares the session to be down and notifies any registered protocol of this failure. Asynchronous mode is supported by Cisco IOS.

Demand Mode

Once the BFD session is established, the participating systems can request that the BFD packets not be sent, then request an exchange of packets only when needed to verify connectivity. Though this mode is defined in the RFC 5880, few network equipment vendors support BFD demand mode.

How BFD Works

Once a BFD session is established with a neighbor, BFD exchanges control packets to verify connectivity and inform the requesting protocol(s) of link failure if a specified number of successive packets are not received. The requesting protocol is then responsible for responding to the link-failure. Routing protocols using BFD for failure detection continue to operate normally when BFD is enabled, including the exchange of their respective hello packets.

A BFD session is a three-way handshake and tear-down process:

1. Routing protocol discovers neighbor and registers neighbor as a client with BFD.
2. BFD control packets act as keepalive to maintain the neighbor session.
3. Failure of the BFD session triggers a notification to the registered routing protocol client which in term tears down the routing protocol neighbor session. If an alternative path exists the routing protocol immediately converges.

BFD Packets

BFD utilises control packets to exchange control information as well as detect the liveliness of the BFD peer.

BFD Control Packet Format

Field	Description
Diagnostic Code (Diag) and Session State:	State in which the BFD session is in and reason i.e. Up/Down/Init.
Discriminators:	demultiplexers
Detect Time Multiplier	Used to calculate detection times for peers. The detection time is the product of the Detect Time Multiplier and Min RX Interval that is used to question a peer's liveliness if a control packet is not received within this product in milliseconds.
Desired Min TX Interval (msecs):	Desired interval to transmit control packets. i.e. how fast the peer desires to send control packets.
Required Min RX Interval (msecs):	Minimum receive interval peer can handle. i.e. rate that the peer can receive packets.
Required Min Echo Interval	Interval within which echo packets are received to indicate liveliness of a peer (if the echo function is enabled).

The following output shows a Wireshark packet capture of a BFD control packet. From this packet capture, it can be determined that the transmit interval is configured to 1000ms, the receive interval to 1000ms, minimum echo interval to 50ms and the multiplier to 3 (x3 the value of the transmit interval).

BFD Control message
    001. .... = Protocol Version: 1
    ...0 0000 = Diagnostic Code: No Diagnostic (0x00)
    01.. .... = Session State: Down (0x1)
    Message Flags: 0x40
        0... .. = Poll: Not set
        .0.. .. = Final: Not set
        ..0. .. = Control Plane Independent: Not set
        ...0 .. = Authentication Present: Not set
        .... 0. = Demand: Not set
        .... .0 = Multipoint: Not set
    Detect Time Multiplier: 3 (= 3000 ms Detection time)
    Message Length: 24 bytes
    My Discriminator: 0x00000002
    Your Discriminator: 0x00000000
    Desired Min TX Interval: 1000 ms (1000000 us)
    Required Min RX Interval: 1000 ms (1000000 us)
    Required Min Echo Interval: 50 ms (50000 us)


Timer Negotiation and Detection Times

When making decisions on detection timers, BFD sends packets as fast as their local peers allow but no faster. A BFD device notes the Required Min RX Interval value received from a peer's BFD control packet (how fast a peer can receive BFD packets) and compares it to its configured Desired Min TX Interval (how fast it can send BFD control packets). The operational transmit interval is then set to whichever of the two values is higher.

When calculating the detection timer values, the local detection is equal to the product of the peer's Detect Time Multiplier and the peer's Tx value. The TX timer and the detection times can be different for each peer.

Given three scenarios where R1 forms a BFD session with peer R2, R3 forms a BFD session with R4 and R5 forms a BFD session with R6, the operational transmit interval and detection time are calculated as shown in the following table:

Device	TX Interval	Min_Rx	Operational TX	Multiplier	Detection Time
R1	50ms	50ms	50ms	3	3 ×50ms = 150ms
R2	50ms	50ms	50ms	3	3 ×50ms = 150ms
R3	50ms	150ms	150ms	5	10 ×150ms = 1500ms
R4	50ms	150ms	150ms	10	5 × 150ms = 750ms
R5	50ms	200ms	150ms	5	10 ×500ms = 5000ms or 5s
R6	500ms	150ms	500ms	10	5 × 150ms = 750ms

The first device to detect that the peer is unreachable will set a flag in the control packet notifying the peer that it is unreachable. The local BFD instance will notify the client routing protocols in each of the peers resulting in both tearing down the routing protocol neighborship.

Echo Function

When the echo function is activated, echo packets are looped back through the layer 3 forwarding path to the BFD peer without involving the CPU. Link failure is detected by an interruption in the stream of echoed packets. Echo function makes it possible for link failure detection using BFD to be handled at the data plane level and not involve the CPU.

The minimum reception rate for BFD control packets from the neighbor is also changed automatically when the echo function is operational, because liveness detection is supplied by the echo packets.

While BFD control messages are transmitted to UDP port 3784, BFD echo messages use UDP port 3785 for both source and destination ports of the BFD echo packet.

BFD started out based on a polling ("asynchronous") approach using control packets. One router polls the other and gets a quick response back. The challenge with this is delay in waking up the BFD process to send a reply, culminating in variable jitter in the response. If the peer is slow in responding BFD triggers a link failure notification, which is not ideal. It is possible to configure both peers to send BFD echo packets or one peer to send the BFD echo packet. The latter approach is referred to as BFD asymmetry.

The Echo function is an additional feature that can be enabled in any of the BFD operational modes i.e. asynchronous or demand modes. The BFD echo function enhances BFD in one very specific way; it allows the devices running BFD to test the actual forwarding path taken by data packets. This is a capability that the control packets are not able to carry out. In some IOS distributions, the Echo function is enabled by default.

Echo Packets

The Echo function uses echo packets using interesting values for the IP source and destination addresses. The destination IP address is set to the IP address of the sender. In other words, the destination IP address is the same as the source IP address of the sender. For Layer 2 addressing, the destination address is the MAC address of the BFD peer.

After the BFD peer receives an echo packet and determines that the destination IP address is different from any of its IP addresses, it consults the RIB/FIB to determine how to forward the packet and sends it to the sender. In this way it uses the data forwarding path of network traffic.

Echo Function in BFD Asynchronous Mode

Peers need to exchange BFD information such as intervals, State, Diag etc. Echo packets do not carry usable data and are technically processed by the sender. Control packets are still exchanged but the frequency is substantially decreased. In BFD asynchronous mode without the echo function, the control packets play the dual-role of exchanging BFD session information and detecting link failure. In BFD asynchronous mode with echo function, the echo function uses control packets to exchange BFD information as usual. However, the control packets are sent less frequently; more frequently sent are echo packets which take the primary role of detecting link failure.

Echo Function Activation

BFD peers use the control packet to signal activation of the echo function. The control packet field Required Min Echo Interval is used to signal echo function activation to a BFD peer. If the echo function is activated, the Required Min Echo Interval field contains a value in milliseconds. It is used to communicate to the BFD peer the minimum rate of the sender receiving echo packets. Conceptually, it is similar to the Required Min RX Interval of the Echo packet. The frequency of Echo packet are therefore partially dictated by the neighbors. Echo packets can not be sent more frequently than the Required Min RX Interval values of the BFD peer. If the echo function is not activated, the control packets from the peer will contain zero values for the Required Min Echo Interval field.

Restrictions to Using the Echo Function

1. Disable ICMP redirects on any interface where the BFD echo function will be used using the command no ip icmp redirects. With ICMP redirect active on an interface, the interface will notice that the echo packets are looped back. It will then generate an ICMP redirect message for each echo packet. Disabling ICMP redirect messages helps in avoiding high CPU uilization.
2. Any uRPF checks will need to be disabled on the interface or an exception should be made for echo packets on the interface. Based on the way echo packets are transmitted and looped back, they fail uRPF checks; depending on how strict the uRPF checks have been configured. If BFD echo mode and uRPF are configured on the same interface, BFD sessions will flap.

BFD Slow Timer

BFD can use the slow timer to slow down the transmission rate of BFD control packets when the echo function is enabled. This reduces the number of BFD control packets that are sent between two BFD neighbors. With echo function enabled, control packets are not used for failure detection hence may not be desirable to be exchanged frequently. This, in turn, further lightens the CPU load.

To configure BFD slow timer use the global configuration mode command bfd slow-timer <milliseconds>:

R6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z
R6(config)#bfd slow-timers 12000
R6(config)#

BFD Configuration

Configuration of BFD is a two step process:

Step 1: Enable BFD on interface through which the peer is reachable using the interface configuration command: bfd interval <tx-interval> min_rx < min_rex> multiplier <multiplier>. The rate of exchanging hello control packets (similar to hello-timer) can be set in the range 50 - 9999 milliseconds. min_rx: minimum interval supported for receiving BFD control packets from a neighbor. multiplier: used to compute the hold-down time. If multiplier is 3 and hello interval 50 then holddown timer is 150 ms.

R6(config)#interface gigabitethernet0/0
R6(config-if)#bfd interval 100 min_rx 50 multiplier 3


Step 2: Configure the routing protocol to use BFD for failure detection. Interested clients include static routing, EIGRP, OSPF, BGP, FHRP(HSRP, VRRP, GLBP), MPLS LSP, etc registers with BFD and is notified as soon as BFD detects a neighbor loss.

BFD for BGP

BFD must be running on all participating BGP devices.

R6(config)#router bgp 65531
R6(config-router)#neighbor 1.1.1.1 remote-as 65532
R6(config-router)#neighbor 1.1.1.1 fall-over bfd ?
  multi-hop   Force BFD multi-hop to detect failure
  single-hop  Force BFD single-hop to detect failure
<cr>

BFD in BGP supports two session types: multi-hop and single-hop. This is because BGP supports BGP peers that can be directly connected or several hops away. This BFD session type will depend on the BGP session type of the neighbor being configured; if the neighbor is several hops away, configure the BFD multi-hop type.

BFD in EIGRP

In EIGRP named mode, BFD is configured under the af-interface mode:

R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
R6(config-router-af-interface)#

If BFD is configured under af-interface default, all interfaces with EIGRP peers will be registered to receive BFD notifications. However, remember that BFD has to first be configured on the interface otherwise the following error messaage will be generated:

R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
%EIGRP: BFD interval is not configured on interface GigabitEthernet0/0 required for BFD operation.
R6(config-router-af-interface)#

In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on link failure on a single interface as below:

R6(config)#router eigrp 2
R6(config-router)#bfd interface gigabitethernet 0/0

In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on all EIGRP-enabled interfaces as below:

R6(config)#router eigrp 2
R6(config-router)#bfd all-interfaces

NOTE: Configuration of EIGRP to receive notifications from all EIGRP enabled interfaces as demonstrated above does not issue a log message if BFD has not been enabled on the interface using the interface-mode BFD configuration commands.

BFD in OSPF

BFD is configured in OSPF for all interfaces with the router ospf mode command bfd all-interfaces. The command does not provide the additional flexibility of EIGRP of installing on select interfaces or all interfaces at once. To enable BFD on an interface, issue the following interface configuration command: ip ospf bfd

Under an interface, to disable BFD for a specific interface in interface mode issue the command: ip ospf bfd disable.

BFD in Static Routing

BFD is able to detect failures in the forwarding path of static routes. To configure BFD in static routing:

R6(config)#interface g1/0
R2(config-if)#bfd interval 250 min_rx 150 multiplier 3
R2(config-if)#exit
R6(config)#ip route static bfd gigabitethernet1/0 10.0.26.1


Verification

BFD operation can be verified using the command show bfd neighbors (detail)

BFD Troubleshooting

Troubleshooting of BFD may be required when BFD is not functioning effectively:

• BFD session down: Verify BFD configuration on both routers.
• BFD session is flapping: check if uRPF has been configured on the interface.

The following commands are important in troubleshooting BFD:

Command	Description
show bfd neighbor detail	Displays the BFD adjacency database. The details keyword shows all BFD protocol parameters and timers per neighbor.
debug bfd event	Displays debugging information about BFD control packets or events such as BFD state transitions.

Recommendations on Deployment of BFD

• The use of BFD echo function is encouraged.
• BFD may not be necessary if devices are directly connected on point to point link without any other device such as a switch in-between. BFD is ideal if two routers are connected to each other with a switch interconnecting the two devices.
• Remember to configure the slower timer command, when you enable BFD echo function.

UNDERSTANDING BGP

Contents

1. Introduction
2. Autonomous Systems
   1. Types of Autonomous Systems
   2. Connections to ISPs
   3. Prefix Sharing with ISPs
3. BGP Message Types
4. Neighbor State
5. Session Types
6. BGP Security
7. Verification
8. BGP Tables
1. Loc-RIB
2. Adj-RIB-in
3. Adj-RIB-out
4. Prefix Advertisement
5. Prefix Processing
9. Path Attributes
1. Best Path Selection
2. Loop Prevention
10. BGP Equal-Cost Multipath
11. iBGP Scalability
1. Full Mesh
2. Route Reflector
3. Confederations
12. BGP Communities
13. BGP Optimization
1. Peer Groups
2. Peer Templates: Session and Policy Templates
3. Summarization
4. Filtering
5. Maximum Prefix
6. Default Route Propagation
14. Troubleshooting BGP

Introduction and Overview

BGP is an open standard path vector routing application based on RFC 4271. As of 2023, BGP is the only external gateway protocol in active use. BGP's primary purpose is to interconnect autonomous systems and allow the sharing of prefixes among them; Internet Service Providers (ISPs) use BGP to share prefixes. Other BGP use cases include: prefix exchange in large data centers (RFC 7938) and scaling of DMVPN where locally significant autonomous system numbers are used.

BGP forms point-to-point peerings resulting in unicast peer relationships between BGP routers. The adjacencies between BGP peers is known as BGP sessions or peering. BGP does not use hello packets to discover neighbors and due to this, BGP routers can not discover each other dynamically. Neighbor relationships need to be configured manually. BGP is able to form neighbor relationships across many hops; what is commonly referred to as a multihop relationship.

This is possible because BGP uses TCP as the transport protocol. BGP updates are incremental and triggered.

BGP makes extensive use of TCP in its operations using TCP port 179 and depends on TCP reliability mechanisms for transmission of messages. TCP is responsible for:

1. handling of fragmentation
2. sequencing of packets
3. ensuring packets are reliably transmitted

TCP allows for multi-hop BGP sessions. This directly implies that BGP requires the implementation of an interior gateway protocol (IGP) such as OSPF and IS-IS first in the network.

BGP provides high scalability and flexibility that does not compare to interior gateway protocols. BGP can support millions of prefixes. As of this writing, the IPv4 Internet routing table contains approximately 940,000+ (Jan 2023) prefixes and counting.

Path selection is based on the multiple path attributes associated with each prefix (and not the link). Path attributes are characteristics of a prefix and include AS_PATH, local preference, multi-exit discriminator, weight and many others. Path attributes influence the best path selection process that each BGP device makes.

BGP supports the advertisement of directly connected networks, learned routes (static or from routing protocols) that exist in the RIB without the need for redistribution.

Why use BGP

1. Support for a large number of prefixes.
2. Policy application i.e. easy to influence ingress and egress traffic.

The following are selected use cases under which the use of BGP can be considered:

• Scaling the enterprise: to interconnect different implementations of discrete IGPs.
• Scaling DMVPN: hubs in DMVPN can be configured as route reflectors.
• Scaling data centers
• When the autonomous system is working as a transit autonomous system for example, an Internet service provider (ISP).
• AS is connected to multiple AS i.e. multihomed and data traffic path entering or leaving the AS needs to be manipulated.

Autonomous Systems

An autonomous system is a collection of routing devices under a single organization's control. Autonomous systems can use one or more interior gateway protocols (IGPs) and common metrics to route packets within the autonomous system. If multiple IGPs or metrics are used within an autonomous system, the autonomous system must appear consistent to external autonomous systems in routing policy. An IGP is not required within an autonomous system; an autonomous system could use BGP as the only routing protocol.

Autonomous systems are uniquely identified by an autonomous system number (ASN). Every autonomous system is provided with an autonomous system number (ASN) that is ultimately issued by the Internet Assigned Numbers Authority (iana.org). Originally, the ASNs issued were 2 bytes(16 bits) in the range 0 - 65535. The publically issued ASNs were in the range 1 - 64495. The 2 byte ASNs were depleted rapidly resulting in the 4 byte ASNs being adopted based on the recommendation of RFC 4893. The ASN range with 4 bytes is 0.0 - 65535.65535. 32-bit (4 byte) autonomous system numbers have been available since 1/1/2007. All ASNs issued today are 32-bit.

Two blocks of private ASNs are available for any organisation to use as long as they are never exchanged publically on the Internet i.e. 64512 - 65534 in the 16-bit range and ASN 4200000000 - 4294967294 in the 32-bit range. Service providers sometimes assign a private ASN to an organization which is then stripped as the network prefix is advertised outside of the service provider's autonomous system. Private ASNs are issued to organizations that have a single connection to an ISP. Private ASNs should be used if an autonomous system is only required to communicate using BGP with a single service provider as the routing policy between the provider and the autonomous system will not be visible on the public Internet. A private ASN received from a local Internet registry (LIR) cannot be retained if the organization migrates to another service provider. A public ASN is required only when an autonomous system is exchanging routing information with other autonomous systems on the public Internet i.e. all routes originating from an autonomous system are visible on the Internet.

In BGP, ASNs act as a loop prevention mechanism and can be used for traffic engineering.

IANA is responsible for assigning all public ASNs to ensure that they are globally unique. IANA requires the following information when requesting for a public ASN:

1. Proof of a publically-allocated network range i.e. addresses are owned by the enterprise.
2. Proof that Internet connectivity is provided through multiple service provider connections.
3. Need for a unique routing policy from service providers.

In the event that an organisation can not provide this information, it should use the ASN provided by its service provider. IANA delegates issuing ASNs to the regional Internet registries (RIR) such as AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC. The appropriate RIRs then allocate blocks of ASNs to local internet registries (LIR) which are usually ISPs.

Special-Purpose ASNs

The following table displays ASNs that are reserved for special purposes and are not to be used on Internet facing BGP configurations:

AS Number	Reason for Reservation	Reference
0	Reserved	[RFC7607]
112	Used by the AS112 project to sink misdirected DNS queries	[RFC7534]
23456	AS_TRANS	[RFC6793]
64496-64511	For documentation and sample code	[RFC5398]
64512-65534	For private use(reserved)	[RFC6996]
65535	Reserved	[RFC7300]
65536-65551	For documentation and sample code	[RFC5398]
4200000000-4294967294	For private use; reserved	[RFC6996]
4294967295	Reserved	[RFC7300]

Types of Autonomous Systems

There are three different kinds of Autonomous Systems:

• Stub AS: connects to only one other AS, though it may have its own private connections not visible to the rest of the Internet. A corporate network connected to an ISP may be considered to have the same ASN as the ISP it is connected to. Another example is a lower-tier ISP that gets its service from another ISP.
• Multi-homed AS: connects to two or more ASes. This allows the AS to maintain its Internet connection should one AS connection fail. A multi-homed autonomous system does not allow traffic from one AS to pass through it to another AS. Many enterprise ASs fall in this category.
• Transit AS: interconnects two or more ASs, allowing for traffic to transit through it. ISPs fall in this category. The complete path for traffic may involve multiple transit AS.

Representation of 32-bit Autonomous System Numbers (ASNs)

In BGP configuration, there are three ways of representing 32-bit autonomous system numbers:

1. as-plain is a simple decimal representation 0 - 4294967295. This is the default AS notation used in Cisco IOS.
2. asdot+ breaks the number up into low-order and high-order 16-bit values separated by a dot. All of the older 16-bit autonomous system numbers can be represented in the low-order value with the high-order value set to zero for example: 65535 = 0.65535. 65536 is outside the range of the low-order values and is therefore represented as 1.0. 65537 is represented as 1.1. 65680 is represented as 1.33.

   Conversion between decimal and asdot+ notation can be done from the .

3. asdot consists of both asdot+ and as-plain notations; any autonomous system number in the 16-bit(2 byte) range i.e. 0 - 65535 is written in asplain notation and 32-bit ASNs are written in asdot+ notation. To enable asdot notation, enter the command: bgp asnotation dot under BGP router configuration mode.

AS Connections to ISPs

An AS can be connected to an ISP through four possible options: single-homed, dual-homed, multi-homed, and dual multi-homed.

1. Single-homed: AS has a single connection to one ISP i.e. single exit point from the AS. The sharing of prefixes by the AS with the ISP is usually through static routes and the ISP advertises a default route.
2. Dual-homed: AS has two connections to the same ISP either through the same router or two separate routers. One link may be the primary and the other the backup. The AS might load balance traffic over both links. In this connectivity type, the AS can advertise prefixes through static configuration and a default route is received from the ISP. The use of BGP may not be recommended in this scenario.
3. Multi-homed: connection to more than one ISP at the same time. This provides increased redundancy and backup if one ISP fails. Path manipulation is possible providing better performance for traffic by ensuring that critical traffic transits through one ISP and other traffic is sent through a second ISP. This type of connectivity ensures that path manipulation is ISP-independent. BGP is typically used with multi-homed connections.
4. Dual-multi-homed: The AS connects to the multi-homed ISPs using more than one connection. Here, BGP is used to share prefixes with the ISPs and potentially internally within the AS as well.

BGP is recommended to be used in multihomed and dual multi-homed type of connections. It is important to note that unless the enterprise network provides transit capability, multihomed connections, if not carefully configured, may provide transit capability resulting in transit traffic consuming bandwidth. Ensure that the BGP configuration for a multihomed connectivity to the enterprise AS does not provide transit capability.

BGP Route Reception from ISPs

ISPs can share prefixes with the enterprise network using BGP; three options are possible:

1. Default route from ISP: the ISP shares a default route only with the enterprise AS. Path manipulation is not possible. This is a preferred option with an enterprise AS that does not have the requisite resources such as small and medium sized enterprise AS.
2. Default route and specific routes: the AS receives a specific subset of prefixes from the ISPs. This subset may be for destinations of interest to the AS. Path manipulation can be implemented for these specific prefixes such as exit through a specific link and all other traffic uses the default route. Good for medium AS.
3. Full BGP table: entire BGP table is shared between the ISPs and the AS. This option requires extensive high-end routers at the enterprise AS. This option is appropriate for large AS such as ISPs or large enterprise networks.

BGP Messages

BGP messages consist of the message header and message body. The message header of all BGP packet types contains similar information. The BGP message body will contain different formatting and information depending on the message type.

BGP Header

All BGP packet types contain a header field. The BGP header contains the following fields:

Marker field:	16-octets and is filled with all ones but its use is now deprecated in the BGP standard. It was originally used for detecting loss of synchronization between peers, authentication information. It is likely maintained to support backwards compatibility.
Length:	contains a value denoting the overall length of the message.
Type:	indicates what type of BGP message is contained in the packet i.e. 1 OPEN message 2 UPDATE message 3 NOTIFICATION message 4 KEEPALIVE message 5 ROUTE refresh

An optional data field follows the header. A Keepalive message type does not contain data. The following Wireshark packet capture shows the details of the BGP header.

Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 67
    Type: UPDATE Message (2)



BGP Message Types

BGP uses five message types for communication: OPEN, UPDATE, ROUTE-REFRESH, NOTIFICATION, and KEEPALIVE. A BGP message can contain one or more of these BGP message types depending on the amount of information to be transmitted.

OPEN

The BGP open message is used to establish a BGP adjacency. It is used to advertise the local ASN, timer values, BGP identifier, BGP capabilities such as: multi-protocol support, route refresh capability, support for 4-octet ASNs. 4 byte ASNs support is negotiated during capability exchange. The old BGP speakers are sent ASdot numbers encoded as ASN "23456". The real AS-Path is encoded with the optional transitive attributes AS4_AGGREGATOR and AS4_PATH. BGP OPEN messages have a value of 1 (one) in the type field of the message header. After configuring the BGP neighbor command to define a neighbor, BGP sends an OPEN message to try to establish a peering relationship with that neighbor. The OPEN message contains the following fields: version, My AS, holdtime, BGP identifier fields. The BGP OPEN packet body contains fields that advertise the local BGP capabilities.

Version:	Contains the BGP version (usually version 4).
My AS	The autonomous system number of the local device. This is important for determining whether the BGP peering session will be iBGP or eBGP.
Hold time:	Contains sender's hold time, the recipient compares this hold timer value with its configured (or default) hold timer and uses the smaller hold timer value for the peering. The minimum hold timer value needs to be either zero or at least three seconds. Monitoring of the hold timer values can be disabled by configuring a holdtimer value of zero. This also disables the transmission of keepalive messages. For Cisco devices, the default hold time is 180 seconds. When the hold time expires, the BGP session is torn down and prefixes originated by the unreachable peer are purged from the BGP table. An update with a route withdrawal is sent to other BGP peers for the affected prefixes.
BGP Identifier:	The BGP Identifier is 32-bit and is in the form of an IPv4 address. It is the BGP router ID. It is critical for uniquely identifying a device in the BGP peering. The BGP identifier must have a non-zero value for routers to become peers.
Optional parameters and Optional Parameter Length:	This field contains the local BGP device's capabilties which provide added flexibility with the protocol.

The following output is a Wireshark packet capture of a BGP OPEN message.

Border Gateway Protocol - OPEN Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 57
    Type: OPEN Message (1)
    Version: 4
    My AS: 65000
    Hold Time: 180
    BGP Identifier: 10.7.11.1
    Optional Parameters Length: 28
    Optional Parameters
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 6
            Capability: Multiprotocol extensions capability
                Type: Multiprotocol extensions capability (1)
                Length: 4
                AFI: IPv4 (1)
                Reserved: 00
                SAFI: Unicast (1)
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 2
            Capability: Route refresh capability (Cisco)
                Type: Route refresh capability (Cisco) (128)
                Length: 0
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 2
            Capability: Route refresh capability
                Type: Route refresh capability (2)
                Length: 0
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 2
            Capability: Enhanced route refresh capability
                Type: Enhanced route refresh capability (70)
                Length: 0
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 6
            Capability: Support for 4-octet AS number capability
                Type: Support for 4-octet AS number capability (65)
                Length: 4
                AS Number: 65000


UPDATE

When BGP devices become peers, they start exchanging their best Network Layer Reachability Information (NLRI) using the UPDATE message. NLRI consists of network prefixes, prefix length (subnet mask) and associated path attributes. BGP UPDATE messages have a value of 2 in the type field of the BGP header. They are used for advertising any feasible routes, withdrawals of previously advertised routes or both. UPDATE messages include Network Layer Reachability Information (prefix) and associated path attributes when advertising prefixes. Withdrawn prefixes only include the prefix and prefix length of prefixes previously advertised but now being withdrawn. An UPDATE message can act as a keepalive to reduce unnecessary traffic. UPDATE messages are sent until the complete BGP table has been fully exchanged.

The fields of a BGP UPDATE message include the following:

Withdrawn Routes Length:	Denotes the size of the packet used for the withdrawn routes. If there are no withdrawn routes, this field will contain the value zero.
Total Path Attribute Length	Size of the path attributes of the prefixes in the update.
Path Attributes:	Various path attributes along with their respective characteristics such as flags denoting whether the path attribute is well-known, transitive, path attribute length.
Network Layer Reachability Information (NLRI):	Prefixes and their associated subnet masks.

 

Marker: ffffffffffffffffffffffffffffffff
Length: 57
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 24
Path attributes
    Path Attribute - ORIGIN: IGP
        Flags: 0x40, Transitive, Well-known, Complete
            0... .... = Optional: Not set
            .1.. .... = Transitive: Set
            ..0. .... = Partial: Not set
            ...0 .... = Extended-Length: Not set
            .... 0000 = Unused: 0x0
        Type Code: ORIGIN (1)
        Length: 1
        Origin: IGP (0)
    Path Attribute - AS_PATH: 65536 65537
        Flags: 0x40, Transitive, Well-known, Complete
            0... .... = Optional: Not set
            .1.. .... = Transitive: Set
            ..0. .... = Partial: Not set
            ...0 .... = Extended-Length: Not set
            .... 0000 = Unused: 0x0
        Type Code: AS_PATH (2)
        Length: 10
        AS Path segment: 65536 65537
            Segment type: AS_SEQUENCE (2)
            Segment length (number of ASN): 2
            AS4: 65536
            AS4: 65537
    Path Attribute - NEXT_HOP: 10.67.1.2
         Flags: 0x40, Transitive, Well-known, Complete
            0... .... = Optional: Not set
            .1.. .... = Transitive: Set
            ..0. .... = Partial: Not set
            ...0 .... = Extended-Length: Not set
            .... 0000 = Unused: 0x0
         Type Code: NEXT_HOP (3)
         Length: 4
         Next hop: 10.67.1.2
Network Layer Reachability Information (NLRI)
    10.78.1.0/30
        NLRI prefix length: 30
        NLRI prefix: 10.78.1.0
    10.108.1.0/30
        NLRI prefix length: 30
        NLRI prefix: 10.108.1.0


To simulate prefix withdrawal, an interface can be shutdown. This triggers BGP to send a withdrawal of the advertised network assigned to that interface.

Marker: ffffffffffffffffffffffffffffffff
Length: 33
Type: UPDATE Message (2)
Withdrawn Routes Length: 10
Withdrawn Routes
    10.78.1.0/30
        Withdrawn route prefix length: 30
        Withdrawn prefix: 10.78.1.0
    10.108.1.0/30
        Withdrawn route prefix length: 30
        Withdrawn prefix: 10.108.1.0
Total Path Attribute Length: 0


BGP updates are sent to neighbors as unicast messages.

NOTIFICATION

BGP NOTIFICATION messages are sent when an error is detected with the BGP session such as hold timer expiring, neighbor capabilities changing or a BGP session hard reset being requested. This causes the BGP session to close. NOTIFICATION messages have a value of 3 in the type field of the BGP message header. The presence of a NOTIFICATION message in a network is a sign of a problem in BGP. They contain the following fields:

Field	Description
Major error Code:	Main cause of the notification message. Potential values include cease(6)
Minor error Code:	Finer details of the error.

Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: Cease (6)
    Minor error Code (Cease): Unknown (0)


KEEPALIVE

BGP peers exchange keepalive messages to maintain the TCP session. Keepalive messages are exchanged every one third of the hold timer agreed upon between the two peers (default is 60 seconds). A hold timer of zero disables the transmission of KEEPALIVE messages. A KEEPALIVE message consists of a BGP header with no body.

Border Gateway Protocol - KEEPALIVE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 19
    Type: KEEPALIVE Message (4)


ROUTE REFRESH

ROUTE-REFRESH messages are used to exchange changes in NLRI without having to reset peerings. Route-refresh message types were not included in the original BGP RFC. However, they are now supported by major network equipment vendors. ROUTE-REFRESH messages have a message type value of 5 in the BGP header. ROUTE-REFRESH is usually set when BGP session and/or policy parameters have been changed and these new changes are to be implemented on the session and prefixes prefixes exchanged. ROUTE-REFRESH message are sent after a soft-reset command has been issued. A hard reset does not trigger the transmission of ROUTE-REFRESH messages. A ROUTE REFRESH BGP packet contains the following fields:

Address family identifier (AFI):	Identifies the address-family whose prefixes are to be affected by the route-refresh.
Subtype:	Whether it is a normal route refresh
Subsequent address family identifier (SAFI)	This can be unicast or multicast.

The following code output shows a Wireshark capture of a BGP packet containing ROUTE-REFRESH message:

Marker: ffffffffffffffffffffffffffffffff
Length: 23
Type: ROUTE-REFRESH Message (5)
Address family identifier (AFI): IPv4 (1)
Subtype: Normal route refresh request [RFC2918] with/without ORF [RFC5291] (0)
Subsequent address family identifier (SAFI): Unicast (1)


BGP Neighbor State

BGP maintains a table of peers with which NLRI is exchanged along with their session state. The different BGP session states include Idle, Connect, Active, OpenSent, OpenConfirm and Established.

Idle

This is the state that the BGP process enters when initially configured or reset. In this state, the device waits for a start event such as a peering configuration with a remote peer. After the device receives a TCP connection request from a remote peer, the device initiates another start event to wait for a timer before starting a TCP connection to a remote peer.

If an error is experienced in other BGP states, or a reset is implemented, the BGP state returns to the Idle state. In this state, the ConnectRetry timer is set to 60 seconds and must decrement to zero before the connection can be initiated again. Any additional failures experienced in the idle state result in the ConnectRetry timer doubling in length from the previous time.

Connect

BGP is waiting for the TCP connection with a neighbor to be completed or a remote BGP peer is trying to initiate a TCP connection with the local BGP device. If the TCP connection completes successfully;

• a BGP OPEN message is sent to the neighbor
• the BGP state transitions to the OpenSent.
• the ConnectRetry timer is reset.

During the connect state, the router with the higher IP address manages the connection. If successful, the BGP state transitions to OpenSent. If the ConnectRetry timer times out before the TCP connection is successful, the BGP state transitions to the Active state. If BGP is reset, the state transitions to the Idle state.

Active

BGP is trying to initiate a TCP connection with its peer because the TCP three-way handshake did not complete. TCP initiates a new three-way handshake again to establish a connection and the ConnectRetry timer is started. Additionally, BGP is also listening for incoming TCP connections. If successful, an OPEN message is sent and the BGP state transitions to OpenSent.

If the TCP connection fails, the state moves back to the Connect state and resets the ConnectRetry timer. If BGP is reset or an error occurs, the state moves back to Idle.

Troubleshooting

A BGP peer state may remain in active due to the following potential reasons:

• The neighbor is peering with the wrong address.
• Neighbor does not have a neighbor statement for this router.
• AS number mismatch.
• Neighbor does not have a route to the source IP address of the Open packet received from the connecting BGP device.

OpenSent

In this state, the TCP session is up and BGP has sent an OPEN message to establish a peering session with the remote peer. The local BGP device is waiting for the peer's matching OPEN message. If the peer's OPEN message is received, BGP checks the following parameters:

1. BGP router IDs must be unique. If no BGP Router ID exists, the condition requiring that BGP router IDs be unique is not met and a BGP peering session will not be created.
2. BGP versions must match.
3. OPEN message autonomous system number must match the configured neighbor's autonomous system number.
4. OPEN message source IP address must match the configured neighbor IP.

If the OPEN messages do not have any errors, the holdtime is negotiated and a KEEPALIVE message is sent. The connection state is then moved to OpenConfirm. If an error is found in the OPEN message, a NOTIFICATION message is sent and the state is moved to Idle. If TCP receives a disconect message, BGP closes the connection, resets the ConnectRetry timer and sets the state to Active.

OpenConfirm

The BGP router has sent a KEEPALIVE message to its peer. It now awaits for a KEEPALIVE or NOTIFICATION message from the peer after receiving its OPEN message. At this point, both routers have sent and received OPEN messages. If a KEEPALIVE message is received from the remote peer, the state transitions to established. BGP will continue sending KEEPALIVE messages.

If the holdtimer expires, a stop or reset event occurs or a NOTIFICATION message is received, the state is moved to Idle.

Established

BGP session has been fully established and neighbors can exchange routes. All neighbor parameters match and the peers can now exchange updates. The BGP neighbor adjacency is complete. BGP routers send UPDATE packets to exchange routing information. BGP resets the hold timer every time a keepalive is received or update is received. If a NOTIFICATION message is received, the state transitions to idle state. With the established state, a TCP session between the two BGP peers can be displayed using the command show tcp brief.

As updates are received, the hold timer is reset. If the hold timer expires, BGP moves the peer back to idle state. The idle and active states for BGP routers that were previously in the established state is usually not a good sign.

The following output shows debugging messages displaying the various BGP state transitions:

R7#debug bgp ipv4 unicast
*Dec 4 01:29:24.782: BGP: 10.67.1.1 restarting - interface GigabitEthernet0/0 up
*Dec 4 01:29:24.782: BGP: nbr global 10.67.1.1 Active open failed - open timer running
*Dec 4 01:29:24.802: BGP: nbr global 10.67.1.1 Active open failed - open timer running
R7(config-if)#
*Dec 4 01:29:33.030: BGP: 10.67.1.1 active went from Idle to Active
*Dec 4 01:29:33.034: BGP: 10.67.1.1 open active, local address 10.67.1.2
R7(config-if)#
*Dec 4 01:29:35.102: BGP: ses global 10.67.1.1 (0x691E20C8:0) act Adding topology IPv4 Unicast:base
*Dec 4 01:29:35.106: BGP: ses global 10.67.1.1 (0x691E20C8:0) act Send OPEN
*Dec 4 01:29:35.110: BGP: ses global 10.67.1.1 (0x691E20C8:0) act Building Enhanced Refresh capability
*Dec 4 01:29:35.110: BGP: 10.67.1.1 active went from Active to OpenSent
*Dec 4 01:29:35.114: BGP: 10.67.1.1 active sending OPEN, version 4, my as: 23456, holdtime 180 seconds, ID A070B01
*Dec 4 01:29:35.182: BGP: 10.67.1.1 active rcv message type 3, length (excl. header) 2
*Dec 4 01:29:35.182: %BGP-3-NOTIFICATION: received from neighbor 10.67.1.1 active 6/0 (CEASE: unknown subcode) 0 bytes
*Dec 4 01:29:35.186: BGP: ses global 10.67.1.1 (0x691E20C8:0) act Receive NOTIFICATION 6/0 (CEASE: unknown subcode) 0 bytes
*Dec 4 01:29:35.186: BGP: ses global 10.67.1.1 (0x691E20C8:0) act Reset (BGP Notification received).
*Dec 4 01:29:35.186: BGP: 10.67.1.1 active went from OpenSent to Closing
*Dec
R7(config-if)# 4 01:29:35.190: BGP: nbr_topo global 10.67.1.1 IPv4 Unicast:base (0x691E20C8:0) NSF delete stale NSF not active
*Dec 4 01:29:35.190: BGP: nbr_topo global 10.67.1.1 IPv4 Unicast:base (0x691E20C8:0) NSF no stale paths state is NSF not active
*Dec 4 01:29:35.190: BGP: nbr_topo global 10.67.1.1 IPv4 Unicast:base (0x691E20C8:0) Resetting ALL counters.
*Dec 4 01:29:35.190: BGP: 10.67.1.1 active closing
*Dec 4 01:29:35.194: BGP: ses global 10.67.1.1 (0x691E20C8:0) act Session close and reset neighbor 10.67.1.1 topostate
*Dec 4 01:29:35.194: BGP: nbr_topo global 10.67.1.1 IPv4 Unicast:base (0x691E20C8:0) Resetting ALL counters.
*Dec 4 01:29:35.194: BGP: 10.67.1.1 active went from Closing to Idle
*Dec 4 01:29:35.194: %BGP_SESSION-5-ADJCHANGE: neighbor 10.67.1.1 IPv4 Unicast topology base removed from session BGP Notification received
*Dec 4 01:29:35.194: BGP: ses global 10.67.1.1 (0x691E20C8:0) act Removed topology IPv4 Unicast:base
*Dec 4 01:29:35.194: BGP: ses global 10.6
R7(config-if)#7.1.1 (0x691E20C8:0) act Removed last topology
*Dec 4 01:29:35.194: BGP: nbr global 10.67.1.1 Open active delayed 10240ms (35000ms max, 60% jitter)
*Dec 4 01:29:35.194: BGP: nbr global 10.67.1.1 Active open failed - open timer running
R7(config-if)#
*Dec 4 01:29:45.318: BGP: 10.67.1.1 active went from Idle to Active
*Dec 4 01:29:45.322: BGP: 10.67.1.1 open active, local address 10.67.1.2
*Dec 4 01:29:45.362: BGP: ses global 10.67.1.1 (0x6AF16050:0) act Adding topology IPv4 Unicast:base
*Dec 4 01:29:45.366: BGP: ses global 10.67.1.1 (0x6AF16050:0) act Send OPEN
*Dec 4 01:29:45.366: BGP: ses global 10.67.1.1 (0x6AF16050:0) act Building Enhanced Refresh capability
*Dec 4 01:29:45.366: BGP: 10.67.1.1 active went from Active to OpenSent
*Dec 4 01:29:45.366: BGP: 10.67.1.1 active sending OPEN, version 4, my as: 23456, holdtime 180 seconds, ID A070B01
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active rcv message type 1, length (excl. header) 38
*Dec 4 01:29:45.386: BGP: ses global 10.67.1.1 (0x6AF16050:0) act Receive OPEN
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active rcv OPEN, version 4, holdtime 180 seconds
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active rcv OPEN w/ OPTION parameter len: 28
*Dec 4 01:29:45.386: BGP: 10.67.1.1
R7(config-if)# active rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active OPEN has CAPABILITY code: 1, length 4
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active OPEN has MP_EXT CAP for afi/safi: 1/1
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active OPEN has CAPABILITY code: 128, length 0
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active OPEN has ROUTE-REFRESH capability(old) for all address-families
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active OPEN has CAPABILITY code: 2, length 0
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active OPEN has ROUTE-REFRESH capability(new) for all address-families
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active OPEN has CAPABILITY code: 7
R7(config-if)#0, length 0
*Dec 4 01:29:45.386: BGP: ses global 10.67.1.1 (0x6AF16050:0) act Enhanced Refresh cap received in open message
*Dec 4 01:29:45.386: BGP: 10.67.1.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Dec 4 01:29:45.390: BGP: 10.67.1.1 active OPEN has CAPABILITY code: 65, length 4
*Dec 4 01:29:45.390: BGP: 10.67.1.1 active OPEN has 4-byte ASN CAP for: 65000
*Dec 4 01:29:45.390: BGP: nbr global 10.67.1.1 neighbor does not have IPv4 MDT topology activated
*Dec 4 01:29:45.390: BGP: 10.67.1.1 active rcvd OPEN w/ remote AS 65000, 4-byte remote AS 65000
*Dec 4 01:29:45.390: BGP: 10.67.1.1 active went from OpenSent to OpenConfirm
*Dec 4 01:29:45.390: BGP: 10.67.1.1 active went from OpenConfirm to Established
*Dec 4 01:29:45.390: BGP: ses global 10.67.1.1 (0x6AF16050:1) act Assigned ID
*Dec 4 01:29:45.390: BGP: 10.67.1.1 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 1
*Dec 4 01:29:45.394: BGP: ses global 10.67.1.1 (0x6AF16050:1) Up
*
R7(config-if)#Dec 4 01:29:45.394: %BGP-5-ADJCHANGE: neighbor 10.67.1.1 Up
*Dec 4 01:29:45.402: BGP: ses global 10.67.1.1 (0x6AF16050:1) read request no-op



BGP Session Types

A BGP session refers to an established adjacency between two BGP devices. BGP can form directly connected neighbor adjacencies or adjacencies that are many hops away (multi-hop adjacency). In the case of multi-hop adjacency, the BGP device uses a route in the routing table to form a TCP session with the remote peer. This route may be a static route or dynamically learned from any routing protocol. BGP sessions are always point-to-point between two devices. BGP peering can be configured to create an internal BGP (iBGP) peering or external BGP (eBGP). BGP neighbors are configured manually. Exchange of routes takes place only after the peering session has been established.

Internal BGP (iBGP)

iBGP sessions are established within an AS. iBGP sessions are established with another BGP device that is in the same autonomous system or participates in the same BGP confederation. iBGP is characterized by the following features:

• iBGP prefixes are assigned an administrative distance of 200 in the routing table.
• iBGP uses a default TTL of 255 resulting in the possibility for iBGP peers being multiple hops away from each other.
• The AS_PATH is not appended to a prefix when it is shared with an iBGP peer.
• Prefixes learned from an iBGP peer can not be sent to another iBGP peer. This is iBGP's way of preventing the formation of routing loops. This is the iBGP concept of split horizon. In order to prevent the formation of "traffic blackholes", iBGP uses a variety of techniques such as full-mesh topology, route reflection, and confederations which ensure that all iBGP peers receive shared NLRI and eliminates traffic black-holing.
• In iBGP, the next hop address field is left unchanged when advertising a prefix to another iBGP peer if it is an address other than 0.0.0.0.
• The next-hop address must exist in the routing table in order for the prefix to be advertised to iBGP peers.
• iBGP peers typically peer via loopbacks: this allows for rerouting around failed paths with IGPs providing alternate paths. Additionally, this is required for some BGP implementations such as in MPLS L3VPNs.

External BGP (eBGP)

eBGP sessions are established between autonomous systems. eBGP peerings are the core of component of BGP on the Internet.

eBGP has the following features:

• eBGP prefixes are assigned an administrative distance of 20 in the routing table. The lower AD of eBGP compared to iBGP is an indication that BGP is designed to share prefixes between autonomous systems rather than within autonomous systems.
• The advertising BGP peer prepends its autonomous system number to the AS_PATH path attribute. The receiving router first confirms that the AS_PATH does not contain the local autonomous system number and processes the packet. If the local autonomous system number is contained in the AS_PATH, then the packet is discarded to prevent a routing loop.
• External peers are directly connected (by default): eBGP places a Time-to-live (TTL) of one (1) to avoid the use of any other routing path. However, if any one of the directly connected interfaces fail, the eBGP session may get torn down. This can be modified using the BGP commands neighbor <ip-address> ebgp-multihop <1 - 255> or neighbor <ip-address> ttl-security hops <1 - 255>. The TTL-security feature can be configured to enforce the requirement for the neighbors to be directly adjacent. TTL-security needs to be configured on both BGP peers. TTL-Security is covered in depth in the section BGP Security
• eBGP peering can use a loopback interface as the outgoing interface. In such a configuration, the requirement for directly connected peers can be disabled using the BGP command neighbor <ip-address> disable-connected-check.
• The next-hop field is changed for prefixes received from an eBGP peer. The local router modifies the next hop to the IP address of its exit interface when it advertises to an iBGP peer a prefix received from an eBGP peer.

BGP Session Configuration

BGP peer configuration can be classified as session commands and policy commands. Session commands are global in scope i.e., apply to all address families (IPv4, IPv6, VPNv6, IPv4 multicast) or per address family. The policy commands are always per address family.

BGP configuration involves defining session parameters, address-family initialization and activation of the neighbor under the appropriate address family. By default, BGP on Cisco devices has IPv4 address family enabled. The default IPv4 address family can be disabled using the BGP router command: no bgp default ipv4-unicast. If the default IPv4 address-family is disabled, the following three-phase BGP configuration must be completed:

Phase 1: BGP session parameters

The neighbor IP address and autonomous system number is configured. Other parameters configured include: authentication, keepalive timers, source and destination IP address settings. The configuration of BGP session involves the following commands:

Step 1: initialize the BGP process using the privileged mode command router bgp <1-4294967295> (in ASN decimal format) or router bgp <1.1-XX.YY> (in ASN asdot format):

R8(config)#router bgp 1.3

The configured ASN is 1.3.

Step 2: define the BGP router ID statically with the command bgp router-id <router-id>:

R8(config-router)#bgp router-id 8.8.8.8

Like IGPs, IOS automatically assigns the RID using the following criteria:

1. Statically defined router-id.
2. Highest IP address configured on any loopback interface.
3. Highest IP address of any physical interface.

It is recommended that the BGP router ID be statically configured. This ensures that it does not change even when the interface IP addresses for the loopback and physical interfaces are modified.

Step 3: define the BGP neighbor's IP address and autonomous system number with the command: neighbor <ip-address> remote-as <asn>. You need to know the outbound interface IP address of the remote router. For iBGP peers, the ASN will be same as that of the local BGP device. For eBGP peers, the ASN values will be different.

R8(config-router)#neighbor 7.7.7.7 remote-as 65536

Step 4 (Optional): define the BGP session's password with MD5 authentication using the command: neighbor <ip-address> password <password>

R8(config-router)#neighbor 7.7.7.7 password cisco123

Failure to configure a password does not affect the operational state of BGP. However, it provides a layer of security to BGP operations.

Step 5 (Optional): modify the BGP session timers with the command: neighbor <ip-address> timers <keepalive> <holdtime> <[minimum-holdtime]>. A neighbor relationship does not form if the configured holdtime on one neighbor is lower than the minimum-holdtime on another neighbor.

R8(config-router)#neighbor 7.7.7.7 timers 60 180 120

The above command configures a keepalive timer value of 60 seconds, holdtime of 180 seconds and minimum holdtime of 120 seconds.

Step 6 (if using the IP address of a loopback interface): specify the source interface of the BGP session. It is important to ensure that the remote BGP peer has reachability to the IP address of the loopback interface. It may be required for this IP address to be advertised by the IGP or added to a static route. By default, the IP address of the exit interface (as determined by the RIB) is used as the source IP address of a BGP packet. However, during configuration, it is possible to use an IP address of an interface that is not the exit interface. In such scenarios, usually a loopback interface is used. This guards against losing a BGP peering due to link failure. This is important in highly redundant networks with more than one path to a peer. The interface to be used for a BGP session can be specified using the command: neighbor <ip-address> update-source <interface-id>.

R8(config-router)#neighbor 7.7.7.7 update-source loopback 0

If the update-source command is issued, then, for eBGP sessions, the TTL must be increased from one (1) to a higher value (two in this case). eBGP sessions use a TTL of one for BGP packets to ensure that the peers are directly connected and do not use a different path to form their peering. This default behaviour prevents multihop eBGP sessions that could be necessary when providers would like to peer via loopback addresses. This requires changing the TTL on BGP packets between eBGP peers. To change the TTL for multihop eBGP neighbor <ip-address> ebgp-multihop <hop-count>.

R8(config-router)#neighbor 7.7.7.7 ebgp-multihop 2

Note: eBGP sessions using loopback interfaces can be enabled using the keyword disable-connected-check of the neighbor command. This keyword disables the default eBGP checks for a TTL of one and the requirement for the eBGP neighbors to be in the same subnet. You can use this keyword to replace the keyword of ebgp-multihop. However, this still requires the eBGP neighbors to be directly connected. eBGP multihop sessions cannot be enabled using this command. The ebgp-multihop keyword will be required in such a scenario.

Verification of Neighbor State

The neighbor state of BGP peers can be verified using the command show ip bgp summary or show bgp ipv4 unicast summary.

Phase 2: Address family initialization and Prefix Advertisement

Network advertisement and route summarization are implemented under the address family mode.

Step 7: Initialize the address family: using the BGP command address-family <afi> <safi>. In this configuration, we initialize IPv4 unicast address family.

R8(config-router)#address-family ipv4 unicast

Step 8: Advertise the network layer reachability information (NLRI) i.e. prefixes and their attributes.

BGP uses the UPDATE message to advertise and withdraw NLRI. NLRI can be originated in multiple ways:

1. Network statement: The syntax of the network statement is network <ip-address> mask <netmask>.
   • Prefixes originated using the network statement have an ORIGIN path attribute of IGP with the status symbol "i" in the BGP table.
   • Prefixes have to exist in the routing table before they are advertised. They do not have to be connected or static routes; they can be sourced from IGPs.
   • When advertising a prefix, the prefix to be advertised must match the prefix in the routing table.
   • Without the mask keyword, the BGP uses a classful mask instead. If subnets or supernets are to be advertised, then the mask keyword may be required.
   • BGP sets the weight path attribute to 32768 for these prefixes.
   R8(config-router-af)#network 10.8.10.0 mask 255.255.255.0
R8(config-router-af)#network 10.8.11.0 mask 255.255.255.0


2. Redistribution: To redistribute IGP prefixes into BGP, use the BGP command redistribute <igp-protocol> <process | asn>.
   • Prefixes originated through redistribution have the value of INCOMPLETE(?) for the ORIGIN path attribute.
   • Originates classful summary prefixes if auto-summary is enabled.
   • The IGP metric of the prefix is automatically copied to the BGP MED path attribute.
   • The weight path attribute has its value set to 32768.
   • When redistributing OSPF routes into BGP, by default, OSPF external routes are not redistributed.
   • To include OSPF external routes add the match ospf external keywords to the redistribute command; redistribute ospf [pid] match internal external

   BGP Redistribute Internal: Redistribution of BGP NLRI into IGP

   Redistribution of BGP NLRI into IGP is not recommended as the number of prefixes being redistributed may overwhelm the IGP affecting its optimal operation. However, if there is an unavoidable requirement to redistribute BGP prefixes into an IGP, take note of the following:

   • By default, only external BGP routes are redistributed into the IGP.
   • bgp redistribute internal command lets internal BGP routes to be redistributed into IGP. This increases the possibility of introducing routing loops if not carefully planned and implemented.
3. aggregate-address statement: This method of NLRI origination aggregates prefixes into a summary. It requires at least one component subnet to be present in the BGP table before the aggregate prefix is advertised. Prefix aggregation is covered in depth in the section: Summarization.
4. bgp inject-map statement: Advertises a component prefix of aggregate route. The component prefix does not have to exist in the routing table. It is generated by applying the inject-map. It originates subnets(s) from a summary route for purpose of longest match traffic engineering. This is the opposite of aggregation.

   Prefix origination using inject-map command can be configured using the following command: bgp inject-map <inject-map> exist-map <exist-map> [copy-attributes] .

   • The inject-map parameter is a route-map that specifies the subnet to be advertised. This component prefix can be specified in a prefix-list which is then referenced by the route-map.
   • The exist-map parameter is a route-map that specifies the aggregate route to match. If the route in the exist-map is matched, the route in the inject-map will be advertised.
   In the route-map referenced by the exist-map keyword, two matches need to be done;
   1. Match the prefix using the match ip address command.
   2. Match the source using a match ip route-source command.

   Example Configuration

   Given an aggregate prefix 150.1.0.0/16 received from a peer 150.1.28.5, we want to advertise a component route 150.1.1.0/24.

   • Step 1: Match the aggregate in a prefix-list: ip prefix-list AGGREGATE permit 150.1.0.0/16.
   • Step 2: Match the prefix that we want to originate: ip prefix-list R1_LOOPBACK permit 150.1.1.0/24.
   • Step 3: Match the route source i.e. prefix best path: ip prefix-list ROUTE_SOURCE 150.1.28.5/32 .
   • Step 4: Configure route-map that is the inject-map:
     route-map INJECT_MAP
  set ip address prefix-list R1_LOOPBACK
route-map EXIST_MAP
  match ip address prefix-list AGGREGATE
  match ip route-source prefix-list ROUTE_SOURCE.
   • Step 5: Apply the inject-map and exist-map;
     router bgp 801.1
  bgp inject-map INJECT_MAP exist-map EXIST_MAP
.

   Verify configuration with the command show ip bgp injected-paths.

5. BGP Conditional Advertisement: provides additional control of route advertisement, depending on the existence of other prefixes in the BGP table. Typically, the BGP conditional advertisement feature is used to track failure of a transit link e.g. advertise to backup provider, only if primary provider is down. It uses the following command neighbor advertise-map <map1> [non-exist-map <map2> | exist-map <map2>].
   • Advertise prefix matched in advertise-map if prefix matched in non-exist-map does not exist or prefix matched in exist-map does exist.
   • The non-exist-map and the advertise-map keywords of the neighbor advertise-map command are used to track routes by the route prefix.

Phase 3: Activation of the BGP Peer

A BGP peer must be activated in order for BGP to initiate a session with that peer. The router's IP address is added to the neighbor table and BGP attempts to establish a BGP session or accepts a BGP session initiated from the peer. This step is required only if the BGP command no bgp default ipv4-unicast has been configured to disable the default IPv4 address family.

Step 9: Activate the neighbor: using the command neighbor <ip-address> activate.

R8(config-router-af)#neighbor 7.7.7.7 activate

If the default BGP IPv4 address family is enabled, then activation of a neighbor is done automatically.

BGP Session Resets

If a policy configuration change is made to BGP, such as a change in routing policy, after a BGP device forms a peering with another BGP device the BGP session may need to be reset for the changes to take effect. BGP supports two methods of cleaning a session; hard reset and soft reset:

• Hard reset: tears down a BGP session and removes prefixes received from a peer. When a hard reset is initiated, BGP ends the session by closing the TCP connection to the BGP peer. It does this by sending a TCP message with the connection finish flag set (FIN) and a TCP handshake to end the connection is initiated. No ROUTE-REFRESH messages are exchanged with a hard reset.

  A hard reset is implemented using the command clear bgp ipv4 unicast <[ip-address|*]>. The IP address is for the peer whose BGP session is to be reset. The "*" refers to all BGP peers.

  • clear bgp ipv4 unicast <*>:
    • The BGP sessions with all peers are reset. The BGP session transitions from Established to Idle and the re-establishment of peering starts again.
    • The entire BGP table is flushed.
    • All NLRI is learned again.
    • Hard reset can be a resource intensive process i.e. bandwidth, time, memory, CPU.
  • clear bgp ipv4 unicast <ip-address>
    • Resets the BGP session with the BGP peer idenfied by the IP address.
    • High impact on network but less severe than clear bgp ipv4 unicast <*>.
  A hard reset is not recommended in production networks as it clears the entire Loc-RIB table which may be massive; additionally, it may have a cascading effect.

• Soft Reset: invalidates the cache and requests full advertisement without tearing down the TCP connection and BGP session. clear bgp ipv4 unicast <ip-address> soft. This option is highly recommended when changing routing policy.

BGP Route Refresh Capability

Route refresh capability between BGP peers is negotiated through OPEN messages exchanged during the initial stages of formation of a BGP session. The TCP connnection between the peers is not torn down. A BGP router can request a peer to send an update without having to hard reset the session. Route refresh capacity does not consume memory like soft reconfigure inbound.

When a BGP policy changes, the BGP table must be updated and the neighbors notified accordingly. If the BGP session supports route refresh capability, the peer re-advertises (refreshes) the prefixes to the requesting router allowing for the inbound policy to process using the new policy changes. Route refresh capability is made possible by the availability of the route refresh message type. The route refresh capability is negotiated for each address family when the session is established. Performing a soft refresh on sessions that support route refresh capability actually initiates a route refresh. Soft resets can be performed for a specific address family with the command: clear bgp <afi> <safi> <ip-address> soft [in | out]

Soft Reconfiguration

We can configure a neighbor to support soft reconfiguration for inbound updates. This enables a device to save prefix information received from a peer unmodified in the Adj-RIB-in table. For outbound updates, soft reconfiguration is supported by default. Soft reconfiguration can be enabled for a neighbor using the BGP address family command neighbor <ip-address> soft-reconfiguration inbound. For Outbound soft reconfiguration, no neighbor manipulation in configuration is required as the command clear ip bgp <ip-address> soft out is sufficient. The soft out option has no effect if the inbound policy is modified. This method of soft reset can be used when both BGP peers do not support automatic route refresh capability. On the downside, soft-reconfiguration is memory intensive because a separate cache is maintained to store prefixes before routing policy changes are applied to them.

Sessions can be cleared with all neighbors by using an asterisk in lieu of the peer's IP address. ROUTE-REFRESH messages are sent by the device that initiated the route refresh to all BGP peers if an asterisk is used or to the BGP peer whose IP address has been used in the refresh command in lieu of the asterisk.

Soft reconfiguration is used in environments where route refresh capability is not supported.

BGP Security

BGP supports an authentication mechanism using Message Digest 5(MD5). When enabled, any TCP packets exchanged between the BGP peers are verified and received if the authentication is successful. For peer authentication to be successful, the BGP peers need to be configured with the same password. If authentication fails, the BGP devices will not form a peer relationship.

Peer Authentication

A BGP session can be configured to enable authentication of BGP messages received from a BGP peer. The keyword password is appended to the neighbor statement or to a peer-session template.

R8(config-router)#neighbor 7.7.7.7 password cisco123

BGP peer authentication using the keyword password implements MD5 authentication. BGP uses the TCP header to carry the MD5 digest of the password between BGP peers. The following snippet shows a Wireshark packet capture of a BGP packet confirming MD5 authentication in effect.

Transmission Control Protocol, Src Port: 51113, Dst Port: 179, Seq: 1, Ack: 1, Len: 57
    Source Port: 51113
    Destination Port: 179
    [Stream index: 1]
    [Conversation completeness: Incomplete, DATA (15)]
    [TCP Segment Len: 57]
    Sequence Number: 1 (relative sequence number)
    Sequence Number (raw): 1231047391
    [Next Sequence Number: 58 (relative sequence number)]
    Acknowledgment Number: 1 (relative ack number)
    Acknowledgment number (raw): 1851241589
    1010 .... = Header Length: 40 bytes (10)
    Flags: 0x018 (PSH, ACK)
    Window: 16384
    [Calculated window size: 16384]
    [Window size scaling factor: -2 (no window scaling used)]
    Checksum: 0x5b52 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    Options: (20 bytes), TCP MD5 signature, End of Option List (EOL)
        TCP Option - TCP MD5 signature
            Kind: MD5 Signature Option (19)
            Length: 18
            MD5 digest: 2fa08d3790fa83f7be58d0071d66eb4d
        TCP Option - End of Option List (EOL)
            Kind: End of Option List (0)
    [Timestamps]
    [SEQ/ACK analysis]
    TCP payload (57 bytes)


The configured password using password keyword of the neighbor command will display the password in clear text when viewing the router configuration. It is important to obfuscate this password in the configuration by configuring the service password encryption command.

TTL Security Check for BGP Neighbor Sessions

When implemented for BGP, the TTL security check introduces a lightweight security mechanism to protect eBGP neighbor sessions from CPU utilization-based attacks. These types of attacks are typically brute force Denial of Service (DoS) attacks that attempt to degrade the network by flooding it with IP packets that contain forged source and destination IP addresses.

The TTL security feature is configured with the neighbor <ip-address> ttl-security hops <1-254> command in BGP configuration mode or BGP address family configuration mode. The hop count argument is used to configure the maximum number of hops that separate the two peers. The TTL security check protects the eBGP neighbor session by comparing the value in the TTL field of received IP packets against a hop count that is configured locally for each eBGP neighbor session. If the value in the TTL field of the incoming IP packet is greater than or equal to the locally configured value, the IP packet is accepted and processed normally. If the TTL value in the IP packet is less than the locally configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. This is the designed behavior; a response to a forged packet is unnecessary. Although it is possible to forge the TTL field in an IP packet header, accurately forging the TTL count to match the TTL count from a trusted peer is impossible unless the trusted peer has been compromised.

When the command ttl-security hops is configured, BGP messages have their TTL values set to 255.

TTL security check supports both directly connected neighbor sessions and multihop eBGP neighbor sessions. The BGP neighbor session is not affected by incoming packets that contain invalid TTL values. The BGP neighbor session will remain open, and the router will silently discard the invalid packet. The BGP session, however, eventually are closed after the expiry of the hold timer value due to the discarding of keepalive messages. expires. This results in a NOTIFICATION message being sent with the error code of Hold Timer Expired.

Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: Hold Timer Expired (4)
    Minor error Code (Hold Timer Expired): 0


The BGP state cycles between Idle and Active as BGP keeps attempting to open a TCP connection with the remote peer.

R8(config-router)#
*Dec 4 02:15:15.230: BGP: topo global:IPv4 Unicast:base Scanning routing tables
*Dec 4 02:15:15.234: BGP: topo global:IPv4 Multicast:base Scanning routing tables
R8(config-router)#
*Dec 4 02:16:11.062: BGP: 7.7.7.7 connection timed out 180084ms (last update) 180000ms (hold time)
*Dec 4 02:16:11.062: BGP: 7.7.7.7 went from Established to Closing
*Dec 4 02:16:11.066: %BGP-5-ADJCHANGE: neighbor 7.7.7.7 Down BGP Notification sent
*Dec 4 02:16:11.066: %BGP-3-NOTIFICATION: sent to neighbor 7.7.7.7 4/0 (hold time expired) 0 bytes
*Dec 4 02:16:11.070: BGP: ses global 7.7.7.7 (0x6AFD0EC4:1) Send NOTIFICATION 4/0 (hold time expired) 0 bytes
*Dec 4 02:16:11.078: BGP: 7.7.7.7 local error close after sending NOTIFICATION
*Dec 4 02:16:11.086: BGP: nbr_topo global 7.7.7.7 IPv4 Unicast:base (0x6AFD0EC4:1) NSF delete stale NSF not active
*Dec 4 02:16:11.086: BGP: nbr_topo global 7.7.7.7 IPv4 Unicast:base (0x6AFD0EC4:1) NSF no stale paths state is NSF not active
*Dec 4 02:16:11.090: BGP: nbr_topo global 7.7.7.7 IPv4 Unicast:base (0x6AFD0EC4:1) Resetting ALL counters.
*Dec 4 02:16:11.094: BGP: 7.7.7.7 closing
*Dec 4 02:16:11.098: BGP: ses global 7.7.7.7 (0
R8(config-router)#x6AFD0EC4:1) Session close and reset neighbor 7.7.7.7 topostate
*Dec 4 02:16:11.098: BGP: nbr_topo global 7.7.7.7 IPv4 Unicast:base (0x6AFD0EC4:1) Resetting ALL counters.
*Dec 4 02:16:11.102: BGP: 7.7.7.7 went from Closing to Idle
*Dec 4 02:16:11.102: %BGP_SESSION-5-ADJCHANGE: neighbor 7.7.7.7 IPv4 Unicast topology base removed from session BGP Notification sent*Dec 4 02:16:11.106: BGP: ses global 7.7.7.7 (0x6AFD0EC4:1) Removed topology IPv4 Unicast:base
*Dec 4 02:16:11.110: BGP: ses global 7.7.7.7 (0x6AFD0EC4:1) Removed last topology
*Dec 4 02:16:11.110: BGP: nbr global 7.7.7.7 Open active delayed 13312ms (35000ms max, 60% jitter)
*Dec 4 02:16:11.114: BGP: nbr global 7.7.7.7 Active open failed - open timer running
R8(config-router)#
*Dec 4 02:16:15.310: BGP: topo global:IPv4 Unicast:base Scanning routing tables
*Dec 4 02:16:15.314: BGP: topo global:IPv4 Multicast:base Scanning routing tables
R8(config-router)#
*Dec 4 02:16:24.398: BGP: 7.7.7.7 active went from Idle to Active
*Dec 4 02:16:24.402: BGP: 7.7.7.7 open active, local address 8.8.8.8
R8(config-router)#
*Dec 4 02:16:29.414: BGP: 7.7.7.7 open failed: Connection timed out; remote host not responding
*Dec 4 02:16:29.414: BGP: 7.7.7.7 Active open failed - tcb is not available, open active delayed 8192ms (35000ms max, 60% jitter)
*Dec 4 02:16:29.418: BGP: ses global 7.7.7.7 (0x692D6218:0) act Reset (Active open failed).
*Dec 4 02:16:29.426: BGP: 7.7.7.7 active went from Active to Idle
*Dec 4 02:16:29.426: BGP: nbr global 7.7.7.7 Active open failed - open timer running
*Dec 4 02:16:29.430: BGP: nbr global 7.7.7.7 Active open failed - open timer running
R8(config-router)#
*Dec 4 02:16:36.690: BGP: 7.7.7.7 active went from Idle to Active
*Dec 4 02:16:36.690: BGP: 7.7.7.7 open active, local address 8.8.8.8
R8(config-router)#
*Dec 4 02:16:41.702: BGP: 7.7.7.7 open failed: Connection timed out; remote host not responding
*Dec 4 02:16:41.702: BGP: 7.7.7.7 Active open failed - tcb is not available, open active delayed 9216ms (35000ms max, 60% jitter)
*Dec 4 02:16:41.706: BGP: ses global 7.7.7.7 (0x692D6218:0) act Reset (Active open failed).
*Dec 4 02:16:41.714: BGP: 7.7.7.7 active went from Active to Idle
*Dec 4 02:16:41.714: BGP: nbr global 7.7.7.7 Active open failed - open timer running
*Dec 4 02:16:41.718: BGP: nbr global 7.7.7.7 Active open failed - open timer running
R8(config-router)#
*Dec 4 02:16:50.002: BGP: 7.7.7.7 active went from Idle to Active
*Dec 4 02:16:50.002: BGP: 7.7.7.7 open active, local address 8.8.8.8
R8(config-router)#

Enabling this feature secures the eBGP session in the incoming direction only and has no effect on outgoing IP packets to the remote router.

When this feature is configured for a multihop neighbor session, the neighbor ebgp-multihop router configuration command cannot be configured and is not needed to establish the neighbor session. These commands are mutually exclusive. If you attempt to configure both commands for the same peering session, an error message will be displayed in the console.

R8(config-router)#neighbor 7.7.7.7 ttl-security hops 2
Remove ebgp-multihop before configuring ttl-security
R8(config-router)#


To configure this feature for an existing multihop session, you must first disable the existing neighbor session with the no neighbor ebgp-multihop command. The multihop neighbor session will be restored when you enable this feature with the neighbor ttl-security command.

R8(config-router)#no neighbor 7.7.7.7 ebgp-multihop 2
R8(config-router)#neighbor 7.7.7.7 ttl-security hops 2


To further leverage the security features of TTL-security, the value of the ttl-security hops can be set to the 254. This value should be the same on both eBGP peers. The packets received by each of the eBGP peers will have a value of 254. No unauthorised external device will be able to send BGP messages with such TTL values. A TTL of 254 ensures that both eBGP neighbors are directly connected.

First ASN in path must be neighbor's ASN

The BGP command bgp enforce-first-as can be configured to enforce additional security. This command ensures that the ASN of the eBGP peer is the first in the AS_PATH prefix attribute of the received prefix from the eBGP peer. If this is not the case, then the received prefixes from this eBGP peer are droppped. This helps provide an added layer of security to BGP.

Verification of BGP

The following commands are helpful for understanding the operational state of BGP

Verifying BGP Session and Neighbors

show tcp brief

Displays the status of the TCP connections.

R6#show tcp brief
TCB       Local Address               Foreign Address             (state)
691E1F44  10.67.1.1.179              10.67.1.2.15459             ESTAB
6B23F194  6.6.6.6.12030              5.5.5.5.179                 ESTAB
67FDB564  6.6.6.6.55235              4.4.4.4.179                 ESTAB


From the output, the device's TCP connections indicate that the local device is a BGP client to devices 5.5.5.5 and 4.4.4.4. The local device acts as a BGP server to the remote BGP peer 10.67.1.2.

BGP sessions are server/client relationships with one peer acting as a server and another as the client. The BGP peer acting as the server opens TCP port 179 and listens for connections from BGP clients on this port. The client initiates a connection to the server on port 179 using an ephemeral port as the source TCP port. The BGP peer acting as the server will accept connections from clients with preconfigured IP address to connect to it. If a client's IP address has not been preconfigured on the server, it will drop the TCP connection attempt from the client with a TCP RST reply message.

BGP peers use the TCP three-way handshake to create a BGP session. If both peers try to create a TCP session at the same time, when initiating the TCP three-way handshake, both peers send a TCP SYN packet sourced from an ephemeral port and destined to port 179. If the TCP SYN packet is sent at the same time by both peers, both BGP peers respond with an ACK to the request on port 179, resulting in two BGP sessions being created. This condition is called a BGP connection collision. BGP handles this condition by making the BGP peer with the higher BGP RID to become the server and maintaining only one TCP session between the two BGP peers.

To avoid BGP connection collisions, the server and client roles can be predetermined right from the start by using the neighbor <ip-address> transport connection-mode [active | passive] command where active means client, passive means server.

Client connections can be viewed using the command show control-plane host open-ports; this command may be version specific. The output of this command is shown below:

R1#show control-plane host open-ports
Active internet connections (servers and established)
Prot               Local Address             Foreign Address                  Service    State
 tcp                        *:23                         *:0                   Telnet   LISTEN
 tcp                     *:14272            41.250.250.1:179         IOS host service ESTABLIS
 tcp                       *:179          10.255.255.3:50138                      BGP ESTABLIS
 tcp                     *:56801            10.255.255.5:179         IOS host service ESTABLIS
 tcp                       *:179          10.255.255.4:33629                      BGP ESTABLIS
 tcp                       *:179                         *:0                      BGP   LISTEN
 tcp                       *:179                         *:0                      BGP   LISTEN
 tcp                       *:179                         *:0                      BGP   LISTEN
 tcp                       *:179                         *:0                      BGP   LISTEN
 tcp                       *:179                         *:0                      BGP   LISTEN
 tcp                       *:179                         *:0                      BGP   LISTEN
 tcp                     *:40321            10.255.255.6:179         IOS host service ESTABLIS
 tcp                       *:179          10.255.255.2:52089                      BGP ESTABLIS
R1#

It is important to note that the client's packet is sourced from the outgoing interface in the routing table. However, this can be modified using the BGP command update-source for each BGP neighbor. i.e. neighbor 10.255.255.2 update-source Loopback255.

show bgp ipv4 unicast summary

Summary of BGP neighbor status. The following information can be learned from the output of this command:

• Number of prefixes learned from each neighbor,
• BGP peers,
• Duration of the BGP session with the remote peer,
• Count of messsages sent and received from each peer,
• Count of messages in the input and output buffers,
• Autonomous system number of the peers.

R6#show bgp ipv4 unicast summary
BGP router identifier 10.6.10.1, local AS number 65000
BGP table version is 20, main routing table version 20
19 network entries using 2812 bytes of memory
19 path entries using 1216 bytes of memory
4/4 BGP path/bestpath attribute entries using 544 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 4620 total bytes of memory
BGP activity 19/0 prefixes, 19/0 paths, scan interval 60 secs

Neighbor         V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4          4        65000     219     303       20    0    0 04:22:56        4
5.5.5.5          4        65000      75      78       20    0    0 01:03:34        8
10.67.1.2        4        65536     241     301       20    0    0 04:28:49        3
R6#


Field	Description
Neighbor:	IP address of the BGP peer. This address is the same that was configured when configuring the peering using the neighbor <ip-address> remote-as <asn> command.
V	BGP version used by the BGP peer
AS	Autonomous system number of the BGP peer
MsgRcvd	Count of messages received from the BGP peer
MsgSent	Count of messages sent to the BGP peer
TblVer	Last version of the BGP database sent to the peer
InQ	Number of messages queued to be processed from peer
OutQ	Number of messages queued to be sent to the peer
Up/Down	Length of time the BGP session is established or the current status if the session is not in an established state
State/PfxRcd	Current state of the BGP peer or the number of prefixes received from the peer. If there is a number in this column, it indicates that a BGP neighbor relationship has been successfully formed. If the values are 'Idle' or 'Active', then there is a problem in the formation of the neighbor relationship: this may usually mean that the local BGP device or remote BGP peer does not have a route to the neighbor.

show bgp ipv4 unicast neighbors <ip-address>

Displays detailed information on:

• the BGP process
• prefixes received from neighbors and transmitted to neighbors
• neighbor state and capabilities

Additional keywords to the above command display additional information for each neighbor:

Command	Description
show bgp ipv4 unicast neighbors <ip-address> policy detail	Displays any policies configurations for the neighbor such as route-maps
show bgp ipv4 unicast neighbors <ip-address> advertised-routes	Displays prefixes advertised to the specified neighbor.

R6#show bgp ipv4 unicast neighbor 10.67.1.2
BGP neighbor is 10.67.1.2, remote AS 65536, external link
  BGP version 4, remote router ID 10.7.11.1
  BGP state = Established, up for 00:11:35
  Last read 00:00:36, last write 00:00:04, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability:
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                2          4
    Keepalives:            13         11
    Route Refresh:          0          0
    Total:                 16         16
  Default minimum time between advertisement runs is 30 seconds
  
 For address family: IPv4 Unicast
  Session: 10.67.1.2
  BGP table version 8, neighbor version 8/0
  Output queue size : 0
  Index 1, Advertise bit 0
  1 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               4          3 (Consumes 192 bytes)
    Prefixes Total:                 4          3
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          3
    Used as multipath:            n/a          0
    
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    AS_PATH loop:                       n/a          4
    Bestpath from this peer:              3        n/a
    Total:                                3          4
  Number of NLRIs in the update sent: max 4, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                     Sent       Rcvd
        Refresh activity:            ----       ----
          Refresh Start-of-RIB          0          0
          Refresh End-of-RIB            0          0
  
  Address tracking is enabled, the RIB does have a route to 10.67.1.2
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.67.1.1, Local port: 179
Foreign host: 10.67.1.2, Foreign port: 61108
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0xBC8F0):
Timer          Starts    Wakeups            Next
Retrans            15          0             0x0
TimeWait            0          0             0x0
AckHold            15         14             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss:  255206248  snduna:  255206643  sndnxt:  255206643
irs: 1359021486  rcvnxt: 1359021949

sndwnd:  15990  scale:      0  maxrcvwnd:  16384
rcvwnd:  15922  scale:      0  delrcvwnd:    462

SRTT: 865 ms, RTTO: 1866 ms, RTV: 1001 ms, KRTT: 0 ms
minRTT: 48 ms, maxRTT: 1000 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 31 (out of order: 0), with data: 15, total data bytes: 462
Sent: 31 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 15, total data bytes: 394

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x6AAD4CA4  FREE
R6#


For an iBGP peer that is a member of a peer-group:

R3#show bgp ipv4 unicast neighbor 6.6.6.6
BGP neighbor is 6.6.6.6,  remote AS 65000, internal link
 Member of peer-group AS65000 for session parameters
  BGP version 4, remote router ID 10.6.15.1
  BGP state = Established, up for 02:32:18
  Last read 00:00:30, last write 00:00:00, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability:
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:               15          6
    Keepalives:           168        165
    Route Refresh:          0          0
    Total:                191        172
  Default minimum time between advertisement runs is 0 seconds
  
 For address family: IPv4 Unicast
  Session: 6.6.6.6
  BGP table version 95, neighbor version 95/0
  Output queue size : 0
  Index 4, Advertise bit 2
  4 update-group member
  AS65000 peer-group member
  NEXT_HOP is always this router for eBGP paths
  Outbound path policy configured
  Route map for outgoing advertisements is RM_LOCALPREF
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               1         10 (Consumes 640 bytes)
    Prefixes Total:                 8         10
    Implicit Withdraw:              7          0
    Explicit Withdraw:             58          0
    Used as bestpath:             n/a         10
    Used as multipath:            n/a          0
  
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Invalid Path:                         34        n/a
    Other Policies:                      348        n/a
    Total:                               382          0
  Number of NLRIs in the update sent: max 36, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: 02:16:15
  Last Sent Refresh End-of-rib: 02:16:15
  Refresh-Out took 0 seconds
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          4          0
          Refresh End-of-RIB            3          0
        
  Address tracking is enabled, the RIB does have a route to 6.6.6.6
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 3.3.3.3, Local port: 40007
Foreign host: 6.6.6.6, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x9EFA4C):
Timer          Starts    Wakeups            Next
Retrans           176           0             0x0
TimeWait            0           0             0x0
AckHold           170         159             0x0
SendWnd             0           0             0x0
KeepAlive           0           0             0x0
GiveUp              0           0             0x0
PmtuAger         8292        8291        0x9EFA83
DeadWait            0           0             0x0
Linger              0           0             0x0
ProcessQ            0           0             0x0

iss: 1883036522  snduna: 1883040887  sndnxt: 1883040887
irs: 3546645074  rcvnxt: 3546648594

sndwnd:  14978  scale:      0  maxrcvwnd:  16384
rcvwnd:  15795  scale:      0  delrcvwnd:    589

SRTT: 1000 ms, RTTO: 1003 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 16 ms, maxRTT: 1000 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 348 (out of order: 0), with data: 171, total data bytes: 3519
Sent: 343 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 178, total data bytes: 4364

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x6B1E7368  FREE
R3#


Verifying BGP Prefixes

show bgp ipv4 unicast

Displays a brief summary of the BGP process, neighbor state and prefixes received or transmitted.

R9#show bgp ipv4 unicast
BGP table version is 66, local router ID is 10.9.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *   2.2.2.2/32       3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 r   3.3.3.3/32       1.1.1.1                                0 65000 i
 r>                   3.3.3.3                  0             0 65000 i
 *>  6.6.6.6/32       10.10.10.1                             0 65538 65539 65536 65000 i
 *>  9.9.9.9/32       0.0.0.0                  0         32768 i
 *   10.1.10.0/24     1.1.1.1                  0             0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.1.11.0/24     1.1.1.1                  0             0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.1.12.0/24     1.1.1.1                  0             0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.1.13.0/24     1.1.1.1                  0             0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.8.0/24      3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *   10.2.9.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.10.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.11.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.12.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.13.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.14.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.15.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.2.16.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *   10.3.5.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                  0             0 65000 i
 *   10.3.6.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                  0             0 65000 i
 *   10.3.7.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                  0             0 65000 i
 *   10.3.8.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                  0             0 65000 i
 *   10.3.9.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                  0             0 65000 i
 *   10.3.10.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                  0             0 65000 i
 *>  10.4.10.0/24     10.10.10.1                             0 65538 65539 65536 65000 i
 *>  10.4.11.0/24     10.10.10.1                             0 65538 65539 65536 65000 i
 *>  10.4.12.0/24     10.10.10.1                             0 65538 65539 65536 65000 i
 *>  10.4.13.0/24     10.10.10.1                             0 65538 65539 65536 65000 i
 *>  10.5.1.0/24      3.3.3.3                                0 65000 i
 *>  10.5.2.0/24      3.3.3.3                                0 65000 i
 *>  10.5.10.0/24     3.3.3.3                                0 65000 i
 *>  10.5.11.0/24     3.3.3.3                                0 65000 i
 *>  10.5.12.0/24     3.3.3.3                                0 65000 i
 *>  10.5.13.0/24     3.3.3.3                                0 65000 i
 *>  10.5.14.0/24     3.3.3.3                                0 65000 i
 *>  10.5.15.0/24     3.3.3.3                                0 65000 i
 *>  10.6.10.0/24     10.10.10.1                             0 65538 65539 65536 65000 i
 *>  10.6.11.0/24     10.10.10.1                             0 65538 65539 65536 65000 i
 *>  10.6.12.0/24     10.10.10.1                             0 65538 65539 65536 65000 i
 *>  10.7.10.0/24     10.10.10.1                             0 65538 65539 65536 i
 *>  10.8.10.0/24     10.10.10.1                             0 65538 65539 i
 *>  10.8.11.0/24     10.10.10.1                             0 65538 65539 i
 *>  10.9.10.0/24     0.0.0.0                  0         32768 i
 *>  10.10.9.0/24     10.10.10.1               0             0 65538 i
 r>  10.10.10.0/24    10.10.10.1               0             0 65538 i
 *>  10.10.11.0/24    10.10.10.1               0             0 65538 i
 *>  10.10.12.0/24    10.10.10.1               0             0 65538 i
 *>  10.10.13.0/24    10.10.10.1               0             0 65538 i
 *   10.12.1.0/30     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *>  10.19.1.0/30     0.0.0.0                  0         32768 i
 *   10.24.1.0/30     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *>  10.39.1.0/30     0.0.0.0                  0         32768 i
 *>  10.67.1.0/30     10.10.10.1                             0 65538 65539 65536 i
 *>  10.78.1.0/30     10.10.10.1                             0 65538 65539 i
 *>  10.108.1.0/30    10.10.10.1               0             0 65538 i
 *   10.109.1.0/30    10.10.10.1               0             0 65538 i
 *>                   0.0.0.0                  0         32768 i
R9#


Field	Description
Network	A list of prefixes in the BGP table. If multiple NLRI routes exist for the same prefix, only the first prefix is identified and others leave a blank space. Valid NLRI routes are indicated by the *.
Next hop	A well-known mandatory BGP path attribute that defines the IP address for the next hop for that specific NLRI. All locally generated prefixes have a next hop value of 0.0.0.0.
Metric	Multiple exit discriminator (MED), an optional non-transitive path attribute used in the BGP best-path algorithm. For locally generated routes, the metric is 0.
LocPrf	Local preference, a well-known discretionary BGP path attribute used in the BGP best-path algorithm for that specific NLRI. For locally generated prefixes, the LocPrf value is 100 by default.
Weight	The Cisco-defined Weight optional non-transitive path attribute. Locally generated prefixes are assigned a Weight of 32768.
Path and Origin	AS_PATH: a well-known mandatory BGP path attribute used for loop prevention and best path selection. Origin: well-known mandatory path attribute used in best-path selection.

show bgp ipv4 unicast <network-address>

Displays all the paths in the Loc-RIB table for a specific prefix and the BGP path attributes for that prefix.

R9#show bgp ipv4 unicast 10.6.10.0
BGP routing table entry for 10.6.10.0/24, version 9
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 2
  65538 65539 65536 65000
    10.10.10.1 from 10.10.10.1 (10.10.11.1)
      Origin IGP, localpref 100, valid, external, best
R9#


show ip route bgp

Display the routing table showing paths learned from BGP.

R9#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 1.1.1.1, 01:28:09
      6.0.0.0/32 is subnetted, 1 subnets
B        6.6.6.6 [20/0] via 10.10.10.1, 01:28:27
      10.0.0.0/8 is variably subnetted, 61 subnets, 3 masks
B        10.1.10.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.1.11.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.1.12.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.1.13.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.2.8.0/24 [20/0] via 1.1.1.1, 01:37:38
B        10.2.9.0/24 [20/0] via 3.3.3.3, 01:37:09
B        10.2.10.0/24 [20/0] via 3.3.3.3, 01:37:09
B        10.2.11.0/24 [20/0] via 3.3.3.3, 01:37:09
B        10.2.12.0/24 [20/0] via 3.3.3.3, 01:37:09
B        10.2.13.0/24 [20/0] via 3.3.3.3, 01:37:09
B        10.2.14.0/24 [20/0] via 3.3.3.3, 01:36:38
B        10.2.15.0/24 [20/0] via 3.3.3.3, 01:36:38
B        10.2.16.0/24 [20/0] via 3.3.3.3, 01:36:38
B        10.3.5.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.3.6.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.3.7.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.3.8.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.3.9.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.3.10.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.4.10.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.4.11.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.4.12.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.4.13.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.5.1.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.5.2.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.5.10.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.5.11.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.5.12.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.5.13.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.5.14.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.5.15.0/24 [20/0] via 3.3.3.3, 02:01:02
B        10.6.10.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.6.11.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.6.12.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.7.10.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.8.10.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.8.11.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.10.9.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.10.11.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.10.12.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.10.13.0/24 [20/0] via 10.10.10.1, 02:20:35
B        10.12.1.0/30 [20/0] via 3.3.3.3, 01:41:51
B        10.24.1.0/30 [20/0] via 3.3.3.3, 01:41:22
B        10.67.1.0/30 [20/0] via 10.10.10.1, 01:54:07
B        10.78.1.0/30 [20/0] via 10.10.10.1, 01:53:37
B        10.108.1.0/30 [20/0] via 10.10.10.1, 01:56:59
R9#


show ip route <ip-address>

Display the details of a route in the routing table including the source of the route. If it is a BGP-learned route, the AS path hops are included.

R9#show ip route 10.6.10.0 255.255.255.0
Routing entry for 10.6.10.0/24
  Known via "bgp 65512", distance 20, metric 0
  Tag 65538, type external
  Last update from 10.10.10.1 02:49:44 ago
  Routing Descriptor Blocks:
  * 10.10.10.1, from 10.10.10.1, 02:49:44 ago
      Route metric is 0, traffic share count is 1
      AS Hops 4
      Route tag 65538
      MPLS label: none
R9#

BGP Processes

BGP runs various processes simultaneously. These can be viewed by filtering the output of the running processes for BGP; show processes cpu | include BGP. The four major BGP processes include:

1. Scheduler: schedules the various processes used by BGP.
2. Router: processes policy, best path algorithm.
3. I/O: responsible for moving prefixes into the InQ and and out of the OutQ.
4. Scanner: watches for changes such as next hop unreachability and removal of prefixes because of this. It evaluates prefixes as a result of the configuration of the network command. The scanner runs every 60 seconds by default. This can be modified using the BGP command bgp scan-time <5-60>.

Other significant BGP processes include the following (these processes support the operation of the scanner process):

1. BMP Server: for the BGP monitoring protocol for monitoring the BGP neighborships.
2. NHT: next hop tracker process helps the scanner for scanning changes in the reachability of the next hop
3. Event: responds to new network statement, new redistribute statements.
4. Import Scanner: to assist the scanner with labels in MPLS environment.
5. Open: used in establishing a peering with a new BGP peer.

BGP Tables

BGP uses three tables for maintaining the network paths and path attributes for a prefix: Loc-RIB (BGP table), Adj-RIB-in, and Adj-RIB-out tables.

Loc-RIB (BGP Table)

Loc-RIB is used by BGP to present routes to the IP routing table. It contains NLRI for prefixes locally originated or received from other peers. After the NLRI passes validity and next-hop reachability checks, the BGP best path algorithm selects the best NLRI for a specific prefix. Prefixes received from iBGP peers have the label of "i" (the first "i" appearing immediately before the prefix.). Prefixes received from eBGP peers do not have the label "i". It is important to note that a prefix originated in another AS but received from an iBGP peer receives the label "i" as it was received from an iBGP peer.

BGP implements loop prevention in the Loc-RIB table by default; prefixes with the local AS in the AS-Path path attribute will be dropped in the Loc-RIB table unless this default configuration is disabled.

Locally originated network prefixes are installed into the BGP table with the network command, redistribution, inject-map, summarization, conditional-map. The BGP process searches the global RIB for an exact network prefix match. The network prefix can be a connected network, a secondary connected network, or prefix learned from an interior gateway protocol such as OSPF, IS-IS. After verifying that the prefix exists in the global RIB, the prefix is installed into the BGP Loc-RIB table. As the prefix is installed into the Loc-RIB table, the following path attributes are set, depending on the source of the route in the RIB:

• Connected networks:
  1. The next-hop path attribute is set to 0.0.0.0
  2. BGP origin attribute is set to i (for IGP)
  3. BGP weight is set to 32,768.
• Static routes:
  1. The next-hop is set to 0.0.0.0.
  2. The origin is set to IGP.
  3. The local preference is set to 100.
  4. The weight is set to 32,768
• Prefixes learned from a routing protocol:
  1. Next-hop path attribute is set to the next-hop IP address in the RIB.
  2. BGP origin attribute is set to i (for IGP)
  3. BGP weight is set to 32,768
  4. The Local Pref is set to 100.
  5. Multi-exit discriminator (MED) is set to the IGP metric.
  6. Redistributed prefixes: prefixes explicitly redistributed from another routing protocol into BGP;
  1. The origin is set to incomplete with the symbol ?.

The Loc-RIB table can be viewed using the command: show bgp ipv4 unicast. See output and description of this command under the section: Verifying BGP Prefixes.

When receiving prefixes, inbound route policies are processed prior to the route being inserted into the Loc-RIB. After insertion into the Loc-RIB, a next-hop check is performed. Then identification of the best BGP path is performed and prefix is then offered for installation into the RIB. Outbound route policies are performed before prefixes enter Adj-RIB-out and then advertised to peers. Only the best paths are advertised to peers and therefore outbound route policies apply to the best paths.

Parsing the BGP Table using Regexp Queries

The Internet BGP table contains over 940,000 prefixes. When querying this massive BGP table, the use of regular expressions makes it easier to retrieve required information. The BGP table can be parsed with regular expressions using the command show bgp <afi> <safi> regexp <regex-pattern>. These regular expressions can also be used to filter through the prefixes received from the large number of ASNs (4,294,967,295).

Modifier	Description
_ (underscore)	Matches a space
^ (caret)	Indicates the start of a string
$ (dollar)	Indicates the end of a string
[ ] (brackets)	Matches a single character or nesting within a range
- (hyphen)	Indicates a range of numbers in brackets
[^] (caret in brackets)	Excludes the characters listed in brackets
() (parentheses)	Used for nesting search patterns
| (pipe)	<OR> functionality in a query
. (period)	Matches a single character including a space.
* (asterisk)	Matches a zero or more characters or patterns
+ (plus sign)	Matches one or more instances of the character or pattern
? (question mark)	Matches one or more instances or the character or pattern.
\\ (Escape character)	Used frequently in BGP communities.

Examples

Intent	Command
Display locally originated prefixes.	show bgp ipv4 unicast regexp ^$
Display externally originated prefixes.	show bgp ipv4 unicast regexp [^_]
Display prefixes originated by a specific AS.	show bgp ipv4 unicast regexp 65537000$
Matches prefixes from the clients of directly connected AS 1234.	show bgp ipv4 unicast regexp ^1234_([0-9]+)
Matches prefixes from confederation peer 65512	show bgp ipv4 unicast regexp ^\65512\)
Matches prefixes from the clients of directly connected AS 12345, where AS 12345 might be doing AS PATH prepending.	show bgp ipv4 unicast regexp ^(12345_)+([0-9]+)

Loc-RIB Table Version

The BGP table version can be viewed using the command show bgp ipv4 unicast summary. Table version information for two variables is displayed in the output: BGP table version and main routing table version. When update messages are received, the BGP table version increments by one and the main routing table version is incremented as well when these updates are installed into it. These updates can be triggered by traffic manipulation through change in path attributes. A rapidly incrementing BGP table version may point to instability of the BGP. This can be a clue to assisting with troubleshooting.

To view the BGP table entry version for a specific NLRI, issue the command show bgp ipv4 unicast <prefix>.

Adj-RIB-in

The Adj-RIB-in table contains NLRI (prefixes and their path attributes) received from a neighbor before processing of inbound route policies. After all route policies are processed, the prefixes and their associated path attributes are stored in the Loc-RIB table and the Adj-RIB-in table is purged to save memory.

The Adj-RIB-in table can be viewed by running the command: show bgp ipv4 unicast neighbor <ip-address> received-routes.

R7#show bgp ipv4 unicast neighbors 10.67.1.1 received-routes
% Inbound soft reconfiguration not enabled on 10.67.1.1
R7#

The output above indicates that the display of the Adj-RIB-in table is not enabled. Viewing the Adj-RIB-in table is disabled by default. To enable the Adj-RIB-in table, issue the command: neighbor <ip-address> soft-reconfiguration inbound in BGP address-family mode. To implement any new route policies, carry out a soft BGP reset.

R7(config-router)#address-family ipv4 unicast
R7(config-router-af)#neighbor 10.67.1.1 soft-reconfiguration inbound

The BGP route policy can then be configured and applied to the neighbor. In this example, the local preference of all prefixes from a neighbor is set to 500 using a route-map named RM_LOCALPREF_500.

R7(config)#route-map RM_LOCAL_PREF_500 permit 10
R7(config-route-map)#set local-preference 500
R7(config-route-map)#exit
R7(config-router-af)#neighbor 10.67.1.1 route-map RM_LOCAL_PREF_500 in
R7(config-router-af)#end

To enforce the routing policy on the prefixes from the neighbor, the neighbor is requested to resend its prefixes using a soft reset on the local BGP device.

R7#clear bgp ipv4 unicast 10.67.1.1 soft in

The following output shows a summary of the packet exchange between the local BGP device and its remote peer after a soft reset is configured.

No. Time                          Source      Destination  Protocol    Length    Info
22  2021-12-06 22:29:24.607378    10.67.1.2   10.67.1.1    BGP         77        ROUTE-REFRESH Message
23  2021-12-06 22:29:24.618021    10.67.1.1   10.67.1.2    BGP         77        ROUTE-REFRESH Message
24  2021-12-06 22:29:24.618093    10.67.1.1   10.67.1.2    BGP         208       UPDATE Message, UPDATE Message, ROUTE-REFRESH Message
25  2021-12-06 22:29:24.628986    10.67.1.2   10.67.1.1    TCP         60        179 ≻ 44223 [ACK] Seq=43 Ack=197 Win=15021 Len=0


A ROUTE-REFRESH message gets sent by the local BGP device to its peer.

Border Gateway Protocol - ROUTE-REFRESH Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 23
    Type: ROUTE-REFRESH Message (5)
    Address family identifier (AFI): IPv4 (1)
    Subtype: Normal route refresh request [RFC2918] with/without ORF [RFC5291] (0)
    Subsequent address family identifier (SAFI): Unicast (1)


The BGP peer responds with a ROUTE-REFRESH message signaling the start of route refresh

Border Gateway Protocol - ROUTE-REFRESH Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 23
    Type: ROUTE-REFRESH Message (5)
    Address family identifier (AFI): IPv4 (1)
    Subtype: Demarcation of the beginning of a route refresh (1)
    Subsequent address family identifier (SAFI): Unicast (1)


The second BGP packet contains two UPDATE messages and one ROUTE-REFRESH message signalling the end of the route refresh.

Frame 24: 208 bytes on wire (1664 bits), 208 bytes captured (1664 bits) on interface -, id 0
Ethernet II, Src: ca:06:04:8b:00:38 (ca:06:04:8b:00:38), Dst: ca:08:04:ab:00:08 (ca:08:04:ab:00:08)
Internet Protocol Version 4, Src: 10.67.1.1, Dst: 10.67.1.2
Transmission Control Protocol, Src Port: 44223, Dst Port: 179, Seq: 43, Ack: 43, Len: 154
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 72
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 27
    Path attributes
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65000
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 65000
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65000
        Path Attribute - NEXT_HOP: 10.67.1.1
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 10.67.1.1
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
    Network Layer Reachability Information (NLRI)
        6.6.6.6/32
            NLRI prefix length: 32
            NLRI prefix: 6.6.6.6
        10.6.10.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.10.0
        10.6.11.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.11.0
        10.6.12.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.12.0
        10.67.1.0/30
            NLRI prefix length: 30
            NLRI prefix: 10.67.1.0
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 59
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 20
    Path attributes
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65000
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 65000
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65000
        Path Attribute - NEXT_HOP: 10.67.1.1
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 10.67.1.1
    Network Layer Reachability Information (NLRI)
        10.4.10.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.4.10.0
        10.4.11.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.4.11.0
        10.4.12.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.4.12.0
        10.4.13.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.4.13.0
Border Gateway Protocol - ROUTE-REFRESH Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 23
    Type: ROUTE-REFRESH Message (5)
    Address family identifier (AFI): IPv4 (1)
    Subtype: Demarcation of the ending of a route refresh (2)
    Subsequent address family identifier (SAFI): Unicast (1)


The prefixes received from the neighbor can be viewed before the routing policies are applied using the command show bgp ipv4 unicast neighbor <ip-address> received-routes

R7#show bgp ipv4 unicast neighbor 10.67.1.1 received-routes
BGP table version is 76, local router ID is 10.7.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network           Next Hop            Metric LocPrf Weight Path
 r   6.6.6.6/32       10.67.1.1               0               0 65000 i
 *   10.4.10.0/24      10.67.1.1                              0 65000 i
 *   10.4.11.0/24      10.67.1.1                              0 65000 i
 *   10.4.12.0/24      10.67.1.1                              0 65000 i
 *   10.4.13.0/24      10.67.1.1                              0 65000 i
 *   10.5.1.0/24       10.67.1.1                              0 65000 i
 *   10.5.2.0/24       10.67.1.1                              0 65000 i
 *   10.5.10.0/24      10.67.1.1                              0 65000 i
 *   10.5.11.0/24      10.67.1.1                              0 65000 i
 *   10.5.12.0/24      10.67.1.1                              0 65000 i
 *   10.5.13.0/24      10.67.1.1                              0 65000 i
 *   10.5.14.0/24      10.67.1.1                              0 65000 i
 *   10.5.15.0/24      10.67.1.1                              0 65000 i
 *   10.6.10.0/24      10.67.1.1                0             0 65000 i
 *   10.6.11.0/24      10.67.1.1                0             0 65000 i
 *   10.6.12.0/24      10.67.1.1                0             0 65000 i
 *   10.67.1.0/30      10.67.1.1                0             0 65000 i

Total number of prefixes 17
R7#show bgp ipv4 unicast neighbor 10.67.1.1 routes
BGP table version is 76, local router ID is 10.7.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>  6.6.6.6/32       10.67.1.1                0    500      0 65000 i
 *>  10.4.10.0/24     10.67.1.1                     500      0 65000 i
 *>  10.4.11.0/24     10.67.1.1                     500      0 65000 i
 *>  10.4.12.0/24     10.67.1.1                     500      0 65000 i
 *>  10.4.13.0/24     10.67.1.1                     500      0 65000 i
 *>  10.5.1.0/24      10.67.1.1                     500      0 65000 i
 *>  10.5.2.0/24      10.67.1.1                     500      0 65000 i
 *>  10.5.10.0/24     10.67.1.1                     500      0 65000 i
 *>  10.5.11.0/24     10.67.1.1                     500      0 65000 i
 *>  10.5.12.0/24     10.67.1.1                     500      0 65000 i
 *>  10.5.13.0/24     10.67.1.1                     500      0 65000 i
 *>  10.5.14.0/24     10.67.1.1                     500      0 65000 i
 *>  10.5.15.0/24     10.67.1.1                     500      0 65000 i
 *>  10.6.10.0/24     10.67.1.1                0    500      0 65000 i
 *>  10.6.11.0/24     10.67.1.1                0    500      0 65000 i
 *>  10.6.12.0/24     10.67.1.1                0    500      0 65000 i
 *   10.67.1.0/30     10.67.1.1                0    500      0 65000 i

Total number of prefixes 17
R7#

The above output shows that the local preference of the routes received was updated by the route map and installed into the routing table. The command show bgp ipv4 unicast neighbor <ip-address> routes is used to view prefixes received from the specified BGP peer after the implementation of inbound policies. Using the Adj-RIB-in, it is possible to view routes prior to the implementation of routing policies.

Adj-RIB-out

The Adj-RIB-out table contains NLRI after outbound route policies have been processed. The Adj-RIB-Out table is maintained for each BGP peer. It contains routes advertised to a specific router. The command show bgp ipv4 unicast neighbors <ip-address> advertised-routes displays the contents of the Adj-RIB-Out table for a neighbor. The Loc-RIB table stores path attributes before outbound policies are applied.

Prefix summarization or aggregation can be confirmed in the Adj-RIB-out table if configured.

Prefix Advertisement

Local prefixes are inserted into the BGP table using the network command as well as through redistribution using the redistribution command. Locally originated prefixes have an origin code of IGP (i).

Redistribution

Redistribution of IGP routes into the BGP table can be accomplished using the BGP redistribution command. This command includes several options among which includes the route-map option to reference a route map that can be used to filter prefixes to be redistributed as well as modify the path attributes of these prefixes. Redistributed prefixes have an origin code of incomplete.

IGPs were not designed for the massive number of prefixes that BGP was designed for. It is therefore not recommended to redistribute NLRI into IGPs.

RIB-Failure

The BGP table may show some prefixes with a status code of rib-failure (r). A rib-failure indicates that the BGP best path for a prefix cannot be installed into the routing table in spite of the prefix being valid and having a path to the BGP next hop. One of the primary reasons for rib-failures is the higher administrative distance (AD). This is particularly the case if the same prefix is learned through iBGP and an IGP. iBGP has a higher default administrative distance (of 200) than most IGPs. The list of prefixes with a rib-failure and the reason for the rib-failure can be viewed using the command show bgp ipv4 unicast rib-failure.

A rib-failure does not prevent the propagation of the best path for a prefix by BGP. To stop the propagation of prefixes that experience a rib-failure or any other prefix that is not marked as "active", issue the BGP commmand bgp suppress-inactive. This stops the propagation, through BGP, of any prefixes that are not marked as active in the BGP table i.e., prefixes that were not installed into the RIB.

If the network design provides for the installation into the RIB of BGP prefixes with a rib-failure; this can be accomplished by lowering the administrative distance of iBGP to lower that of the IGP.

Prefix Processing

Not every prefix in the Loc-RIB table is advertised to BGP peers or installed into the global RIB. When a route is received from a peer, BGP performs the following route processing steps:

• Step 1: Store the route in the Adj-RIB-In table in the original state and apply the inbound route policy, based on the neighbor from which it was received.
• Step 2: Update the Loc-RIB table with the latest entry. The Adj-RIB-In table is cleared to save memory.
• Step 3: Pass a validity check to verify that the route is valid and that the next-hop address is resolvable in the global RIB. If the route fails, the route remains in the Loc-RIB table but is not processed further.
• Step 4: Identify the BGP best path and pass only the best path and its path attributes to step 5.
• Step 5: Install the best-path route into the global RIB, process the outbound route policy, store the non-discarded routes in the Adj-RIB-Out table, and advertise to BGP peers.

eBGP and iBGP Route Advertisement Behaviours

Differences in eBGP Behaviour from iBGP

1. With eBGP, the TTL of packets is set to 1 (one) by default. eBGP packets are dropped in transit if a multihop BGP session is attempted. TTL on iBGP is 255 allowing multi-hop sessions.
2. The advertising router modifies the BGP next-hop path attribute to the IP address sourcing the BGP connection(on eBGP routes.)
3. The advertising router prepends its ASN to the existing AS_PATH.
4. The receiving router verifies that the AS_PATH does not contain an ASN that matches the local router's. BGP discards the NLRI if it fails the AS_PATH loop-prevention check.

eBGP and iBGP Route Advertisement

It is common for the validity check to fail for external prefixes learned from an iBGP peer. iBGP peers do not modify the next-hop address if the NLRI has a next-hop address other than 0.0.0.0. The next-hop address must be resolvable in the global RIB in order for it to be considered valid and advertised to other BGP peers. eBGP peering links must be installed in the RIB of intermediate iBGP peers for forwarding to occur or use an IGP between iBGP peers.

The BGP next-hop-self feature can be used to advertise external prefixes to iBGP neighbors replacing the next-hop path attribute of the prefix with the peering link IP address of the local BGP device. This can be configured in address-family mode using the command neighbor <ip-address> next-hop-self [all] for each neighbor. The next-hop-self does not modify the next-hop address for iBGP prefixes by default. The all keyword modifies the next-hop for iBGP too.

R6(config-router)#address-family ipv4 unicast
R6(config-router-af)#neighbor AS65000 next-hop-self

On an iBGP peer, issuing the command show bgp ipv4 unicast confirms that the next hop for eBGP advertised links has been set to the eBGP peer.

R5#show bgp ipv4 unicast neighbor 6.6.6.6 routes
BGP table version is 23, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
r>i 6.6.6.6/32       6.6.6.6                  0    100      0 i
*>i 10.6.10.0/24     6.6.6.6                  0    100      0 i
*>i 10.6.11.0/24     6.6.6.6                  0    100      0 i
*>i 10.6.12.0/24     6.6.6.6                  0    100      0 i
*>i 10.7.10.0/24     6.6.6.6              20000    100      0 65536 i
*>i 10.8.10.0/24     6.6.6.6              20000    100      0 65536 65539 i
*>i 10.8.11.0/24     6.6.6.6              20000    100      0 65536 65539 i
*>i 10.67.1.0/30     6.6.6.6                  0    100      0 i
*>i 10.78.1.0/30     6.6.6.6              20000    100      0 65536 i
*>i 10.108.1.0/30    6.6.6.6              20000    100      0 65536 65539 i
Total number of prefixes 10

Path Attributes

Every prefix in a BGP update contains path attributes (PAs). Path attributes can be thought of as properties or characteristics of a prefix or network layer reachability information (NLRI). NLRI is a routing update that consists of the network prefix, prefix length and any other PAs for the specific route. Path attributes can be modified with granularity providing complete control of BGP's routing policies.

Path attributes are contained in every BGP update message except withdrawal messages. Each attribute consists of attribute type, length and value (TLV) and is two bytes (1 byte for flags and the other for attribute details).

Classification of Path Attributes

BGP prefix path attributes are classified as;

1. Well-known mandatory: Any device capable of speaking BGP has to understand these attributes. Every BGP update must include these attributes. These include: next-hop, AS_PATH and origin code.
2. Well-known discretionary: every BGP speaker should understand these types of attributes, however they may or may not be included with every BGP update message.
3. Optional transitive: optional indicates that no devices are guaranteed to understand this attribute. Transitive indicates that this path attribute is permitted to transit from one autonomous system to another. This is done by setting the transitive flag to "on" that results in the BGP device including the path attribute in its update to eBGP peers. For prefixes received with path attributes that are not understood, these prefixes can be installed in the BGP table. However, these attributes cannot be altered. Additionally, they are included in any subsequent advertisement to other peers. These attributes are maintained with the prefix update from autonomous system to autonomous system.
4. Optional non-transitive: may be proprietary. This attribute can not leave the autonomous system.

All well-known mandatory path attributes are also transitive. Routers usually drop BGP updates if they do not contain these path attributes. Optional attributes do not have to be recognised by all BGP implementations.

Use of Path Attributes

Path attributes serve a variety of purposes with some path attributes serving more than one purpose:

• Best path selection process
• Loop prevention
• Prefix classification for further processing e.g. route tags used by BGP communities that are processed by a downstream router.
• Informative e.g. atomic aggregate which indicates that some path information is missing due to prefix summarization.

Path attributes offer BGP the extensive flexibility in route manipulation that is not seen in any other routing protocol/application.

Best Path Selection

Prerequisites

Next Hop

The next hop path attribute is a well-known transitive attribute and has a type code of 3. In eBGP, the next hop IP is the IP address of the exit interface of an eBGP peer that sent the update. An iBGP peer that receives NLRI from an eBGP does not modify the next hop attribute when sending the update to an iBGP peer. The next hop attribute should be thought of in the context of autonomous system to autonomous system instead of router to router. This approach helps in troubleshooting reachability issues that my arise. In iBGP, the next hop IP address is the address of the iBGP peer that originated the prefix. The originator of a prefix has a next hop value of 0.0.0.0 in the BGP table. When advertising internal prefixes, a BGP peer should override the next hop value to its exit interface using the next-hop-self keyword of the command neighbor. When a router receives a BGP update, before the start of the best path selection process, the BGP process first verifies whether the next-hop is reachable. If the next-hop is not reachable, the best path selection process will not even start for the prefix. If the next hop is reachable, then the best path selection process starts.

The next hop path attribute controls the IGP route recursion i.e. BGP knows the next-hop but does not know the egress interface. It is important to note that BGP entries in the routing table do not have an exit interface specified. The IGP must perform recursion otherwise, the route cannot be used. The result of a failed next hop recursion is a failed best path selection i.e. the route is not installed in the RIB or advertised. The next-hop validity check is to prevent a route recursion failure. By default, outbound iBGP updates do not modify the next-hop attribute regardless of iBGP peer type. This can be modified using the BGP command neighbor <ip-address> next-hop-self or in a route-map using the action command set ip next-hop. More recent IOS versions include the command next-hop-self all to insert the route reflector in the data-path. This is usually used in Unified MPLS design.

Updates sent to an iBGP peer does not modify the next hop by default. The source IP address of the update message is used as the next hop.

Note: All BGP prefixes must pass the route validity check, and the next-hop IP address must be resolvable for the route to be eligible as a best path. Some vendors and publications consider this as the first step in the BGP best path selection process.

next-hop-self at Edge

If the keyword next-hop-self is added when configuring an iBGP peer, on a BGP router that is at the edge of the autonomous system, the following are the effects:

1. Pros:
• Peer can use the same next-hop on outbound updates to iBGP peers.
• Result is same dynamic update-group.
• There will be no need to include external links in IGP.
2. Cons:
• Hinders fast convergence if the external uplink fails. This has to do with BGP's next hop tracking; if the next hop is lost, all routes accessible through the lost next hop are flushed and reconvergence is initiated.

eBGP Next Hop Processing

By default, outbound eBGP updates have their next hop path attribute value as the IP address of the interface that was configured using the update-source keyword e.g. if update-source command points to the interface loopback0, next-hop is set to the IP address configured on the interface loopback0. This behaviour can be modified using the route-map action statement set ip next-hop. The command neighbor next-hop-unchanged can be used for third-party next-hops.

Best Path Selection Process

A BGP router only advertises the best path to neighboring routers. Inside the Loc-RIB, all the prefixes and their path attributes are maintained with the best path calculated. The best path selection process evaluates multiple path attributes of the list of available paths from which the best path is selected. The best path is presented to the RIB for installation. If the best path is no longer available, the BGP device can use the existing paths to quickly identify a new best path. BGP recalculates the best path for a prefix when the following events occur:

1. Change in the next-hop or the reachability of the next-hop of a prefix
2. Failure of an interface connected to an eBGP peer
3. Redistribution change
4. BGP update containing updated path information i.e., added or removed paths and path attributes for a network prefix.

By default, BGP automatically installs the first received path as the best path. When additional paths are received for the same network prefix, the newer paths are compared against the current best path. If there is a tie, processing continues until a best path winner is identified. The BGP best path algorithm, on Cisco devices, selects the best path in the following order:

1. Prefer the path with the highest weight
2. Prefer the path with the highest local preference.
3. Prefer the path that was originated by the local router via the network or aggregate commands or through route redistribution from an IGP such as OSPF, IS-IS, etc. Local paths sourced through the network or redistribute commands are preferred over local aggregated paths sourced through the command aggregate-address.
4. Prefer the path with the lower Accumulated Interior Gateway Protocol (AIGP) metric.
5. Prefer the path with the shortest AS_PATH.
6. Prefer the path with the lowest origin type where IGP is lower than external gateway protocol (EGP), and EGP is lower than incomplete.
7. Prefer the path with the lowest Multi-Exit Discriminator (MED).
8. Prefer the external path over the internal path.
9. Prefer the path with the lowest IGP metric to the BGP next hop.
10. Prefer the path with the oldest session for eBGP paths.
11. Prefer the path from the BGP peer with the lowest router ID.
12. Prefer the path with the lowest cluster length for iBGP paths.
13. Prefer the path with the lowest neighbor BGP router ID for iBGP peers.

Some consider the next-hop validity as the first path selection criteria.

1. Weight

Weight is a 16-bit value (0 - 65535) assigned locally on the router where the higher weight is preferred. Weight is an optional non-transitive path attribute and therefore is not included in the update message. BGP weight is a Cisco-defined path attribute and the first parameter checked when selecting the best path on Cisco devices. Weight only influences outbound traffic from a router or an autonomous system and is not advertised to peers. It is locally significant and is not contained in updates. It can be thought of in the context of the administrative distance assigned to different routing protocols by a router. BGP peers do not know the values for weight that are used by the local router in the best path selection process.

By default, locally originated prefixes have a weight value of 32768. For prefixes received from other BGP peers, the weight is assigned a value of zero (0). Use the route-map command set weight <0-65535> to modify the weight path attribute. If modifying the weight path attribute, take note of the following;

• Weight attribute should be modified in the "in" direction i.e., the path attribute of the prefix is modified before it is installed in the Loc-RIB table.
• Apply the route-map to the BGP peer which is advertising the NLRI whose weight path attribute is to be modified.

The following sequence of steps shows how the weight attribute can be modified to influence the best path selection process of a prefix:

R1(config)#do show bgp ipv4 unicast 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 19
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  65512 65538
    9.9.9.9 from 3.3.3.3 (10.3.10.1)
      Origin IGP, metric 0, localpref 100, valid, internal
  Refresh Epoch 2
  65512 65538
    9.9.9.9 from 9.9.9.9 (10.9.13.1)
      Origin IGP, localpref 100, valid, external, best
R1(config)#


Step 1: Configure a prefix-list or access control list (ACL) to identify the prefix(es) whose weight is to be modified.

R1(config)#ip access-list standard 10
R1(config-std-nacl)#10 permit 10.10.10.0 0.0.0.255
R1(config-std-nacl)#exit

Step 2: Configure a route-map to reference the ACL or prefix-list in Step 1 and then modify the weight of the prefix.

R1(config)#route-map RM_WEIGHT_200 permit 10
R1(config-route-map)#match ip address 10
R1(config-route-map)#set weight 200
R1(config-route-map)#exit

Step 3: Apply the route-map to a neighbor and specify the direction.

R1(config)#router bgp 65000
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#neighbor 3.3.3.3 route-map RM_WEIGHT_200 in

Step 4: Implement a route refresh. A new policy does not take effect on existing routes in the BGP table. It only takes effect on new updates received.

R1(config-router-af)#do clear bgp ipv4 unicast 3.3.3.3 in


Weight can be set for specific routes with an inbound route map or for all routes learned from a specific neighbor. The command set weight <1-65535> in a route map sets the weight value for a matching prefix.

The weight is set for all prefixes received by a neighbor using the BGP address family command: neighbor <ip-address> weight <1-65535>. After changing the weight value, carryout a soft reset of BGP.

R1(config-router-af)#do show bgp ipv4 unicast 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 41
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 2
  65512 65538
    9.9.9.9 from 3.3.3.3 (10.3.10.1)
      Origin IGP, metric 0, localpref 100, weight 200, valid, internal, best
  Refresh Epoch 2
  65512 65538
    9.9.9.9 from 9.9.9.9 (10.9.13.1)
      Origin IGP, localpref 100, valid, external
R1(config-router-af)#

2. Local Preference

Local preference (LOCAL_PREF) is a well-known discretionary path attribute that indicates the preference for exiting the autonomous system to a remote prefix. It is 32-bit. A higher value is preferred. The local preference does not have to be present in a BGP update. If the value is not specified, then a default value of 100 is used. LOCAL_PREF is not advertised between eBGP peers. However, it is advertised to confederation eBGP peers in BGP confederations. It is used to influence routing decisions in the local autonomous system i.e. it is propagated only in the local AS. Modifying the LOCAL_PREF can influence path selection in other iBGP peers without affecting eBGP peers because it is not advertised outside the autonomous system. Local preference has a type code of 5.

LOCAL_PREF can be set for specific routes with an inbound route map using the command: set local-preference <0-4294967295> The default local preference value can be modified from 100 to a different value using the command bgp default local-preference <0-4294967295>. The LOCAL PREFERENCE values can be modified to alter routing behaviour using a route map:

Before altering the Local preference on an autonomous system edge BGP device, the path taken by a downstream router is shown below:

R2#traceroute 10.10.10.1
Type escape sequence to abort.
Tracing the route to 10.10.10.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.12.1.1 24 msec 16 msec 16 msec
  2 10.19.1.2 [AS 65512] 20 msec 40 msec 20 msec
  3 10.109.1.2 [AS 65512] 104 msec 44 msec 32 msec


The Loc-RIB table of the downstream iBGP peer.

R2#show bgp ipv4 unicast 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 62
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 3
  65512 65538
    3.3.3.3 (metric 3) from 3.3.3.3 (10.3.10.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
  Refresh Epoch 2
  65512 65538
    1.1.1.1 (metric 2) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal


Step 1: Identify the prefixes whose local preference values are to be modified using an ACL or prefix-list:

R3(config)#ip prefix-list PL_10.10.10.0 seq 10 permit 10.10.10.0/24 le 32

In this case, a prefix list is used to identify the network whose local preference is to be modified. The network address 10.10.10.0 with a subnet mask of 255.255.255.0 and any potential subnets of this address has been identified by the prefix list PL_10.10.10.0.

Step 2: Set the local preference value in a route map referencing the access control list or prefix list.

R3(config)#route-map RM_LOCALPREF permit 10
R3(config-route-map)#match ip address prefix-list PL_10.10.10.0
R3(config-route-map)#set local-preference 500
R3(config-route-map)#exit

Step 3: Apply the route map to a neighbor or peer-group.

R3(config)#router bgp 65000
R3(config-router)#address-family ipv4 unicast
R3(config-router-af)#neighbor AS65000 route-map RM_LOCALPREF out
R3(config-router-af)#end


Step 4: Carryout a soft reconfiguration of peers.

R3#clear bgp ipv4 unicast 65000 soft out

The path taken is different after configuration of the Local Preference values.

R2#traceroute 10.10.10.1
Type escape sequence to abort.
Tracing the route to 10.10.10.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.12.1.1 36 msec 24 msec 24 msec
  2 10.13.1.2 16 msec 28 msec 32 msec
  3 10.39.1.2 [AS 65512] 20 msec 16 msec 24 msec
  4 10.109.1.2 [AS 65512] 32 msec 40 msec 68 msec


Note: Changing the LOCAL_PREF can produce interesting results. If two routers having different paths to a prefix advertise their paths to each other, both will receive the other's prefix advertisement. However, with changed LOCAL_PREF, the router whose path has a lower LOCAL_PREF will send a prefix withdraw to the peer with a better path. It will have two paths to the same prefix and the one with the better path will have one. Always remember BGP peers only share their best path.

The downstream iBGP peers will have one path.

R2#show bgp ipv4 unicast 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 62
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 3
  65512 65538
    3.3.3.3 (metric 3) from 3.3.3.3 (10.3.10.1)
      Origin IGP, metric 0, localpref 500, valid, internal, best


However, only the autonomous system edge BGP device with the path with the lower local preference will maintain both paths. on one upstream BGP device

R1#show bgp ipv4 unicast 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 69
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 2
  65512 65538
    3.3.3.3 (metric 2) from 3.3.3.3 (10.3.10.1)
      Origin IGP, metric 0, localpref 500, valid, internal, best
  Refresh Epoch 1
  65512 65538
    9.9.9.9 from 9.9.9.9 (10.9.13.1)
      Origin IGP, localpref 100, valid, external
*********************************************************

R3#show bgp ipv4 unicast 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 19
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     4
  Refresh Epoch 2
  65512 65538
    9.9.9.9 from 9.9.9.9 (10.9.13.1)
      Origin IGP, localpref 100, valid, external, best


3. Locally Originated

Preference is given in best path selection using the following criteria:

1. Routes that were advertised locally: these are paths that were sourced into the Loc-RIB table using the BGP network command.
2. Prefer local paths that were redistributed into BGP.
3. Networks that have been aggregated locally using the BGP command aggregate-address (summarization).
4. Routes received by BGP peers

Note: prefixes injected into the BGP table using the network command and through redistribution are preferred to summary prefixes using the aggregate-address command.

4. Accumulated Interior Gateway Protocol (AIGP)

Accumulated Interior Gateway Protocol (AIGP) is an optional non-transitive path attribute that is included with advertisements throughout an autonomous system. IGPs typically use metric to identify the shortest path to a destination but cannot provide the scalability of BGP. BGP uses the autonomous system to identify a single domain of control for a routing policy. BGP does not use the path metric due to scalability issues combined with the notion that each autonomous system may use a different policy to calculate the metrics. AIGP provides the ability for BGP to maintain and calculate a conceptual path metric in environments with multiple autonomous systems using unique IGP routing domains in each AS. AIGP path attribute exchanges must be agreed upon between the BGP peers and AIGP metrics are only included in prefix advertisements between AIGP-enabled peers. AIGP metrics are enabled for a BGP neighbor with the BGP address family config command neighbor <ip-address> aigp

The following guidelines apply to AIGP metrics:

• A path with an AIGP metric is preferred to a path without an AIGP metric.
• If the next-hop address requires a recursive lookup, the AIGP path needs to calculate a derived metric to include the distance to the next-hop address. This ensures that the cost to the BGP edge router is included. The formula is: Derived AIGP metric = (Original AIGP Metric + Next-Hop AIGP Metric)
  • If multiple AIGP paths exist and one next-hop address contains an AIGP metric and the other does not, the non-AIGP path is not used.
  • The next-hop AIGP metric is recursively added if multiple lookups are performed.
• AIGP paths are compared based on the derived AIGP metric (with recursive next hops) or the actual AIGP metric (non-recursive next-hop). The path with the lower AIGP metric is preferred.
• When a router A advertises an AIGP-enabled path that was learned from another router B, if the next-hop address changes to a router A address, router A increments the AIGP metric to reflect the distance (the IGP path metric) between routers A and B.

5. AS_PATH

The AS_PATH attribute is a list of the ASNs to the destination prefix. It typically correlates to the autonomous system hop count. A shorter AS_PATH is preferred over a longer AS_PATH. The AS_PATH is a well-known transitive and mandatory path attribute. It has to be included in all eBGP updates. eBGP peers discard updates if they do not include the AS_PATH. The AS_PATH is not prepended by iBGP peers because it can result in traffic being black-holed. Traffic can be modified by prepending to the AS_PATH in a route-map with the command set as-path prepend <last_as_number | pattern>. Tip: Prepend an AS on a path that you do not want to use. set as-path influences routing decision of downstream routers.

AS_PATH prepending on production networks should use the local autonomous system number:

Step 1: create the access control list or prefix list to identify the prefixes whose AS_PATH attribute is to be modified.

Step 2: Configure a route-map and reference the prefix-list or ACL. set the AS_PATH attribute using the command set as-path prepend <AS>

Step 3: Apply the route-map on a BGP peer

Step 4: Carry out a soft reconfiguration of the neighborship.

Some service providers block prefixes whose AS_PATH has been prepended. In such a scenario, path selection can be influenced using the MED.

When working with confederations, AS_CONFED_SEQUENCE (confederation AS_PATH) is not counted, and for aggregated addresses with multiple autonomous system numbers (ASNs) under the AS_SET portion of AS_PATH, the AS_SET counts for only one AS_PATH entry.

NOTE: The AS_PATH attribute is not considered in the best path selection process if the command bgp bestpath-as-path ignore is configured.

6. Origin

Origin is a well-known mandatory BGP path attribute. By default, networks that are advertised on Cisco routers using the network statement are set with the code i (for IGP). Redistributed networks are assigned the code ? (incomplete) origin attribute. The Origin path attribute has a type code of 1 (one). The types of origin include: IGP (code 0), EGP, and redistributed. When using the origin attribute to determine the best path, the order of preference is;

1. IGP origin (i): These prefixes enter the BGP table through the network command.
2. Exterior Gateway Protocol (EGP) (e): referencing the EGP (exterior gateway protocol), the predecessor to BGP.
3. Incomplete origin (?): redistributed routes.

On Cisco IOS devices, the origin can not be set to EGP. EGP is no longer implemented by most network equipment vendors. The only two origins attributes that can be viewed will have a value of i or ?.

A prefix's origin can be modified in a route map with the command: set origin <igp | incomplete>

7. Multi-Exit Discriminator (MED)

MED is a discretionary non-transitive BGP path attribute. MED's purpose is to influence traffic flows inbound from a different autonomous system. MED uses a 32-bit value called a metric. A lower MED is preferred. BGP sets the MED automatically to the IGP metric during network advertisement or redistribution. If the MED is received via an eBGP session, it can be advertised to other iBGP peers but it should not be sent outside the autonomous system that received it. MED can be considered as a sort of suggestion sent from an eBGP peer to another eBGP peer to suggest to that neighbor how they enter my AS for a particular prefix. The eBGP peers can choose to ignore the MED values when deciding the best path. The default MED value is zero(0). For MED to be an effective decision factor, the paths being decided upon must come from the same autonomous system. Any confederation sub-ASs are ignored. The MED has a type code of 4. MED can be used as a sort of load balancing technique with traffic to specific prefixes using one path and traffic to other prefixes using another path.

RFC 4451 guidelines state that a prefix without a MED value should be given priority (in essence a value of zero). Cisco follows this recommendation by default. Some organisations require that the MED must be set and any paths without a MED should be treated as least preferred. If the metric is set to zero, IOS will advertise it to peers. The behaviour for prefixes with missing MED can be modified so that they are given the least preference. Applying the command bgp bestpath med missing-as-worst will set the MED to infinity with a value of 4294967295 if the MED is missing from a path. The command should be placed on all nodes in an AS to keep the best path algorithm configuration settings the same.

The default MED comparison mechanism requires that the AS_PATH values be identical because the policies used to set the MED can vary from one service provider's autonomous system to another service provider's autonomous system. This means that the MED can influence traffic only when multiple links are from the same service provider. Typically, organizations use different service providers for redundancy. In these situations, the default BGP rules for MED comparison from different service providers need to be relaxed to compare MED values from different service providers. The always-compare-med keyword allows for the comparison of MED regardless of the AS_PATH. This is enabled using the command bgp always-compare-med. It should be configured on all BGP routers in the autonomous system or a routing loop could potentially occur.

If the command bgp bestpath med-confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE. These paths originated within the local confederation.

MED-Deterministic

The paths are stored in the order in which they are received and stored in the BGP table. If the keyword always-compare-med is not enabled, the path MED is only compared against the existing best path and not against all the paths in the Loc-RIB table which can cause variations in the best path comparison process. BGP deterministic MED corrects the problem by grouping together paths with identical AS_PATH values as part of the best path identification process. Each group's MED is compared against the other group's MED. BGP deterministic MED is enabled with the configuration command: bgp deterministic-med. It is recommended for all BGP deployments in the same autonomous system.

Modification of MED

Step 1: Identify the prefixes whose MED values are to be modified using a prefix list or access control list:

Step 2: Reference the identified prefixes in a route map and modify the MED values using the route-map command set metric <1-4294967295>. The default MED value is 0.

Step 3: Implement a route refresh for outgoing BGP updates: clear ip bgp * out

8. eBGP over iBGP

The best path selection follows this order:

1. eBGP peers (most desirable)
2. Confederation member AS peers. There is no distinction between confederation internal and confederation external.
3. iBGP peers (least desirable)

The rationale behind this prioritisation is that for external prefixes, traffic should be routed out of the local AS rather than internally through the local AS to get to the external prefix.

9. Lowest IGP Metric

Use the lowest IGP metric/cost to reach the BGP next-hop address. Lower metric value is preferred. This path attribute is relevant to best path selection in iBGP. Multiple paths can be used (multi-path) if all the paths available have the same path attributes by this stage. There is a command to allow multipath if AS_PATH is not the same (BUT has to be same length): bgp best-path as-path multipath-relax.

10. Oldest eBGP Path

BGP maintains stability in a network by preferring the path from the oldest (established) BGP session. This ensures stability in the network because unstable sessions result in the BGP best-path calculation executing frequently which consumes CPU processing. The downfall of this technique is that it does not lead to a deterministic method of identifying the BGP best path from a design perspective.

11. Lowest Router ID

Prefer the path from the BGP peer with the lowest router ID. If a path contains route reflector (RR) attributes, the originator ID is substituted for the router ID in the best path selection process.

12. Minimum Cluster Length

Select the best path using the lowest cluster list length. This is specifically for iBGP routes. This directly refers to the number of route reflectors that the prefix transits. The cluster list is a non-transitive BGP path attribute that is appended (not overwritten) by a route reflector with its cluster ID. Route reflectors use cluster ID attribute as a loop prevention mechanism. This cluster ID is not advertised between autonomous systems and is locally significant. In simplest terms, this step locates the path that has travelled the lowest number of iBGP advertisement hops.

13. Lowest Neighbor Address

Select the path that comes from the lowest BGP neighbor address. This step is limited to iBGP peerings because eBGP peerings used the oldest received path as the tie-breaker.

Exceptions to the Best Path Selection

The following configurations to BGP alter the aforementioned default best path selection process:

• AS-Path: bgp bestpath as-path ignore: Ignore AS_PATH path attribute in best path selection process.
• MED:
  • bgp always-compare-med: Compare the MED regardless of the AS that the prefix is originated from i.e., do not care whether the paths are from the same AS or different AS.
  • bgp bestpath med-confed: compares MED for routes locally originated in the confederation
  • bgp bestpath med-missing-as-worst: assigns MED of 4294967294 to NULL MED.
  • bgp deterministic med: Compare MED against all possible paths.
• IGP Metric: bgp bestpath igp-metric ignore. Ignore the IGP metric to the next hop. This was introduced in IOS-XE3.4s
• Router-ID: no bgp bestpath compare-routerid: ignore the router-id from the best path selection process.

Manipulating Best Path Selection

• Outbound routing policy affects inbound traffic
• Inbound routing policy affects outbound traffic
• Longest match routing is above all: affects both directions.

Attributes Influencing Outbound Path Selection

Weight and local-preference: set inbound and affects outbound traffic.

Attributes Influencing Inbound Path Selection

AS-Path and MED: set outbound but affects inbound traffic.

Multipath Load Balancing

Multipath load balancing for external links with unequal bandwidth capacity; enabled under IPv4, IPv6, VPNv4 and VRF address families as well as for iBGP, eBGP, eiBGP. However, still only one best path is advertised to peers.

Loop Prevention

AS_PATH

In addition of being used in best path selection, the AS_PATH attribute is used for loop prevention. AS_PATH is a well-known mandatory attribute and includes a complete list of all ASNs that the prefix advertisement has traversed from its source AS. The source autonomous system is the furthest to the right of the AS_PATH attribute and the most recent to the left. AS_PATH is used as a loop prevention mechanism in BGP. If a BGP router receives a prefix advertisement with its AS listed in the AS_PATH attribute, it discards the prefix because the router thinks the advertisement forms a loop. This behaviour can be modified using the BGP command neighbor <ip-address> allowas-in or as-override.

AS-Path must not contain Local-AS

Normal EBGP loop prevention. Can be disabled with allow-as in.

BGP Equal-Cost Multipath

BGP advertises only one best path but it allows for the installation of multiple paths into the RIB. BGP supports equal-cost multipaths and unequal cost multipathing through the configuration of BGP Link Bandwidth. BGP multipathing has three different variances in behaviour: eBGP multipath, iBGP multipath, eBGP and iBGP multipath (eiBGP). eiBGP is traditionally used in service providers with Layer 3 VPNs. Enabling BGP multipathing does not alter the best-path algorithm or change the behaviour of paths advertisement to other BGP peers. Only the BGP best path is advertised to peers.

To become a candidate for multipath i.e., paths to the same destination, the following path attributes need to have the same values:

• Origin
• AS PATH length
• Neighboring AS or sub-AS (in the case of confederations)
• Weight
• MED

eBGP Equal Cost Multipath

eBGP multipath is enabled on IOS routers with the address-family command: maximum-paths <1-32>. Up to 32 multipaths are supported on some IOS versions. To qualify for multipath, eBGP paths need to match the following path attributes of the best path:

• Weight
• Local Preference
• AS Path length
• AS_PATH content (although confederations can contain a different AS_CONFED_SEQ path)
• Origin
• MED
• The IGP metric to the BGP next hop must be equal to the best path IGP metric.
• The path should have been learned from an eBGP peer or confederation external peer.

If the paths do not match the mentioned characteristics, then they are not eligible for multipathing.

R9(config-router-af)#do show bgp ipv4 unicast 10.7.10.0
BGP routing table entry for 10.7.10.0/24, version 148
Paths: (3 available, best #3, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  65538 65539 65536
    10.10.10.1 from 10.10.10.1 (10.10.13.1)
      Origin IGP, localpref 100, valid, external
  Refresh Epoch 1
  65000 65536
    3.3.3.3 from 3.3.3.3 (10.3.10.1)
      Origin IGP, localpref 100, valid, external
  Refresh Epoch 1
  65000 65536
    1.1.1.1 from 1.1.1.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, external, best
R9(config-router-af)#
R9(config-router-af)#do show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 3.3.3.3, 00:00:35
      5.0.0.0/32 is subnetted, 1 subnets
B        5.5.5.5 [20/0] via 1.1.1.1, 00:00:35
      6.0.0.0/32 is subnetted, 1 subnets
B        6.6.6.6 [20/0] via 1.1.1.1, 00:00:35
      10.0.0.0/8 is variably subnetted, 64 subnets, 3 masks
B        10.1.10.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.1.11.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.1.12.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.1.13.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.2.8.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.9.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.10.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.11.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.12.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.13.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.14.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.15.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.2.16.0/24 [20/0] via 3.3.3.3, 00:00:35
B        10.3.5.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.3.6.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.3.7.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.3.8.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.3.9.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.3.10.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.4.10.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.4.11.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.4.12.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.4.13.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.1.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.2.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.10.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.11.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.12.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.13.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.14.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.5.15.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.6.10.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.6.11.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.6.12.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.6.13.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.6.14.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.6.15.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.7.10.0/24 [20/0] via 1.1.1.1, 00:00:35
B        10.8.10.0/24 [20/0] via 10.10.10.1, 00:46:49
B        10.8.11.0/24 [20/0] via 10.10.10.1, 00:46:49
B        10.10.9.0/24 [20/0] via 10.10.10.1, 00:55:30
B        10.10.11.0/24 [20/0] via 10.10.10.1, 00:55:30
B        10.10.12.0/24 [20/0] via 10.10.10.1, 00:55:30
B        10.10.13.0/24 [20/0] via 10.10.10.1, 00:55:30
B        10.12.1.0/30 [20/0] via 3.3.3.3, 00:00:35
B        10.24.1.0/30 [20/0] via 3.3.3.3, 00:00:35
B        10.67.1.0/30 [20/0] via 1.1.1.1, 00:00:35
B        10.78.1.0/30 [20/0] via 1.1.1.1, 00:00:35
B        10.108.1.0/30 [20/0] via 10.10.10.1, 00:55:30
R9(config-router-af)#do show ip cef 10.7.10.0
10.7.10.0/24
  nexthop 10.19.1.1 GigabitEthernet1/0



R9(config)#router bgp 65512
R9(config-router-af)#address-family ipv4 unicast
R9(config-router-af)#maximum-paths 10


R9(config-router-af)#do show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 3.3.3.3, 00:00:07
                 [20/0] via 1.1.1.1, 00:00:07
      5.0.0.0/32 is subnetted, 1 subnets
B        5.5.5.5 [20/0] via 3.3.3.3, 00:00:07
                 [20/0] via 1.1.1.1, 00:00:07
      6.0.0.0/32 is subnetted, 1 subnets
B        6.6.6.6 [20/0] via 3.3.3.3, 00:00:07
                 [20/0] via 1.1.1.1, 00:00:07
      10.0.0.0/8 is variably subnetted, 64 subnets, 3 masks
B        10.1.10.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.1.11.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.1.12.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.1.13.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.2.8.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.2.9.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.2.10.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.2.11.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.2.12.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.2.13.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.2.14.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.2.15.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.2.16.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.3.5.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.3.6.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.3.7.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.3.8.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.3.9.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.3.10.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.4.10.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.4.11.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.4.12.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.4.13.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.5.1.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.5.2.0/24 [20/0] via 3.3.3.3, 00:00:06
                     [20/0] via 1.1.1.1, 00:00:06
B        10.5.10.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.5.11.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.5.12.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.5.13.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.5.14.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.5.15.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.6.10.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.6.11.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.6.12.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.6.13.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.6.14.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.6.15.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.7.10.0/24 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.8.10.0/24 [20/0] via 10.10.10.1, 00:45:23
B        10.8.11.0/24 [20/0] via 10.10.10.1, 00:45:23
B        10.10.9.0/24 [20/0] via 10.10.10.1, 00:54:04
B        10.10.11.0/24 [20/0] via 10.10.10.1, 00:54:04
B        10.10.12.0/24 [20/0] via 10.10.10.1, 00:54:04
B        10.10.13.0/24 [20/0] via 10.10.10.1, 00:54:04
B        10.12.1.0/30 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.24.1.0/30 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.67.1.0/30 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.78.1.0/30 [20/0] via 3.3.3.3, 00:00:06
                      [20/0] via 1.1.1.1, 00:00:06
B        10.108.1.0/30 [20/0] via 10.10.10.1, 00:54:04

R9(config-router-af)#do show ip cef 10.7.10.0
10.7.10.0/24
  nexthop 10.19.1.1 GigabitEthernet1/0
  nexthop 10.39.1.1 GigabitEthernet3/0

R9(config-router-af)#do show bgp ipv4 unicast 10.7.10.0
BGP routing table entry for 10.7.10.0/24, version 194
Paths: (3 available, best #3, table default)
Multipath: eBGP
  Advertised to update-groups:
     1
  Refresh Epoch 1
  65538 65539 65536
    10.10.10.1 from 10.10.10.1 (10.10.13.1)
      Origin IGP, localpref 100, valid, external
  Refresh Epoch 1
  65000 65536
    3.3.3.3 from 3.3.3.3 (10.3.10.1)
      Origin IGP, localpref 100, valid, external, multipath(oldest)
  Refresh Epoch 1
  65000 65536
    1.1.1.1 from 1.1.1.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, external, multipath, best
R9(config-router-af)#


iBGP Multipath

iBGP multipath is enabled with the address-family command: maximum-paths ibgp <1-32>. To become candidate for iBGP multipath, iBGP paths need to match the best path path attributes:

• Weight
• Local Preference
• AS Path length
• AS_PATH content (although confederations can contain a different AS_CONFED_SEQ path)
• Origin
• MED
• IGP metric to the BGP next hop must be equal to the best path IGP metric, unless the router is configured for unequal cost iBGP multipath.
• The path must have been received from an iBGP peer

eiBGP MultiPath

eiBGP multipath is configured using the command maximum-paths eibgp.

iBGP Scalability

In a bid to prevent the formation of loops, prefixes received from an iBGP peer cannot be advertised to another iBGP peer. To scale iBGP so that prefixes are advertised across the autonomous-system to other iBGP peers, the following options are available:

• Full-mesh configuration
• Route reflectors
• BGP confederations.

You do not have to select one design over another; one implementation would consist of a full mesh in one section of the network for path diversity and inter-cluster route reflectors for scaling in another section of the network. Both route reflection and confederations accomplish the same goal; iBGP scalability. Migration to a confederation is more complicated, however, greenfield confederation is easier. Migration to route reflection is easier.

iBGP Full Mesh

iBGP peers do not prepend their ASN to the AS-Path because the NLRI would fail the validity check and would not install the prefix into the Loc-RIB and RIB. iBGP rules prohibit the advertisement of an NLRI received from an iBGP peer to another iBGP peer. This is how iBGP prevents the formation of loops. In order to maintain a loop-free topology without traffic blackholing in iBGP, one technique is to configure all iBGP peers to form a full-mesh neighborship with each other. A full mesh is required to be created so that iBGP peers can overcome this split-horizon restriction.

Full mesh design advantages:

• Path diversity: all BGP peers learn all possible egress paths.
• Optimal traffic flows: all BGP peers learn the closest egress path. Path selection, by default, would be based on IGP metric to the egress router i.e. hot potato routing.

The configuration of a full-mesh iBGP peering in a large autonomous system is a monstrous task and is not a recommended best practice. However, the use of peer groups can help reduce the administrative challenge of a full-mesh iBGP network. Key disadvantages of full mesh designs include the following:

• Control plane scaling is exponential: the number of peerings for a full mesh is determined by the formula
  n * (n - 1) ÷ 2
  . Given 10 routers = 45 peerings, 100 routers = 4950 peerings.
• Operationally hard to scale: adding or modifying peering configuration is administratively prohibitive.

Route Reflectors

Route reflectors enable iBGP peers to advertise prefixes without the need to form full-mesh iBGP neighborships. Route reflectors are configured per address family; a route reflector for the IPv4 address family will not act as a route reflector for the IPv6 address family unless it is configured explicitly for this purpose. The BGP device that is reflecting prefixes is known as a route reflector (RR). Route reflectors are defined by RFC 1966 and updated by RFC 4456. Through route reflectors, BGP devices are able to advertise prefixes to iBGP peers by "reflecting" the prefixes; the RR only reflects its best path. Route reflection eliminates the need for full mesh. iBGP peers only need to peer with the route reflector. This is similar in context to the operation of the OSPF designated router (DR) where updates are sent to the RR which then sends the update to route reflector clients. The RR does not modify other attributes when reflecting routes. The BGP device that is receiving reflected prefixes is referred to as a route reflector client (RRC). A route reflector will not modify the next-hop ip address for the routes that are advertised from iBGP peers. In more recent BGP designs, the RR does not have to be in the data path.

A route reflector can have three types of peers:

• eBGP peers
• iBGP client peers
• iBGP non-client peers

Route reflectors are guided by three rules:

1. Rule 1: If route reflector receives a prefix from a BGP peer that is not a route reflector client, the route reflector advertises the prefixes to a route reflector client (and eBGP peer). It does not advertise the prefixes to a non-route reflector client.
2. Rule 2: If a route reflector receives a prefix from a route reflector client, it advertises the prefixes to route reflector clients and non-route reflector clients (as well as eBGP peers).
3. Rule 3: If a route reflector receives a prefix from an eBGP peer. It advertises the prefix to route reflector clients and non-route reflector clients. Note: this update will also be sent to eBGP peers.

The placement of the RR in the topology should be guided by these rules.

The operation of route reflectors (RR), in effect, ignore the iBGP split horizon rule. BGP Route reflection is a BGP policy command and so it is configured under the address-family and is configured only on route reflector devices with the address-family command neighbor <ip-address | peer-group-name> route-reflector-client.

R2(config)#router bgp 65000
R2(config-router)#neighbor AS65000 peer-group
R2(config-router)#neighbor 1.1.1.1 remote-as 65000
R2(config-router)#neighbor 1.1.1.1 peer-group AS65000
R2(config-router)#neighbor 4.4.4.4 remote-as 65000
R2(config-router)#neighbor 4.4.4.4 peer-group AS65000
R2(config-router)#address-family ipv4 unicast
R2(config-router-af#neighbor AS65000 route-reflector-client
R2(config-router-af#neighbor 5.5.5.5 route-reflector-client


No further BGP configuration is applied to route-reflector clients. Unlike BGP confederations, implementing route reflectors does not affect the existing BGP sessions.

Both MED and IGP metrics may impact the BGP best path selection decisions. With certain route reflection technologies the route reflection approach may not yield the same route selection result as that of the full iBGP mesh approach. One way in which route selection can be configured to be similar to the path selection under full mesh topologies is by configuring the intra-cluster IGP metrics to be better than the inter-cluster IGP metrics, and maintaining full mesh within the cluster i.e. full mesh and route reflectors together.

Route reflectors are very critical devices when implementing iBGP scalability using route reflection; they have accurate information as they are the principle source of path information for other iBGP devices. Path attribute modification should be implemented on the route reflectors.

Developments in BGP

In more recent BGP topologies, virtual route reflectors are gaining prominence. These virtual route reflectors are usually virtual machines and share NLRI information in the autonomous system. These RRs are normally not present in the path of the traffic.

In iBGP topologies with route reflectors, a feature known as BGP selective route download exists. This feature allows a network administrator to selectively download some or none of the BGP routes into the RIB. The primary purpose of this feature is to suppress the unnecessary downloading of certain BGP routes to the RIB or FIB on a dedicated route reflector, which propagates BGP updates without carrying transit traffic. The feature thereby helps to maximize resources available and to improve routing scalability and convergence on the dedicated route reflector. This is useful if the dedicated route reflector does not have sufficient hardware resources.

Verification of Route Reflection

show ip protocols

The route reflector status of a BGP device can be verified by the command show ip protocols:

R2#show ip protocols | section bgp
Routing Protocol is "bgp 65000"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Route Reflector for address family IPv4 Unicast, 2 clients
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    1.1.1.1
    4.4.4.4
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance      Last Update
    1.1.1.1              200      01:17:53
    4.4.4.4              200      01:39:15
  Distance: external 20 internal 200 local 200
R2#

show bgp ipv4 unicast neighbor <ip-address>

The route reflector client status of the BGP peers can be verified by issuing the command: show bgp ipv4 unicast neighbor <peer-IP-address> on the route reflector:

R2#show bgp ipv4 unicast neighbor 1.1.1.1
BGP neighbor is 1.1.1.1, remote AS 65000, internal link
 Member of peer-group AS65000 for session parameters
  BGP version 4, remote router ID 10.1.13.1
  BGP state = Established, up for 01:59:44
  Last read 00:00:12, last write 00:00:14, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
  
  ...
   For address family: IPv4 Unicast
  Session: 1.1.1.1
  BGP table version 34, neighbor version 34/0
  Output queue size : 0
  Index 1, Advertise bit 0
  Route-Reflector Client
  1 update-group member
  AS65000 peer-group member
  Slow-peer detection is disabled
  ...


show bgp ipv4 unicast <prefix>

For BGP prefixes that have been received from a route reflector client, these prefixes are tagged as having been received from a route reflector client:

R2#show bgp ipv4 unicast 10.1.10.0
BGP routing table entry for 10.1.10.0/24, version 13
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  Local, (Received from a RR-client)
    1.1.1.1 (metric 2) from 1.1.1.1 (10.1.13.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
R2#

High Availability

A simple BGP topology with a single route reflector may not provide the high-availability requirement of autonomous systems. High availability can be provided by adding redundant route reflectors, nested route reflectors where route reflector clients are route reflectors themselves. These different route reflectors will have different route reflector IDs.

Route Reflector Loop Prevention

Route reflection relaxes the iBGP restrictions of loop prevention by permitting the advertisement of a prefix received from an iBGP peer to another iBGP peer. The design of route reflection poses the great risk of introducing routing loops. Nested route reflection with intra-cluster loops occuring on peerings between route reflector clients and inter-cluster loops occuring in connections between route reflector clients peering with route reflector clients of different route reflector clusters.

Route reflectors prevent loop formation through the use of the cluster-ID; an RR discards routes received with its own cluster-ID. Additionally, to prevent routing loop formation in iBGP, route reflectors set the ORIGINATOR_ID attribute to the router-ID of the RR client of prefixes received from the specific route reflector client. The client uses Originator-ID for loop prevention. Together with the CLUSTER_LIST path attribute, these two path attributes are used to guard against inter-cluster and intra-cluster loops from being formed. The ORIGINATOR_ID has a type code of 9 and CLUSTER_LIST has a type code of 10.

ORIGINATOR_ID

The ORIGINATOR_ID is an optional non-transitive BGP path attribute that is created by the first route reflector. Its value is set to the router ID of the BGP device that advertised the route into the autonomous system. If a prefix contains an ORIGINATOR_ID path attribute, this value is not to be overwritten. The ORIGINATOR_ID path attribute can be verified by issuing the command: show bgp ipv4 unicast <ip-address>

R2#show bgp ipv4 unicast 10.6.12.0
BGP routing table entry for 10.6.12.0/24, version 13
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 2
  Local, (Received from a RR-client)
    6.6.6.6 (metric 3) from 4.4.4.4 (10.4.13.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
       Originator: 10.6.15.1, Cluster list: 10.4.13.1
R2#

CLUSTER_LIST

CLUSTER_LIST is a non-transitive BGP attribute and its value is updated by the route reflector. This attribute is appended (not over-written) by the route reflector with its CLUSTER_ID which, by default, is the BGP router ID. If a route reflector receives a prefix with its CLUSTER ID in the CLUSTER_LIST attribute, the prefix will be discarded because it has been looped. The CLUSTER_LIST path attribute can be verified by the command: show bgp ipv4 unicast <ip-address>.

R1#show bgp ipv4 unicast 10.6.12.0
BGP routing table entry for 10.6.12.0/24, version 13
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    6.6.6.6 (metric 4) from 3.3.3.3 (10.3.10.1)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 10.6.15.1, Cluster list: 10.3.10.1, 10.5.15.1
  Refresh Epoch 2
  Local
    6.6.6.6 (metric 4) from 2.2.2.2 (10.2.16.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.6.15.1, Cluster list: 10.2.16.1, 10.4.13.1
R1#

The CLUSTER_ID can be set manually using the command bgp cluster-id <1 - 4294967294> where the cluster ID is a 32-bit quantity and may also be configured in the form of an IPv4 address. The cluster IDs can be viewed using the command show bgp ipv4 unicast cluster-ids

The following Wireshark capture of a BGP update packet shows the ORIGINATOR_ID and the CLUSTER_ID path attributes added to a prefix.

Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 101
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 42
    Path attributes
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: empty
        Path Attribute - NEXT_HOP: 6.6.6.6
        Path Attribute - MULTI_EXIT_DISC: 0
        Path Attribute - LOCAL_PREF: 100
        Path Attribute - CLUSTER_LIST: 10.4.13.1
            Flags: 0x80, Optional, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: CLUSTER_LIST (10)
            Length: 4
            Cluster List: 10.4.13.1
                Cluster ID: 10.4.13.1
        Path Attribute - ORIGINATOR_ID: 10.6.15.1
            Flags: 0x80, Optional, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: ORIGINATOR_ID (9)
            Length: 4
            Originator identifier: 10.6.15.1
    Network Layer Reachability Information (NLRI)
        10.6.1.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.1.0
        10.6.8.0/24
        10.6.9.0/24
        10.6.10.0/24
        10.6.11.0/24
        10.6.12.0/24
        10.6.13.0/24
        10.6.14.0/24
        10.6.15.0/24


Large Scale Route Reflection

Large scale BGP designs should not be serviced by a single RR. RR clusters allow redundancy and hierarchy. A cluster is defined by the clients an RR serves. RRs in the same cluster use the same cluster-ID. Per address-family RR pairs; this avoids the "fate sharing" of services.

Inter-cluster Peerings

Inter-cluster peerings between RRs can be client to non-client peerings; depending on redundancy design, there could be duplicate routes and more processing. However, loops are prevented by the cluster-ID. The cluster-ID is based on the Router-ID; by default, all route reflectors are in separate cluster. If the same cluster-ID is used on both clusters (i.e. both RRs), then they may not accept each other's updates.

Virtual Route Reflectors

RRs generally do not need to be in the data path. A high memory/CPU VM can serve as a RR. IOS-XRv, CSR1000v and Quagga can be used as virtual RRs. With virtual RR, there's no need to install the 900K+ routes in the RIB/FIB if the RR is not in the data path. The selective RIB download feature can be considered:

• It prevents BGP paths from being installed in the RIB/FIB.
• It is implemented using the BGP command table-map [route-map] filter.
• Scales to 20m+ VPNv4 routes.

Route Reflector Use Cases

The scaling of BGP topologies using RR can be carried out always. This is the recommended method of scaling iBGP. In hub and spoke topologies, the hub is a suitable candidate for configuration as a route reflectorbgp.

Confederations

BGP confederations are another way in which iBGP can be scaled. Defined by RFC 3065, BGP confederations split the autonomous system into smaller sub-autonomous systems known as member autonomous systems that combine into a larger autonomous system known as autonomous system confederation. Inside the sub-AS, full mesh or RR can be implemented. The peering between BGP routers in different sub-ASs acts like eBGP. eBGP peers have no knowledge that they are peering with a confederation and they reference the confederation identifier in their configuration. Confederations can be further scaled by performing route reflection inside a confederation. When advertising to eBGP peers, sub-AS numbers are stripped from the updates messages.

Confederations are configured using private autonomous system numbers i.e. 64512 - 65534. Different IGPs can be configured in each sub-AS with next-hop-self command configured on the Sub-AS border routers. Confederation eBGP peerings are created between each of the confederations. Confederation eBGP peering does not follow the all same rules of standard eBGP. Some changes occur in the operation of confederation eBGP peerings such as:

• BGP MED attribute is transitive to all other member ASs but does not leave the confederation.
• The LOCAL_PREF attribute is transitive to all other member autonomous systems but does not leave the confederation.
• The next-hop address for external confederation routes does not change as the route is exchanged between member autonomous systems.

To configure a BGP confederation:

Step 1: Initialize the BGP process with the global configuration command: router bgp <member_asn>

R4(config)#router bgp 65000
R4(config-router)#bgp router-id 4.4.4.4

Step 2: Identify the BGP confederation with the command bgp confederation identifier <asn>. This AS number will be known to external BGP peers i.e. peers not part of the confederation.

R4(config-router)#bgp confederation identifier 112

Step 3: On routers that directly peer with another member AS, identify the peering member AS with the command: bgp confederation peers <member_asn>. Configure BGP confederation peers as normal and then follow the normal BGP configuration guidelines for the remaining configuration.

R4(config-router)#bgp confederation peers 65500 64512

Entering the wrong confederation peers for a BGP peer in a different sub-confederation results in the following BGP notification messages and BGP adjacency change messages:

R7(config-router)#
*Dec 28 13:38:24.043: %BGP-3-NOTIFICATION: received from neighbor 2.2.2.2 active 2/2 (peer in wrong AS) 2 bytes 0070
R7(config-router)#
*Dec 28 13:38:24.047: %BGP_SESSION-5-ADJCHANGE: neighbor 2.2.2.2 IPv4 Unicast topology base removed from session BGP Notification received
R7(config-router)#
*Dec 28 13:38:26.411: %BGP-3-NOTIFICATION: received from neighbor 2.2.2.2 passive 2/2 (peer in wrong AS) 2 bytes 0070
R7(config-router)#
*Dec 28 13:38:26.415: %BGP_SESSION-5-ADJCHANGE: neighbor 2.2.2.2 IPv4 Unicast topology base removed from session BGP Notification received
R7(config-router)#bgp confederation peers
*Dec 28 13:38:33.243: %BGP-3-NOTIFICATION: received from neighbor 2.2.2.2 active 2/2 (peer in wrong AS) 2 bytes 0070
R7(config-router)#bgp confederation peers 6
*Dec 28 13:38:33.251: %BGP_SESSION-5-ADJCHANGE: neighbor 2.2.2.2 IPv4 Unicast topology base removed from session BGP Notification received


Entering the correct confederation peer autonomous system number will resolve this:

R7(config-router)#bgp confederation peers 65000 64512
*Dec 28 13:38:44.491: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

Step 4: Configure the neighbor. Note that for a peer in another confederation, it will form an eBGP session. If the exit interface address was sourced from another interface, such as a loopback, then remember to increment the TTL using ebgp-multihop keyword.

R4(config-router)#neighbor 7.7.7.7 remote-as 65500
R4(config-router)#neighbor 7.7.7.7 update-source loopback 0
R4(config-router)#neighbor 7.7.7.7 ebgp-multihop 2

Verification of BGP Confederation Configuration

BGP confederation configuration can be verified using various commands.

show ip protocols

R4#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "bgp 65000"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  BGP confederation consists of ASs: 64512 65500
  
  BGP confederation advertised as AS 112
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address FiltIn FiltOut DistIn DistOut Weight RouteMap
    6.6.6.6
    7.7.7.7
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance      Last Update
    6.6.6.6              200      00:02:49
    7.7.7.7              200      00:05:51
  Distance: external 20 internal 200 local 200

R4#

show bgp ipv4 unicast neighbor <ip-address>

R4#show bgp ipv4 unicast neighbor 7.7.7.7
BGP neighbor is 7.7.7.7, remote AS 65500, external link
  BGP version 4, remote router ID 7.7.7.7
  Neighbor under common administration
  BGP state = Established, up for 00:23:08
  Last read 00:00:05, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds

  .....



Loop Prevention in BGP Confederations

New path attributes were created to prevent loop formation such as AS_CONFED_SEQUENCE and AS_CONFED_SET. The following Wireshark packet capture of link traffic between R1 and R2 showing a BGP Update message with the AS_CONFED_SEQUENCE path attribute:

Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 129
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 38
    Path attributes
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: (65500 65000)
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: (65500 65000)
                Segment type: AS_CONFED_SEQUENCE (3)
                Segment length (number of ASN): 2
                AS4: 65500
                AS4: 65000
        Path Attribute - NEXT_HOP: 4.4.4.4
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 4.4.4.4
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100
    Network Layer Reachability Information (NLRI)
        10.5.1.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.1.0
        10.5.2.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.2.0
        10.5.10.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.10.0
        10.5.11.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.11.0
        10.5.12.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.12.0
        10.5.13.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.13.0
        10.5.14.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.14.0
        10.5.15.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.5.15.0
        10.6.1.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.1.0
        10.6.8.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.8.0
        10.6.9.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.9.0
        10.6.10.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.10.0
        10.6.11.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.11.0
        10.6.12.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.12.0
        10.6.13.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.13.0
        10.6.14.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.14.0
        10.6.15.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.6.15.0


The AS_CONFED_SEQUENCE attribute is used to prevent loops but is not used (counted) when choosing the shortest AS_PATH. It is contained in parenthesis. AS_CONFED_SEQUENCE is removed from AS_PATH when the route is advertised outside the confederation.

R1#show bgp ipv4 unicast
BGP table version is 41, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r i 9.9.9.9/32       9.9.9.9                  0    100      0 65512 i
 r>                   9.9.9.9                  0             0 65512 i
 *>  10.1.10.0/24     0.0.0.0                  0         32768 i
 *>  10.1.11.0/24     0.0.0.0                  0         32768 i
 *>  10.1.12.0/24     0.0.0.0                  0         32768 i
 *>  10.1.13.0/24     0.0.0.0                  0         32768 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 * i 10.5.1.0/24      4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.5.2.0/24      4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.5.10.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.5.11.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.5.12.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.5.13.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.5.14.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.5.15.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.1.0/24      4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.8.0/24      4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.9.0/24      4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.10.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.11.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.12.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.13.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.14.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.6.15.0/24     4.4.4.4                  0    100      0 (65500 65000) i
 *>i                  4.4.4.4                  0    100      0 (65500 65000) i
 * i 10.7.10.0/24     7.7.7.7                  0    100      0 (65500) i
 *>i                  7.7.7.7                  0    100      0 (65500) i
 * i 10.7.11.0/24     7.7.7.7                  0    100      0 (65500) i
 *>i                  7.7.7.7                  0    100      0 (65500) i
 * i 10.8.10.0/24     8.8.8.8                  0    100      0 (65500) i
 *>i                  8.8.8.8                  0    100      0 (65500) i
 * i 10.8.11.0/24     8.8.8.8                  0    100      0 (65500) i
 *>i                  8.8.8.8                  0    100      0 (65500) i
 * i 10.8.15.0/24     8.8.8.8                  0    100      0 (65500) i
 *>i                  8.8.8.8                  0    100      0 (65500) i
 * i 10.9.10.0/24     9.9.9.9                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 r i 10.19.1.0/30     9.9.9.9                  0    100      0 65512 i
 r>                   9.9.9.9                  0             0 65512 i
 * i 10.39.1.0/30     9.9.9.9                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 * i 10.109.1.0/30    9.9.9.9                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
R1#

The NLRI includes the fields confed-internal and confed-external based on whether the NLRI was received within the same member AS or a different one.

R1(config-router)#do show bgp ipv4 unicast 10.39.1.0
BGP routing table entry for 10.39.1.0/30, version 40
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     4
  Refresh Epoch 1
  65512, (Received from a RR-client)
    9.9.9.9 from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
  Refresh Epoch 1
  65512
    9.9.9.9 from 9.9.9.9 (10.9.13.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
R1(config-router)#
R1(config-router)#do show bgp ipv4 unicast 10.6.12.0
BGP routing table entry for 10.6.12.0/24, version 255
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3          4
  Refresh Epoch 1
  (65500 65000), (Received from a RR-client)
    4.4.4.4 (metric 4) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
R1(config-router)#


R3(config-router)#do show bgp ipv4 unicast 10.6.13.0
BGP routing table entry for 10.6.13.0/24, version 269
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          3
  Refresh Epoch 2
  (65500 65000)
    4.4.4.4 (metric 4) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      Originator: 2.2.2.2, Cluster list: 1.1.1.1
  Refresh Epoch 2
  (65500 65000)
    4.4.4.4 (metric 4) from 8.8.8.8 (8.8.8.8)
      Origin IGP, metric 0, localpref 100, valid, confed-external
R3(config-router)#

BGP Confederation Use Cases

Implementation of BGP confederations should be considered under extra-ordinary circumstances as its configuration results in the dropping of existing peer sessions. The potential scenarios under which confederations could be implemented include the following:

• Company acquisitions or mergers.
• Distributed administrative control of the same autonomous system i.e., where the single AS is sub-divided into based on department, geography and each sub-AS has its own administrative unit.

BGP Communities

BGP communities are an optional transitive BGP attribute that can traverse from autonomous system to autonomous system. A BGP community is a 32-bit value that can be included with a prefix in an update message. By default, BGP communities are not included in BGP update messages. It is a recommended best practice to enable the sending of BGP communities to peers during BGP configuration. BGP communities provide the capability to tag routes for the purpose of modifying BGP routing policy of upstream and downstream BGP devices. It is important to note that BGP does not have route-tag matching or setting support. BGP communities can be used to add common policies to large groups of prefixes. BGP communities are used to group prefixes together for:

1. Advertisement policy
2. Filtering policy
3. Best path selection policy

A custom BGP community value can be applied to a group of prefixes and subsequently, a policy can be set on any prefix that possesses that custom BGP community value. When prefixes are identified by tagging using a BGP community attribute, some policy can then be applied to these prefixes. One prefix can be tagged with many community values resulting in many policy actions taken on a prefix when the community values are evaluated.

BGP communities can be named and these names are locally significant i.e. within the autonomous system. However, by default, BGP communities are not advertised to BGP peers. The scope of the BGP community attribute can also be structured to be meaningful to a set of autonomous systems.

There are two types of BGP communities: standard and extended. Standard BGP communities are further classified as well-known and private communities.

• Well-known communities: all routers that are capable of sending or receiving BGP communities must implement well-known BGP communities.
• Private communities: community patterns can vary from organisation to organisation. BGP private communities do not need to be registered. They can be used for varying purposes in different autonomous systems; in one autonomous system, a specific BGP private community value can be used to signify geographic locations while in another autonomous system, it may signify a method of route advertisement.

A BGP community can be displayed in different formats:

1. Full 32-bit number (older format): can be displayed in decimal (0 - 4294967200) or Hex 0x0 - 0xFFFFFFA0. This format is not commonly used nowadays.
2. Two 16-bit numbers (new format): This new format with values in the range 0 - 65535 is usually represented in the form AA:NN where AA is the autonomous system number and NN is any number that can be used to represent a specific routing policy in the autonomous system. This may require documentation with some sort of code book that guides on what the number correlates to and the policy description of that policy. This can be contrasted with well-known communities that are known by their names i.e. No_Export, Local AS, No_Advertise.

Community values are denoted in decimal according to RFC 1997 by default. To display communities in AA:NN (new format) use the global configuration command: ip bgp-community new-format for ip bgp new-format.

Setting Communities

To set communities in a route-map, use the command set community {community-number [additive] [well-known-community] | none}. Setting of BGP communities values is not additive by default. BGP community values can be deleted by setting the value to none in a route-map.

Matching communities using Community Lists

BGP community values can be matched through the use of a community list. A community list can be configured through the following steps:

1. Configure a community list: The community list can be a standard list or an extended list.
   • Standard community list: matches community name or number:
     ip community-list 1 standard permit no-export

   • Extended community list: matches regular expression:
     ip community-list expanded AS100 permit 100:[0-9]+

2. Reference the configured community list from a route-map using the match community <community-list> statement:
   match community AS100

Matching using community lists adds to the extensive flexibility of BGP. For example if a prefix has several communities, and the requirement is to delete the "no-export" community from the list of communities in the path attribute;

1. Configure a community list: ip community list 1 permit no-export
2. Match the community in a route-map: match ip address prefix-list PL_XYZ
set comm-list 1 delete

If you use the set community <value>, all community values are removed. To maintain existing communities and then add new communities, use the additive keyword to append the new community values while maintaining any existing values. If no previous community values exist, the new community values are still added.

Sending BGP Communities

BGP communities can be appended, removed, or modified selectively as a prefix is advertised from device to device. Additionally, one prefix can have many BGP communities added.

Communities are enabled on a neighbor-by-neighbor basis with the BGP address-family configuration command: neighbor <ip-address> send-community [standard | extended | both]. If a keyword is not specified, standard communities are sent by default. Without configuration of this command, the BGP community path attribute is not included in BGP update messages for affected prefixes.

R1(config)#router bgp 64512
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#neighbor 2.2.2.2 send-community standard

Well-Known Communities

RFC 1997 defined a set of global communities (known as well-known communities) that use the community range 4,294,901,760 (0xFFFF0000) to 4,294,967,295 (0xFFFFFFFF). All routers that are capable of interpreting BGP communities must implement well-known communities. The following are the common well-known communities: Internet, No_Advertise, No_Export, Local-AS

INTERNET

Advertise the prefix to any BGP peer.

NO_ADVERTISE (0xFFFFFF02)

All NLRI received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers. The No-Advertise community indicates that prefixes should not be advertised to any BGP peer. The No_Advertise BGP community can be advertised from an upstream BGP peer or locally with an inbound policy. The No-Advertise community is set in the BGP Loc-RIB that affects outbound route advertisement. The No-Advertise community is set in a route-map with the command: set community no-advertise.

BGP routes that are set with the No_Advertise community can be displayed with the command show bgp ipv4 unicast community no-advertise.

NO_EXPORT (0xFFFFFF01)

All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself). The No-Export community prevents the advertisement of a route to any eBGP peer. If the router receiving the No-Export route is a confederation member, the route can be advertised to other sub autonomous systems in the confederation. It can also be used to affect the propagation of a prefix by a neighboring AS; particularly if the local AS eBGP device sends an update message with the NO_EXPORT community set. The No-Export community is set with the command in a route map set community no-export

R3(config)#route-map RM_NO_EXPORT_FROM_9.9.9.9 permit 10
R3(config-route-map)#set community no-export
R3(config-route-map)#exit
R3(config)#router bgp 64512
R3(config-router-af)#neighbor 9.9.9.9 route-map RM_NO_EXPORT_FROM_9.9.9.9 in
R3(config-router-af)#do clear bgp ipv4 unicast 9.9.9.9 in

The command show bgp <afi> <safi> community no-export shows all the BGP prefixes that contain the Local-AS community.

R3(config-router-af)#do show bgp ipv4 unicast community no-export
BGP table version is 516, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>  9.9.9.9/32       9.9.9.9                  0             0 65512 i
 r i                  1.1.1.1                  0    100      0 65512 i
 *>  10.9.10.0/24     9.9.9.9                  0             0 65512 i
 * i                  1.1.1.1                  0    100      0 65512 i
 * i 10.9.11.0/24     1.1.1.1                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 * i 10.9.12.0/24     1.1.1.1                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 * i 10.9.13.0/24     1.1.1.1                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 * i 10.9.14.0/24     1.1.1.1                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 * i 10.9.15.0/24     1.1.1.1                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 * i 10.9.16.0/24     1.1.1.1                  0    100      0 65512 i
 *>                   9.9.9.9                  0             0 65512 i
 *>  10.19.1.0/30     9.9.9.9                  0             0 65512 i
 * i                  1.1.1.1                  0    100      0 65512 i
 r>  10.39.1.0/30     9.9.9.9                  0             0 65512 i
 r i                  1.1.1.1                  0    100      0 65512 i
 *>  10.109.1.0/30    9.9.9.9                  0             0 65512 i
 * i                  1.1.1.1                  0    100      0 65512 i
R3(config-router-af)#

The following is a Wireshark packet capture of a BGP update sent by device R3 to device R8 containing a NO_EXPORT path attribute.

Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 118
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 47
    Path attributes
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: (64512) 65512
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: AS_PATH (2)
            Length: 12
            AS Path segment: (64512)
                Segment type: AS_CONFED_SEQUENCE (3)
                Segment length (number of ASN): 1
                AS4: 64512
            AS Path segment: 65512
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65512
        Path Attribute - NEXT_HOP: 9.9.9.9
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 9.9.9.9
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100
        Path Attribute - COMMUNITIES: NO_EXPORT
            Flags: 0xc0, Optional, Transitive, Complete
                1... .... = Optional: Set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: COMMUNITIES (8)
            Length: 4
            Communities: NO_EXPORT
    Network Layer Reachability Information (NLRI)
        9.9.9.9/32
            NLRI prefix length: 32
            NLRI prefix: 9.9.9.9
        10.9.10.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.9.10.0
        10.9.11.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.9.11.0
        10.9.12.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.9.12.0
        10.9.13.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.9.13.0
        10.9.14.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.9.14.0
        10.9.15.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.9.15.0
        10.9.16.0/24
            NLRI prefix length: 24
            NLRI prefix: 10.9.16.0
        10.19.1.0/30
            NLRI prefix length: 30
            NLRI prefix: 10.19.1.0
        10.39.1.0/30
            NLRI prefix length: 30
            NLRI prefix: 10.39.1.0
        10.109.1.0/30
            NLRI prefix length: 30
            NLRI prefix: 10.109.1.0


One of the several ways in which as AS can be prevented from becoming a transit AS is to set the NO_EXPORT community on prefixes that are not local to the AS.

NO_EXPORT_SUBCONFED (0xFFFFFF03)

The No-Export sub confed community known as the Local-AS community prevents the advertisement of a route outside of the local autonomous system. All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation). If the router receiving a route with the Local-AS community is a confederation member, the route can be advertised only within the Sub-AS (member-AS) and is not advertise between member autonomous systems. The Local-AS community is set within a route map with the command: set community local-as

The command show bgp ipv4 unicast community local-as shows all the BGP prefixes that contain the Local-AS community

Private Communities

Community patterns can vary from organisation to organisation. It does not need to be registered and can signify geographic locations for one autonomous system while signifying a method of route advertisement in another autonomous system.

Two simple concepts are involved with private communities:

1. Conditionally matching a prefix by community
2. Setting private BGP communities.

Conditionally-Matching Communities

Conditionally matching BGP communities allows for selection of routes based on the BGP communities within the route’s path attributes so that selective processing can occur in route maps. You display the entire BGP table by using the command show bgp ipv4 unicast detail and then manually select a route with a specific community. However, if the BGP community is known, you can display all the routes by using the command show bgp ipv4 unicast community <community>.

Conditionally matching requires the creation of a community list. A community list shares a similar structure to an ACL. It can be standard or expanded. The community list can be referenced by a number or name. Standard community lists are numbered 1 to 99 and match either well-known communities or a private community number i.e. (AS-number:16-bit number). Expanded community lists are numbered 100 to 500 and use regex patterns. The configuration syntax for a community list is: ip community-list [1-500 | standard <list_name> | expanded <list_name>>] [permit | deny] <community_pattern>

Community patterns can be one or multiple entries. If multiple communities are listed in the same entry, then all items must match i.e. considered a boolean AND. If a boolean OR function is desired, then just add multiple lines to the community list so that it is entered as a second Access Control Entity. The community list is then referenced in a route-map with the command match community [1 - 500]

A private BGP community can be set in a route-map by using the command: set community <bgp_community> [additive] By default, when you set a community, any existing communities are overwritten, but you can preserve them by using the optional additive keyword.

Verification of BGP Communities

show bgp ipv4 unicast neighbor <bgp-router-id>

R3#show bgp ipv4 unicast neighbor 8.8.8.8
BGP neighbor is 8.8.8.8, remote AS 65500, external link
  BGP version 4, remote router ID 8.8.8.8
  Neighbor under common administration
  BGP state = Established, up for 00:30:13
  Last read 00:00:47, last write 00:00:44, hold time is 180, keepalive interval is 60 secon
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability:
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:               10         17
    Keepalives:            33         30
    Route Refresh:          0          0
    Total:                 44         48
  Default minimum time between advertisement runs is 30 seconds
  
 For address family: IPv4 Unicast
  Session: 8.8.8.8
  BGP table version 121, neighbor version 121/0
  Output queue size : 0
  Index 16, Advertise bit 2
  16 update-group member
  Community attribute sent to this neighbor
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled

...

R3#

Extended Communities

Extended communities have a 64-bit length. It has a type value approach. Extended communities can be set for transitive or non-transitive capability. A common use of extended communities is for MPLS L3VPN specifically for route target (RT) community value for example: route-target both 65535:4294967295 , MPLS L2VPN, EIGRP Cost Community.

BGP Cost-Community

BGP cost community is a non-transitive extended community attribute that is advertised within the AS or to confederation peers only. The cost community feature allows you to customize the local route preference and influence the best path selection process by assigning cost values to specific routes. It influences BGP best path selection at the point of insertion: pre-bestpath point of insertion can be used and compares cost-community value before weight. The POI allows you to assign a preference to a specific path when multiple equal cost paths are available. If the POI is not valid for local best path selection, the cost community attribute is silently ignored. EIGRP as PE/CE protocol uses "pre-bestpath" cost community to encode composite metric into BGP.

GSHUT Community

The BGP Graceful Shutdown feature reduces or eliminates the loss of traffic along a link being shut down for maintenance. The goal of gracefully shutting down one or more BGP sessions is to minimize traffic loss during the planned shutdown and subsequent reestablishment of the sessions. GSHUT community is used in conjunction with the BGP graceful shutdown feature. Takes the restarting peer out of the data-path by modifying local preference; similar to IS-IS overload or OSPF Max metric LSA. Introduced on Cisco IOS XE Release 3.6S.

The GSHUT community attribute is applied to a neighbor specified by the neighbor shutdown graceful command, thereby gracefully shutting down the link in an expected number of seconds. The GSHUT community is always sent by the GSHUT initiator. The GSHUT community is specified in a community list, which is referenced by a route map and then used to make policy routing decisions. The GSHUT community can also be used in the show ip bgp community command to limit output to GSHUT routes

neighbor <ipv4-address | ipv6-address | peer-group-name> shutdown graceful <seconds> {community <value> [local-preference <value>] | local-preference <value>}

R5(config-router)#neighbor 3.3.3.3 shutdown graceful 360 local-preference 50
R5(config-router)#
*Oct 27 21:18:25.319:  Graceful Shutdown after 360 seconds for neighbor: 3.3.3.3
R5(config-router)#                                                  
R5(config-router)#                                                  
R5(config-router)#do show bgp ipv4 unicast neighbor 3.3.3.3          
BGP neighbor is 3.3.3.3,  remote AS 1000.1000, internal link        
  BGP version 4, remote router ID 30.255.3.129                      
  BGP state = Established, up for 00:52:45                          
  Last read 00:00:10, last write 00:00:17, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:                                                
    1 active, is not multisession capable (disabled)                
  Neighbor capabilities:                                            
    Route refresh: advertised and received(new)                      
    Four-octets ASN Capability: advertised and received              
    Address family IPv4 Unicast: advertised and received            
    Enhanced Refresh Capability: advertised and received            
    Multisession Capability:                                        
    Stateful switchover support enabled: NO for session 1            
  Message statistics:                                                
    InQ depth is 0                                                  
    OutQ depth is 0                                                  
                                                                    
                         Sent       Rcvd                            
    Opens:                  1          1                            
    Notifications:          0          0                            
    Updates:                2          7                            
    Keepalives:            58         59                            
    Route Refresh:          0          0                            
    Total:                 62         67                            
  Default minimum time between advertisement runs is 0 seconds      
  Graceful Shutdown Timer running, schedule to reset the peer in 00:05:43 seconds
  Graceful Shutdown Localpref set to 50                              
                                                                    
For address family: IPv4 Unicast                                    
  Session: 3.3.3.3                                                  
  BGP table version 36, neighbor version 1/36                        
  Output queue size : 0                                              
  Index 0, Advertise bit 0                                          
  Slow-peer detection is disabled                                    
  Slow-peer split-update-group dynamic is disabled                  
                                 Sent       Rcvd                    
  Prefix activity:               ----       ----                    
    Prefixes Current:               0         20 (Consumes 1280 bytes)
    Prefixes Total:                 0         20                    
    Implicit Withdraw:              0          0                    
    Explicit Withdraw:              0          0                    
    Used as bestpath:             n/a          8                    
    Used as multipath:            n/a          0                    
                                                                    
                                   Outbound    Inbound              
  Local Policy Denied Prefixes:    --------    -------              
    ORIGINATOR loop:                    n/a          3              
    Total:                                0          3              
  Number of NLRIs in the update sent: max 3, min 0                  
  Last detected as dynamic slow peer: never                          
  Dynamic slow peer recovered: never                                
  Refresh Epoch: 1                                                  
  Last Sent Refresh Start-of-rib: 00:00:17                          
  Last Sent Refresh End-of-rib: never                                
  Last Received Refresh Start-of-rib: never                          
  Last Received Refresh End-of-rib: never                            
                                       Sent       Rcvd              
        Refresh activity:              ----       ----              
          Refresh Start-of-RIB          1          0                
          Refresh End-of-RIB            0          0                
                                                                    
  Address tracking is enabled, the RIB does have a route to 3.3.3.3  
  Connections established 1; dropped 0                              
  Last reset never                                                  
  Transport(tcp) path-mtu-discovery is enabled                      
  Graceful-Restart is disabled                                      
Connection state is ESTAB, I/O status: 1, unread input bytes: 0      
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 5.5.5.5, Local port: 179                                
Foreign host: 3.3.3.3, Foreign port: 11698                          
Connection tableid (VRF): 0                                          
Maximum output segment queue size: 50                                
                                                                    
Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)
                                                                    
Event Timers (current time is 0x32B820):                            
Timer          Starts    Wakeups            Next                    
Retrans            61          0             0x0                    
TimeWait            0          0             0x0                    
AckHold            63         59             0x0                    
SendWnd             0          0             0x0                    
KeepAlive           0          0             0x0                    
GiveUp              0          0             0x0                    
PmtuAger            0          0             0x0                    
DeadWait            0          0             0x0                    
Linger              0          0             0x0                    
ProcessQ            0          0             0x0                    
                                                                    
iss: 1649500220  snduna: 1649501492  sndnxt: 1649501492              
irs: 1281202527  rcvnxt: 1281204214                                  
                                                                    
sndwnd:  15113  scale:      0  maxrcvwnd:  16384                    
rcvwnd:  16175  scale:      0  delrcvwnd:    209                    
                                                                    
SRTT: 1000 ms, RTTO: 1003 ms, RTV: 3 ms, KRTT: 0 ms                  
minRTT: 12 ms, maxRTT: 1000 ms, ACK hold: 200 ms                    
Status Flags: passive open, gen tcbs                                
Option Flags: nagle, path mtu capable                                
IP Precedence value : 6                                              
                                                                    
Datagrams (max data segment is 1460 bytes):                          
Rcvd: 125 (out of order: 0), with data: 64, total data bytes: 1686  
Sent: 125 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 61, total data bytes: 1271
                                                                    
Packets received in fast path: 0, fast processed: 0, slow path: 0  
fast lock acquisition failures: 0, slow path: 0                    
TCP Semaphore      0x6AAD3010  FREE                                  
R5(config-router)#

Using BGP Communities to Influence Best Path Selection

RFC 1998 provides guidelines for the application of the BGP community attribute in multihome routing and how to influence best path selection. The general idea is to prestage an inbound policy (using a route-map) to:

• Match on pre-defined communities
• Set Local preference
• Set other attributes

The result is that outbound community signaling affects outbound path selection on the other side. The appropriate LOCAL_PREFERENCE value is combined with the ASN in a community value e.g. ASN 100 and desired local pref of 90 results in a community value of 100:90.

To implement this feature, configure a community list:

1. Configure community-lists: ip community-list 1 permit 100:90 and ip community-list 2 permit 100:110.
2. Configure a route-map: For inbound policy: route-map BGP_IN
match community 1
set local-preference 90
match community 2
set local-community 110
route-map BGP_IN 30
3. Apply the route-map to the neighbor: neighbor 155.1.37.7 route-map BGP_IN in (on router R3).
4. To view the community values easier, in global mode,ip bgp-community new-format.

BGP Optimization

Optimization of BGP helps improve the performance of BGP through the configuration of:

• Peer groups or peer templates
• Prefix summarization
• Prefix filtering
• Failure detection using BFD
• CPU tuning and memory utilization

Peer Groups

Peer groups are defined to efficiently apply the same policies to multiple peers. They are useful when many neighbors have the same outbound policies. Updates are generated once per peer group. Peer groups simplify BGP configuration and reduce system resource use (CPU and memory) by grouping BGP peers together into BGP update groups. Configuration of multiple neighbors can be done in one place. BGP update groups enable a BGP device to perform outbound routing policy processing once and then replicate the update to all members. All members in the peer group are in the same update group and therefore must be of the same session type i.e. iBGP or eBGP but not mixed up.

BGP peer groups simplify BGP configuration when there are multiple routers assigned to a peer group. A BGP peer group is created through the following steps:

• Step 1: Create the peer group using the BGP router command neighbor <group_name> peer-group.
  R6(config-router)#neighbor AS65000 peer-group

• Step 2: Add BGP peers to the peer group using the command: neighbor <ip-address> peer-group <group_name>.
  R6(config-router)#neighbor 4.4.4.4 remote-as 65000
R6(config-router)#neighbor 5.5.5.5 remote-as 65000
R6(config-router)#neighbor 4.4.4.4 peer-group AS65000
R6(config-router)#neighbor 5.5.5.5 peer-group AS65000


• Step 3: All BGP parameters are configured using peer-group <group_name> in lieu of neighbor <ip-address>.

  R6(config-router)#neighbor AS65000 next-hop-self


BGP neighbors cannot be activated by a peer group name and must be activated for each address family by IP address (if the default IPv4 address family has been disabled).

The following actions can be implemented against a peer-group that will affect the peer-group's individual members:

1. Reset of BGP neighborship: This can be a soft reset or hard reset e.g. clear bgp ipv4 unicast peer-group AS65000 soft out.
2. Route-filtering using route-maps, distribute-lists and filter-lists.

Peer groups can be verified using the command show ip bgp update-group. If BGP peers share the same policy, then they are put in the same update-group.

Troubleshooting Peer Groups

When troubleshooting peer group issues, you need to take note of the following:

• The neighbor ip address was not associated with the configured peer group.
• The peer group is not configured correctly; what works for one neighbor might not work for the other.
• The route filter applied to the group is not appropriate for all the peers.
• If there are conflicting entries between the peer group and a specific neighbor statement, the neighbor statement wins.

Peer Templates

BGP peer templates are BGP configurations that can be applied to one or more BGP peers. BGP configurations can be categorized as session commands and policy commands.

• Session commands:
  • Affect the TCP session between BGP peers.
  • Can be global or per address family.
• Policy commands:
  • Per address family.

BGP peer templates can inherit configurations from other peer templates. If a conflict exists between an inherited configuration and the invoking peer template, the invoking template preempts the inherited value. There are two types of BGP peer templates: peer session templates and peer policy templates.

Peer session

Peer sessions can be used to implement BGP session configurations on a BGP session. Peer session templates are used to group and apply the configuration of general BGP session commands to peers that should have same session configuration. Peer session templates can be applied regardless of address families of the neighbors.

General session commands can be configured once in a peer session template and then applied to many neighbors through the direct application of a peer session template or through indirect inheritance from a peer session template. Peer session templates support direct and indirect inheritance. A BGP device can be configured with only one peer session template at a time, and that peer session template can contain only one indirectly inherited peer session template. A BGP device can directly inherit only one session template and can indirectly inherit up to seven additional peer session templates.

You define peer session template settings with the BGP configuration command template peer-session <template-name> and then enter any BGP session related configuration commands.

R6#configure terminal
R6(config)#router bgp 65000
R6(config-router)#template peer-session BGP_SESSION_TEMPLATE_AS65000
R6(config-router-stmp)#remote-as 65000
R6(config-router-stmp)#update-source loopback0
R6(config-router-stmp)#timers 30 90 60

The peer-session template can then be applied to a group of BGP peers using the inherit keyword in BGP router mode.

R6(config-router)#neighbor 4.4.4.4 inherit peer-session BGP_SESSION_TEMPLATE_AS65000
R6(config-router)#neighbor 5.5.5.5 inherit peer-session BGP_SESSION_TEMPLATE_AS65000

Verification of Peer Sessions

Configured peer sessions can be viewed using the command show bgp ipv4 unicast template peer-session. The following output shows an example of a the details of a configured peer session template.

R11#show bgp ipv4 unicast template peer-session
Template:PEER_SESS_1000, index:1
Local  policies:0x2000B1, Inherited polices:0x0
Locally  configured session commands:
  remote-as 1000.1000
  password is configured
  update-source Loopback255
  timers  70 210 140
  ha-mode graceful-restart
Inherited session commands:


R6#show bgp ipv4 unicast template peer-session
Template:BGP_SESSION_TEMPLATE_AS65000, index:1
Local policies:0xA1, Inherited polices:0x0
Locally configured session commands:
 remote-as 65000
 update-source Loopback0
 timers 30 90 60
Inherited session commands:

R6#

Peer policy

Peer policy templates are used to configure BGP policy commands for neighbors that belong to specific address families. Peer policy templates are configured once and then applied to many neighbors through the direct application of a peer policy template or through inheritance from peer policy templates. The configuration of peer policy templates simplifies the configuration of BGP policy commands that are applied to all neighbors within an autonomous system. Peer policy templates support inheritance. A directly applied peer policy template can directly or indirectly inherit configurations from up to seven peer policy templates. So, a total of eight peer policy templates can be applied to a neighbor or neighbor group.

BGP policy configuration commands that are configured only for a specific address family. You define peer policy template configurations with the BGP configuration command template peer-policy <template-name> and then enter any BGP address family–related configuration commands.

BGP peer policy templates are applied to a BGP peer in address-family mode using the inherit keyword.

R6(config-router)#template peer-policy BGP_POLICY_TEMPLATE_AS65000
R6(config-router-ptmp)#send-community both
R6(config-router-ptmp)#route-reflector-client
R6(config-router-ptmp)#exit
R6(config-router)#address-family ipv4 unicast
R6(config-router-af)#neighbor 4.4.4.4 inherit peer-policy BGP_POLICY_TEMPLATE_AS65000
R6(config-router-af)#neighbor 5.5.5.5 inherit peer-policy BGP_POLICY_TEMPLATE_AS65000


Peer-policies can be verified using the privileged mode command: show bgp ipv4 unicast template peer-policy

R6#show bgp ipv4 unicast template peer-policy
Template:BGP_POLICY_TEMPLATE_AS65000, index:1.
Local policies:0x20000008200, Inherited polices:0x0
Local disable policies:0x0, Inherited disable policies:0x0
Locally configured policies:
  route-reflector-client
  send-community both
Inherited policies:

R6#

Note: A BGP peer that is a member of a peer group cannot inherit configurations from a peer-policy template or peer-session template. BGP templates and BGP peer groups are mutually exclusive.

The peer session and peer policy templates configured for a BGP peer can be verified using the privileged mode command: show bgp ipv4 unicast neighbor <ip-address>

R6#show bgp ipv4 unicast neighbor 4.4.4.4
BGP neighbor is 4.4.4.4, remote AS 65000, internal link
 Inherits from template BGP_SESSION_TEMPLATE_AS65000 for session parameters
   BGP version 4, remote router ID 4.4.4.4
   Neighbor under common administration
   BGP state = Established, up for 01:44:19
   Last read 00:00:16, last write 00:00:05, hold time is 90, keepalive interval is 30 seconds
   Configured hold time is 90, keepalive interval is 30 seconds
   Minimum holdtime from neighbor is 60 seconds
   Neighbor sessions:
    1 active, is not multisession capable (disabled)
   Neighbor capabilities:
     Route refresh: advertised and received(new)
     Four-octets ASN Capability: advertised and received
     Address family IPv4 Unicast: advertised and received
     Enhanced Refresh Capability: advertised and received
     Multisession Capability:
     Stateful switchover support enabled: NO for session 1
   Message statistics:
     InQ depth is 0
     OutQ depth is 0
     
                          Sent       Rcvd
     Opens:                  1          1
     Notifications:          0          0
     Updates:                4          2
     Keepalives:           230        144
     Route Refresh:          0          0
     Total:                237        147
   Default minimum time between advertisement runs is 0 seconds
  
 For address family: IPv4 Unicast
  Session: 4.4.4.4
  BGP table version 65, neighbor version 65/0
  Output queue size : 0
  Index 3, Advertise bit 1
  Route-Reflector Client
  3 update-group member
  Inherits from template BGP_POLICY_TEMPLATE_AS65000
  Community attribute sent to this neighbor
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:              20          3 (Consumes 192 bytes)
    Prefixes Total:                32          3
    Implicit Withdraw:              9          0
    Explicit Withdraw:              3          0
    Used as bestpath:             n/a          3
    Used as multipath:            n/a          0
    
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:              8        n/a
    Invalid Path:                        14        n/a
    Total:                               22          0
  Number of NLRIs in the update sent: max 9, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: 01:44:19
  Last Sent Refresh End-of-rib: 01:44:19
  Refresh-Out took 0 seconds
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          1          0
          Refresh End-of-RIB            1          0
          
  Address tracking is enabled, the RIB does have a route to 4.4.4.4
  Connections established 2; dropped 1
  Last reset 01:44:19, due to RR client config change of session 1
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 6.6.6.6, Local port: 57887
Foreign host: 4.4.4.4, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x92DCB0):
Timer          Starts    Wakeups            Next
Retrans           233          0             0x0
TimeWait            0          0             0x0
AckHold           145        138             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger         5597       5596        0x92DF17
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss: 2305547986  snduna: 2305552744  sndnxt: 2305552744
irs: 1586087929  rcvnxt: 1586090809

sndwnd:  16023  scale:      0  maxrcvwnd:  16384
rcvwnd:  14978  scale:      0  delrcvwnd:   1406

SRTT: 1000 ms, RTTO: 1003 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 8 ms, maxRTT: 1000 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 377 (out of order: 0), with data: 146, total data bytes: 2879
Sent: 377 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 234, total data bytes: 4757

Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
TCP Semaphore 0x6B259A44 FREE
R6#


All BGP peers that inherit the same peer policy template are placed in the same update-group.

Route Summarization

BGP route summarization automatically summarizes prefixes on classful boundary, when no mask is provided when defining networks to be advertised using the BGP network command. BGP auto-summary is disabled by default.

BGP Aggregation

The hierarchy of a BGP topology is arbitrary; learning of routes in path vector protocols like BGP is similar to distance vector routing protocols i.e. you learn from your neighbor. This, therefore, implies that summarization can be implemented anywhere in the toplogy. The only requirement is that the subnet must exist in BGP table.

Network prefix summarization is extremely important with BGP due to the large number of network prefixes that BGP can hold. The Internet routing table has over 1,000,000 IPv4 prefixes (as at 1/1/2023). Summarization conserves router resources and accelerates best path calculation by reducing the size of the BGP table on downstream routers. Summarization provides the benefit of stability by hiding route flaps from downstream routers thereby reducing routing churn. Route summarization can reduce the size of the BGP table for Internet routers. The aggregated prefixes on the Internet reduce the routing table to 560,000 prefixes.

Two techniques exist for BGP route summarization: static and dynamic route summarization.

• Static: create a static route (point to interface null0 for loop prevention) for the prefix and advertise that prefix with the network statement.
• Dynamic: configure an aggregation network prefix. When valid component routes are present in the Loc-RIB, the router will create an aggregate prefix. For routes to be aggregated, they must be in the BGP table and not only in the routing table. Dynamic aggregation uses the command aggregate-address <network> <subnetmask> [summary-only] [as-set]. Additional command arguments include:
  • summary-only: suppress more specific routes
  • suppress-map: suppress subset of more specific routes
  • as-set: an ordered list of AS numbers and communities associated with the aggregate that is inherited from the component routes.
  • advertise-map: attributes of prefix or prefixes matched with advertised-map are inherited in aggregate address. When used in conjunction with as-set prevents a specific AS from being included in the AS_SET of the new aggregate and circumvents loop prevention.
  • attribute-map|route-map: used to modify attributes associated with aggregate address. When used in conjunction with as-set can set or remove attributes e.g. remove no-export community, add MED.
  • unsuppress-map: selectively advertises prefixes that were previously suppressed by aggregate-address.

In both methods, a new network prefix with a shorter prefix length is advertised into BGP. The summarizing router becomes the originator of the aggregate route because it is considered a new route. Dynamic aggregation does not suppress the component routes by default. The summary-only keyword is required to suppress the component prefixes. The suppressed component prefixes have a status code of 's' for suppressed in the BGP table. If component prefixes need to be advertised to some neighbors and not others, then do not use summary-only but filter the component prefix advertisement using a route filter.

Atomic Aggregate Attribute

Aggregated prefixes act like new BGP routes with a shorter prefix length. BGP path attributes like AS_PATH, MED and BGP communities are not included in the new BGP summary advertisement by default. A new path attribute is added to the summary prefix known as atomic aggregate. The atomic aggregate path attribute indicates that loss of path information has occurred during summarization. The atomic aggregate attribute has a type code of 6.

To inject the original BGP path information from the component routes, the as-set keyword is required. AS_PATH settings get copied into the AS_SET portion of AS_PATH of the aggregate prefix from smaller component routes. The new AS_PATH, which is included in brackets only counts as one hop.

AS_SET

To keep the BGP path information history, the optional as-set keyword may be used with the aggregate-address command. As the router generates the aggregate route, BGP attributes from the component aggregate routes are copied over to it. The AS_PATH settings from the original prefixes are stored in the AS_SET portion of AS_PATH. AS_SET, which is displayed within brackets, counts as only one AS hop, even if multiple ASs are listed.

R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#aggregate-address 10.1.0.0 255.255.0.0 summary-only
R1(config-router-af)#aggregate-address 10.1.0.0 255.255.0.0
R1(config-router-af)#exit
R1(config-router)#exit
R1(config)#ip prefix-list PL_10.1.0.0/16 seq 10 permit 10.1.0.0/16
R1(config)#ip prefix-list PL_10.1.0.0/16 seq 20 deny 10.1.0.0/17 le 32
R1(config)#router bgp 65000
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#neighbor 9.9.9.9 prefix-list PL_10.1.0.0/16 out
R1(config-router-af)#do clear bgp ipv4 unicast 9.9.9.9 out


On the eBGP peer R9:

R9(config-router-af)#do show bgp ipv4 unicast
BGP table version is 285, local router ID is 10.9.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop           Metric LocPrf Weight Path
 *m  2.2.2.2/32       1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 r>  3.3.3.3/32       1.1.1.1                                0 65000 i
 rm                   3.3.3.3                  0             0 65000 i
 *m  5.5.5.5/32       3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  6.6.6.6/32       3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *>  9.9.9.9/32       0.0.0.0                  0         32768 i
 *m  10.1.0.0/16      3.3.3.3                                0 65000 i
 *>                   1.1.1.1                  0             0 65000 i
 *m  10.1.10.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                  0             0 65000 i
 *m  10.1.11.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                  0             0 65000 i
 *m  10.1.12.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                  0             0 65000 i
 *m  10.1.13.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                  0             0 65000 i
 *m  10.2.8.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.9.0/24      1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.10.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.11.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.12.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.13.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.14.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.15.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.2.16.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *>  10.3.5.0/24      1.1.1.1                                0 65000 i
 *m                   3.3.3.3                  0             0 65000 i
 *>  10.3.6.0/24      1.1.1.1                                0 65000 i
 *m                   3.3.3.3                  0             0 65000 i
 *>  10.3.7.0/24      1.1.1.1                                0 65000 i
 *m                   3.3.3.3                  0             0 65000 i
 *>  10.3.8.0/24      1.1.1.1                                0 65000 i
 *m                   3.3.3.3                  0             0 65000 i
 *>  10.3.9.0/24      1.1.1.1                                0 65000 i
 *m                   3.3.3.3                  0             0 65000 i
 *>  10.3.10.0/24     1.1.1.1                                0 65000 i
 *m                   3.3.3.3                  0             0 65000 i
 *m  10.4.10.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.4.11.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.4.12.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.4.13.0/24     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *m  10.5.1.0/24      3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.5.2.0/24      3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.5.10.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.5.11.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.5.12.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.5.13.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.5.14.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.5.15.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.6.10.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.6.11.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.6.12.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.6.13.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.6.14.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *m  10.6.15.0/24     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *   10.7.10.0/24     10.10.10.1                             0 65538 65539 65536 i
 *m                   3.3.3.3                                0 65000 65536 i
 *>                   1.1.1.1                                0 65000 65536 i
 *   10.8.10.0/24     3.3.3.3                                0 65000 65536 65539 i
 *                    1.1.1.1                                0 65000 65536 65539 i
 *>                   10.10.10.1                             0 65538 65539 i
 *   10.8.11.0/24     3.3.3.3              0 65000 65536 65539 i
 *                    1.1.1.1              0 65000 65536 65539 i
 *>                   10.10.10.1              0 65538 65539 i
 *>  10.9.10.0/24     0.0.0.0 0         32768 i
 *>  10.10.9.0/24     10.10.10.1 0             0 65538 i
 r>  10.10.10.0/24    10.10.10.1 0             0 65538 i
 *>  10.10.11.0/24    10.10.10.1 0             0 65538 i
 *>  10.10.12.0/24    10.10.10.1 0             0 65538 i
 *>  10.10.13.0/24    10.10.10.1 0             0 65538 i
 *m  10.12.1.0/30     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *>  10.19.1.0/30     0.0.0.0                  0         32768 i
 *m  10.24.1.0/30     1.1.1.1                                0 65000 i
 *>                   3.3.3.3                                0 65000 i
 *>  10.39.1.0/30     0.0.0.0                  0         32768 i
 *m  10.67.1.0/30     3.3.3.3                                0 65000 i
 *>                   1.1.1.1                                0 65000 i
 *   10.78.1.0/30     10.10.10.1              0 65538 65539 i
 *m                   3.3.3.3              0 65000 65536 i
 *>                   1.1.1.1              0 65000 65536 i
 *>  10.108.1.0/30    10.10.10.1 0             0 65538 i
 *   10.109.1.0/30    10.10.10.1 0             0 65538 i
*>               0.0.0.0 0         32768 i
R9(config-router-af)#


 

R9(config-router-af)#do clear bgp ipv4 unicast 1.1.1.1 in
R9(config-router-af)#do show bgp ipv4 unicast
BGP table version is 331, local router ID is 10.9.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  2.2.2.2/32       3.3.3.3                                0 65000 i
 r>  3.3.3.3/32       3.3.3.3                  0             0 65000 i
 *>  5.5.5.5/32       3.3.3.3                                0 65000 i
 *>  6.6.6.6/32       3.3.3.3                                0 65000 i
 *>  9.9.9.9/32       0.0.0.0                  0         32768 i
 *m  10.1.0.0/16      3.3.3.3                                0 65000 i
 *>                   1.1.1.1                  0             0 65000 i
 *>  10.1.10.0/24     3.3.3.3                                0 65000 i
 *>  10.1.11.0/24     3.3.3.3                                0 65000 i
 *>  10.1.12.0/24     3.3.3.3                                0 65000 i
 *>  10.1.13.0/24     3.3.3.3                                0 65000 i
 *>  10.2.8.0/24      3.3.3.3                                0 65000 i
 *>  10.2.9.0/24      3.3.3.3                                0 65000 i
 *>  10.2.10.0/24     3.3.3.3                                0 65000 i
 *>  10.2.11.0/24     3.3.3.3                                0 65000 i
 *>  10.2.12.0/24     3.3.3.3                                0 65000 i
 *>  10.2.13.0/24     3.3.3.3                                0 65000 i
 *>  10.2.14.0/24     3.3.3.3                                0 65000 i
 *>  10.2.15.0/24     3.3.3.3                                0 65000 i
 *>  10.2.16.0/24     3.3.3.3                                0 65000 i
 *>  10.3.5.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.6.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.7.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.8.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.9.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.10.0/24     3.3.3.3                  0             0 65000 i
 *>  10.4.10.0/24     3.3.3.3                                0 65000 i
 *>  10.4.11.0/24     3.3.3.3                                0 65000 i
 *>  10.4.12.0/24     3.3.3.3                                0 65000 i
 *>  10.4.13.0/24     3.3.3.3                                0 65000 i
 *>  10.5.1.0/24      3.3.3.3                                0 65000 i
 *>  10.5.2.0/24      3.3.3.3                                0 65000 i
 *>  10.5.10.0/24     3.3.3.3                                0 65000 i
 *>  10.5.11.0/24     3.3.3.3                                0 65000 i
 *>  10.5.12.0/24     3.3.3.3                                0 65000 i
 *>  10.5.13.0/24     3.3.3.3                                0 65000 i
 *>  10.5.14.0/24     3.3.3.3                                0 65000 i
 *>  10.5.15.0/24     3.3.3.3                                0 65000 i
 *>  10.6.10.0/24     3.3.3.3                                0 65000 i
 *>  10.6.11.0/24     3.3.3.3                                0 65000 i
 *>  10.6.12.0/24     3.3.3.3                                0 65000 i
 *>  10.6.13.0/24     3.3.3.3                                0 65000 i
 *>  10.6.14.0/24     3.3.3.3                                0 65000 i
 *>  10.6.15.0/24     3.3.3.3                                0 65000 i
 *   10.7.10.0/24     10.10.10.1                             0 65538 65539 65536 i
 *>                   3.3.3.3                                0 65000 65536 i
 *   10.8.10.0/24     3.3.3.3                                0 65000 65536 65539 i
 *>                   10.10.10.1                             0 65538 65539 i
 *   10.8.11.0/24     3.3.3.3                                0 65000 65536 65539 i
 *>                   10.10.10.1                             0 65538 65539 i
 *>  10.9.10.0/24     0.0.0.0 0 32768 i
 *>  10.10.9.0/24     10.10.10.1 0 0 65538 i
 r>  10.10.10.0/24    10.10.10.1 0 0 65538 i
 *>  10.10.11.0/24    10.10.10.1 0 0 65538 i
 *>  10.10.12.0/24    10.10.10.1 0 0 65538 i
 *>  10.10.13.0/24    10.10.10.1 0 0 65538 i
 *>  10.12.1.0/30     3.3.3.3 0 65000 i
 *>  10.19.1.0/30     0.0.0.0 0 32768 i
 *>  10.24.1.0/30     3.3.3.3 0 65000 i
 *>  10.39.1.0/30     0.0.0.0 0 32768 i
 *>  10.67.1.0/30     3.3.3.3 0 65000 i
 *   10.78.1.0/30     10.10.10.1 0 65538 65539 i
 *>                   3.3.3.3 0 65000 65536 i
 *>  10.108.1.0/30    10.10.10.1 0 0 65538 i
 *   10.109.1.0/30    10.10.10.1 0 0 65538 i
 *>                   0.0.0.0 0 32768 i
R9(config-router-af)#
R9(config-router-af)#do show bgp ipv4 unicast 10.1.0.0
BGP routing table entry for 10.1.0.0/16, version 285
Paths: (2 available, best #2, table default)
Multipath: eBGP
  Advertised to update-groups:
     1
  Refresh Epoch 1
  65000, (aggregated by 65000 1.1.1.1)
    3.3.3.3 from 3.3.3.3 (10.3.10.1)
      Origin IGP, localpref 100, valid, external, atomic-aggregate, multipath(oldest)
  Refresh Epoch 2
  65000, (aggregated by 65000 1.1.1.1)
    1.1.1.1 from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, multipath, best
R9(config-router-af)# R9(config-router-af)#

Regular Expressions

Regular expressions are used for the following:

• String matching in show command outputs
• TCL/EEM scripting
• BGP AS-Path access lists
• BGP expanded community lists

The following command can be used to filter locally originated prefixes ip as-path access-list 1 permit ^$.

Route Filtering

BGP update filtering occurs on a per peer basis. Cisco IOS provides the following methods of filtering updates:

1. Distribute-lists
2. Prefix-list
3. Filter-lists
4. Route-maps

Filtering is implemented at inbound route policy state for incoming prefixes and outbound routing policy stage for outgoing updates. It is recommended to use a route-map to avoid an order of operations issue where for example a distribute-list and filter-list are applied to the same peer and it is not clear which is implemented first.

Distribute-list

Distribute-lists allow for the filtering of network prefixes on a neighbor-by-neighbor basis using standard or extended Access Control Lists (ACLs). They are configured in address-family mode: neighbor <ip-address> distribute-list <acl> [in | out].

R3(config)#do show bgp ipv4 unicast neighbor 9.9.9.9 advertised-routes
BGP table version is 68, local router ID is 10.3.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 *>  3.3.3.3/32       0.0.0.0                  0         32768 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 r>i 6.6.6.6/32       6.6.6.6                  0    100      0 i
 *>i 10.1.10.0/24     1.1.1.1                  0    100      0 i
 *>i 10.1.11.0/24     1.1.1.1                  0    100      0 i
 *>i 10.1.12.0/24     1.1.1.1                  0    100      0 i
 *>i 10.1.13.0/24     1.1.1.1                  0    100      0 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>  10.3.5.0/24      0.0.0.0                  0         32768 i
 *>  10.3.6.0/24      0.0.0.0                  0         32768 i
 *>  10.3.7.0/24      0.0.0.0                  0         32768 i
 *>  10.3.8.0/24      0.0.0.0                  0         32768 i
 *>  10.3.9.0/24      0.0.0.0                  0         32768 i
 *>  10.3.10.0/24     0.0.0.0                  0         32768 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>i 10.6.10.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.11.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.12.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.13.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.14.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.15.0/24     6.6.6.6                  0    100      0 i
 *>i 10.7.10.0/24     6.6.6.6              20000    100      0 65536 i
 *>i 10.8.10.0/24     6.6.6.6              20000    100      0 65536 65539 i
 *>i 10.8.11.0/24     6.6.6.6              20000    100      0 65536 65539 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.67.1.0/30     6.6.6.6                  0    100      0 i
 *>i 10.78.1.0/30     6.6.6.6              20000    100      0 65536 i

Total number of prefixes 48
R3(config)#

Prefix filtering using the distribute-list command can be implemented using the following commands:

Step 1: Create an access control list (ACL) with the list of prefixes to be permitted or denied:

R3(config)#ip access-list standard ACL_10.1.10.0
R3(config-std-nacl)#10 deny 10.1.10.0 0.0.0.255
R3(config-std-nacl)#11 deny 10.1.11.0 0.0.0.255
R3(config-std-nacl)#12 deny 10.1.12.0 0.0.0.255
R3(config-std-nacl)#13 deny 10.1.13.0 0.0.0.255
R3(config-std-nacl)#14 deny 10.1.14.0 0.0.0.255
R3(config-std-nacl)#20 permit any

Step 2: Apply the ACL to a peer using the distribute-list command:

R3(config)#router bgp 65000
R3(config-router)#address-family ipv4 unicast
R3(config-router-af)#neighbor 9.9.9.9 distribute-list ACL_10.1.10.0 out

Step 3: Reset the BGP session to enforce the prefix filtering:

R3(config-router-af)#do clear bgp ipv4 unicast 9.9.9.9 out

You can verify that the advertised routes do not include the routes filtered by the access control list.

R3(config-std-nacl)#do show bgp ipv4 unicast neighbor 9.9.9.9 advertised-routes
BGP table version is 68, local router ID is 10.3.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 *>  3.3.3.3/32       0.0.0.0                  0     32768 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 r>i 6.6.6.6/32       6.6.6.6                  0    100      0 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>  10.3.5.0/24      0.0.0.0                  0         32768 i
 *>  10.3.6.0/24      0.0.0.0                  0         32768 i
 *>  10.3.7.0/24      0.0.0.0                  0         32768 i
 *>  10.3.8.0/24      0.0.0.0                  0         32768 i
 *>  10.3.9.0/24      0.0.0.0                  0         32768 i
 *>  10.3.10.0/24     0.0.0.0                  0         32768 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>i 10.6.10.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.11.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.12.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.13.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.14.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.15.0/24     6.6.6.6                  0    100      0 i
 *>i 10.7.10.0/24     6.6.6.6              20000    100      0 65536 i
 *>i 10.8.10.0/24     6.6.6.6              20000    100      0 65536 65539 i
 *>i 10.8.11.0/24     6.6.6.6              20000    100      0 65536 65539 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.67.1.0/30     6.6.6.6                  0    100      0 i
 *>i 10.78.1.0/30     6.6.6.6              20000    100      0 65536 i
 
Total number of prefixes 44
R3(config-std-nacl)#


These prefixes can be confirmed from the BGP peer with ID 9.9.9.9:

R9#show bgp ipv4 unicast neighbor 3.3.3.3 received-routes
BGP table version is 46, local router ID is 10.9.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

       Network          Next Hop            Metric LocPrf Weight Path
 *     2.2.2.2/32       3.3.3.3                                0 65000 i
 r     3.3.3.3/32       3.3.3.3                  0             0 65000 i
 *     5.5.5.5/32       3.3.3.3                                0 65000 i
 *     6.6.6.6/32       3.3.3.3                                0 65000 i
 *     10.2.8.0/24      3.3.3.3                                0 65000 i
 *     10.2.9.0/24      3.3.3.3                                0 65000 i
 *     10.2.10.0/24     3.3.3.3                                0 65000 i
 *     10.2.11.0/24     3.3.3.3                                0 65000 i
 *     10.2.12.0/24     3.3.3.3                                0 65000 i
 *     10.2.13.0/24     3.3.3.3                                0 65000 i
 *     10.2.14.0/24     3.3.3.3                                0 65000 i
 *     10.2.15.0/24     3.3.3.3                                0 65000 i
 *     10.2.16.0/24     3.3.3.3                                0 65000 i
 *     10.3.5.0/24      3.3.3.3                  0             0 65000 i
 *     10.3.6.0/24      3.3.3.3                  0             0 65000 i
 *     10.3.7.0/24      3.3.3.3                  0             0 65000 i
 *     10.3.8.0/24      3.3.3.3                  0             0 65000 i
 *     10.3.9.0/24      3.3.3.3                  0             0 65000 i
 *     10.3.10.0/24     3.3.3.3                  0             0 65000 i
 *     10.5.1.0/24      3.3.3.3                                0 65000 i
 *     10.5.2.0/24      3.3.3.3                                0 65000 i
 *     10.5.10.0/24     3.3.3.3                                0 65000 i
 *     10.5.11.0/24     3.3.3.3                                0 65000 i
 *     10.5.12.0/24     3.3.3.3                                0 65000 i
 *     10.5.13.0/24     3.3.3.3                                0 65000 i
 *     10.5.14.0/24     3.3.3.3                                0 65000 i
 *     10.5.15.0/24     3.3.3.3                                0 65000 i
 *     10.6.10.0/24     3.3.3.3                                0 65000 i
 *     10.6.11.0/24     3.3.3.3                                0 65000 i
 *     10.6.12.0/24     3.3.3.3                                0 65000 i
 *     10.6.13.0/24     3.3.3.3                                0 65000 i
 *     10.6.14.0/24     3.3.3.3                                0 65000 i
 *     10.6.15.0/24     3.3.3.3                                0 65000 i
 *     10.12.1.0/30     3.3.3.3                                0 65000 i
 *     10.24.1.0/30     3.3.3.3                                0 65000 i
 *     10.67.1.0/30     3.3.3.3                                0 65000 i
 
Total number of prefixes 36


Extended Access Control Lists (ACLs)

Extended ACLs provide extensive filtering capability that is comparable to prefix-lists. Filtering using extended ACLs in BGP behave differently from the way they do in OSPF or EIGRP; the source section of the ACL maps to the prefix and the destination section of the extended ACL maps to the prefix-length.

The general structure of an extended ACL is: <sequence> <permit|deny> <protocol> <source-ip> <source-mask> <destination-ip> <destination-mask> . When applying an extended ACL to BGP, it can be interpreted as follows: <sequence> <permit|deny> <protocol> <prefix> <mask-to-desired-section-of-prefix> <prefix-length> <mask-to-desired-section-of-prefix> . The source mask can be used to match specific section of the IP address. The destination mask can be used to match a specific section of the subnet mask. For example, given the following prefix 100.100.100.0/24; to filter a prefix that begins with exactly 100.100 higher order bits, and the prefix length is 16-bits or greater, we permit the entry and block everything else: #access-list 100 permit ip 100.100.0.0 0.0.255.255 255.255.0.0 0.0.255.255.

When matching using standard ACLs, we match only the source address and source mask. The destination part of the extended ACL matches against the netmask. When used for BGP filtering, whatever is the source part of the address is matched against the prefix and the destination is matched against the netmask.

Given the following prefixes;

• 30.1.1.0/24, 30.1.2.0/24, ...,30.1.10.0/24,...
• 30.2.1.0/24, 30.2.2.0/24, ...,30.2.10.0/24,...
• 30.3.1.0/24, 30.3.2.0/24, ...,30.3.10.0/24,...
• 30.4.1.0/24, 30.4.2.0/24, ...,30.4.10.0/24,...
• 30.5.1.0/24, 30.5.2.0/24, ...,30.5.10.0/24,...
• 30.6.1.0/24, 30.6.2.0/24, ...,30.6.10.0/24,...

Aggregate prefixes can be configured with a subnet mask of 16 and advertised externally (out of the autonomous system) but the component prefixes are advertised internally. The extended access-list that can be configured to accomplish this goal is: 10 permit 0.0.0.0 255.255.0.0 host 255.255.0.0. The first two octets of the prefix and subnet mask are matched. This extended ACL can then be applied using a distribute-list.

R7>show bgp ipv4 unicast neighbor 30.255.6.6 routes
BGP table version is 513, local router ID is 77.255.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  30.1.0.0/16      30.255.6.6                             0 65537000 i
 *>  30.2.0.0/16      30.255.6.6                             0 65537000 i
 *>  30.3.0.0/16      30.255.6.6                             0 65537000 i
 *>  30.4.0.0/16      30.255.6.6                             0 65537000 i
 *>  30.5.0.0/16      30.255.6.6                             0 65537000 i
 *>  30.6.0.0/16      30.255.6.6               0             0 65537000 i
 *>  30.255.0.0/16    30.255.6.6               0             0 65537000 i

Total number of prefixes 7
R7>

Prefix-List

Prefix-lists allow the filtering of network prefixes on a neighbor-by-neighbor basis for a specific direction i.e. inbound or outbound. Compared to the access control lists, prefix-lists provide more fine-grained filtering. To apply filtering using prefix lists, in address-family mode, enter the command; neighbor <ip-address> prefix-list <prefix-list-name> [in | out].

The following steps guide with configuration of filtering using prefix-lists. The BGP device aggregates local prefixes but filters the more specific local prefixes from being advertised to an eBGP peer.

R1#show bgp ipv4 unicast neighbor 9.9.9.9 advertised-routes
BGP table version is 61, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 r>i 3.3.3.3/32       3.3.3.3                  0    100      0 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 r>i 6.6.6.6/32       6.6.6.6                  0    100      0 i
 *>  10.1.0.0/16      0.0.0.0                            32768 i
 *>  10.1.10.0/24     0.0.0.0                  0         32768 i
 *>  10.1.11.0/24     0.0.0.0                  0         32768 i
 *>  10.1.12.0/24     0.0.0.0                  0         32768 i
 *>  10.1.13.0/24     0.0.0.0                  0         32768 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>i 10.3.5.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.6.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.7.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.8.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.9.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.10.0/24     3.3.3.3                  0    100      0 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i       
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i       
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>i 10.6.10.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.11.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.12.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.13.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.14.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.15.0/24     6.6.6.6                  0    100      0 i
 *>i 10.7.10.0/24     6.6.6.6              20000    100      0 65536 i
 *>i 10.8.10.0/24     6.6.6.6              20000    100      0 65536 65539 i
 *>i 10.8.11.0/24     6.6.6.6              20000    100      0 65536 65539 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.67.1.0/30     6.6.6.6                  0    100      0 i
 *>i 10.78.1.0/30     6.6.6.6              20000    100      0 65536 i
 
Total number of prefixes 49

R9#show bgp ipv4 unicast neighbor 1.1.1.1 received-routes
BGP table version is 63, local router ID is 10.9.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  2.2.2.2/32       1.1.1.1                                0 65000 i
 r>  3.3.3.3/32       1.1.1.1                                0 65000 i
 *>  5.5.5.5/32       1.1.1.1                                0 65000 i
 *   6.6.6.6/32       1.1.1.1                                0 65000 i
 *>  10.1.0.0/16      1.1.1.1                  0             0 65000 i
 *>  10.1.10.0/24     1.1.1.1                  0             0 65000 i
 *>  10.1.11.0/24     1.1.1.1                  0             0 65000 i
 *>  10.1.12.0/24     1.1.1.1                  0             0 65000 i
 *>  10.1.13.0/24     1.1.1.1                  0             0 65000 i
 *>  10.2.8.0/24      1.1.1.1                                0 65000 i
 *>  10.2.9.0/24      1.1.1.1                                0 65000 i
 *>  10.2.10.0/24     1.1.1.1                                0 65000 i
 *>  10.2.11.0/24     1.1.1.1                                0 65000 i
 *>  10.2.12.0/24     1.1.1.1                                0 65000 i
 *>  10.2.13.0/24     1.1.1.1                                0 65000 i
 *>  10.2.14.0/24     1.1.1.1                                0 65000 i
 *>  10.2.15.0/24     1.1.1.1                                0 65000 i
 *>  10.2.16.0/24     1.1.1.1                                0 65000 i
 *>  10.3.5.0/24      1.1.1.1                                0 65000 i
 *>  10.3.6.0/24      1.1.1.1                                0 65000 i
 *>  10.3.7.0/24      1.1.1.1                                0 65000 i
 *>  10.3.8.0/24      1.1.1.1                                0 65000 i
 *>  10.3.9.0/24      1.1.1.1                                0 65000 i
 *>  10.3.10.0/24     1.1.1.1                                0 65000 i
 *   10.4.10.0/24     1.1.1.1                                0 65000 i
 *   10.4.11.0/24     1.1.1.1                                0 65000 i
 *   10.4.12.0/24     1.1.1.1                                0 65000 i
 *   10.4.13.0/24     1.1.1.1                                0 65000 i
 *>  10.5.1.0/24      1.1.1.1                                0 65000 i
 *>  10.5.2.0/24      1.1.1.1                                0 65000 i
 *>  10.5.10.0/24     1.1.1.1                                0 65000 i
 *>  10.5.11.0/24     1.1.1.1                                0 65000 i
 *>  10.5.12.0/24     1.1.1.1                                0 65000 i
 *>  10.5.13.0/24     1.1.1.1                                0 65000 i
 *>  10.5.14.0/24     1.1.1.1                                0 65000 i
 *>  10.5.15.0/24     1.1.1.1                                0 65000 i
 *   10.6.10.0/24     1.1.1.1                                0 65000 i
 *   10.6.11.0/24     1.1.1.1                                0 65000 i
 *   10.6.12.0/24     1.1.1.1                                0 65000 i
 *   10.6.13.0/24     1.1.1.1                                0 65000 i
 *   10.6.14.0/24     1.1.1.1                                0 65000 i
 *   10.6.15.0/24     1.1.1.1                                0 65000 i
 *   10.7.10.0/24     1.1.1.1                                0 65000 65536 i
 *   10.8.10.0/24     1.1.1.1                                0 65000 65536 65539 i
 *   10.8.11.0/24     1.1.1.1                                0 65000 65536 65539 i
 *>  10.12.1.0/30     1.1.1.1                                0 65000 i
 *>  10.24.1.0/30     1.1.1.1                                0 65000 i
 *   10.67.1.0/30     1.1.1.1                                0 65000 i
 *   10.78.1.0/30     1.1.1.1                                0 65000 65536 i
 
Total number of prefixes 49
R9#


Step 1: Create a prefix list

R1(config)#ip prefix-list PL_10.1.0.0/17 seq 10 deny 10.1.0.0/17 le 32
R1(config)#ip prefix-list PL_10.1.0.0/17 seq 20 permit 0.0.0.0/0 le 32

Step 2: Apply the prefix-list in routing policy on the BGP peer.

R1(config-router-af)#neighbor 9.9.9.9 prefix-list PL_10.1.0.0/17 out

Step 3: Reset the BGP neighborship.

R1(config-router-af)#do clear bgp ipv4 unicast 9.9.9.9 out

The Loc-RIB table of R1 and R9 after applying filtering using the prefix-list shows that prefixes 10.1.10.0/24, 10.1.11.0/24, 10.1.12.0/24 confirms that these component prefixes have been filtered. The aggregated prefix 10.1.0.0/16 is permitted by the prefix list and is therefore not filtered by BGP.

This may be an effective method of advertising aggregated prefixes to eBGP peers and filtering the component prefixes but advertising the component prefixes to iBGP peers as they are internal to the organization.

R1#show bgp ipv4 unicast neighbor 9.9.9.9 advertised-routes
BGP table version is 61, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 r>i 3.3.3.3/32       3.3.3.3                  0    100      0 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 r>i 6.6.6.6/32       6.6.6.6                  0    100      0 i
 *>  10.1.0.0/16      0.0.0.0                            32768 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>i 10.3.5.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.6.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.7.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.8.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.9.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.10.0/24     3.3.3.3                  0    100      0 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i       
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i       
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>i 10.6.10.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.11.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.12.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.13.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.14.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.15.0/24     6.6.6.6                  0    100      0 i
 *>i 10.7.10.0/24     6.6.6.6              20000    100      0 65536 i
 *>i 10.8.10.0/24     6.6.6.6              20000    100      0 65536 65539 i
 *>i 10.8.11.0/24     6.6.6.6              20000    100      0 65536 65539 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.67.1.0/30     6.6.6.6                  0    100      0 i
 *>i 10.78.1.0/30     6.6.6.6              20000    100      0 65536 i
 
Total number of prefixes 45

R9#show bgp ipv4 unicast neighbor 1.1.1.1 received-routes
BGP table version is 63, local router ID is 10.9.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  2.2.2.2/32       1.1.1.1                                0 65000 i
 r>  3.3.3.3/32       1.1.1.1                                0 65000 i
 *>  5.5.5.5/32       1.1.1.1                                0 65000 i
 *   6.6.6.6/32       1.1.1.1                                0 65000 i
 *>  10.1.0.0/16      1.1.1.1                  0             0 65000 i
 *>  10.2.8.0/24      1.1.1.1                                0 65000 i
 *>  10.2.9.0/24      1.1.1.1                                0 65000 i
 *>  10.2.10.0/24     1.1.1.1                                0 65000 i
 *>  10.2.11.0/24     1.1.1.1                                0 65000 i
 *>  10.2.12.0/24     1.1.1.1                                0 65000 i
 *>  10.2.13.0/24     1.1.1.1                                0 65000 i
 *>  10.2.14.0/24     1.1.1.1                                0 65000 i
 *>  10.2.15.0/24     1.1.1.1                                0 65000 i
 *>  10.2.16.0/24     1.1.1.1                                0 65000 i
 *>  10.3.5.0/24      1.1.1.1                                0 65000 i
 *>  10.3.6.0/24      1.1.1.1                                0 65000 i
 *>  10.3.7.0/24      1.1.1.1                                0 65000 i
 *>  10.3.8.0/24      1.1.1.1                                0 65000 i
 *>  10.3.9.0/24      1.1.1.1                                0 65000 i
 *>  10.3.10.0/24     1.1.1.1                                0 65000 i
 *   10.4.10.0/24     1.1.1.1                                0 65000 i
 *   10.4.11.0/24     1.1.1.1                                0 65000 i
 *   10.4.12.0/24     1.1.1.1                                0 65000 i
 *   10.4.13.0/24     1.1.1.1                                0 65000 i
 *>  10.5.1.0/24      1.1.1.1                                0 65000 i
 *>  10.5.2.0/24      1.1.1.1                                0 65000 i
 *>  10.5.10.0/24     1.1.1.1                                0 65000 i
 *>  10.5.11.0/24     1.1.1.1                                0 65000 i
 *>  10.5.12.0/24     1.1.1.1                                0 65000 i
 *>  10.5.13.0/24     1.1.1.1                                0 65000 i
 *>  10.5.14.0/24     1.1.1.1                                0 65000 i
 *>  10.5.15.0/24     1.1.1.1                                0 65000 i
 *   10.6.10.0/24     1.1.1.1                                0 65000 i
 *   10.6.11.0/24     1.1.1.1                                0 65000 i
 *   10.6.12.0/24     1.1.1.1                                0 65000 i
 *   10.6.13.0/24     1.1.1.1                                0 65000 i
 *   10.6.14.0/24     1.1.1.1                                0 65000 i
 *   10.6.15.0/24     1.1.1.1                                0 65000 i
 *   10.7.10.0/24     1.1.1.1                                0 65000 65536 i
 *   10.8.10.0/24     1.1.1.1                                0 65000 65536 65539 i
 *   10.8.11.0/24     1.1.1.1                                0 65000 65536 65539 i
 *>  10.12.1.0/30     1.1.1.1                                0 65000 i
 *>  10.24.1.0/30     1.1.1.1                                0 65000 i
 *   10.67.1.0/30     1.1.1.1                                0 65000 i
 *   10.78.1.0/30     1.1.1.1                                0 65000 65536 i
 
Total number of prefixes 45
R9#


Verification

R1#show bgp ipv4 unicast neighbor 9.9.9.9
BGP neighbor is 9.9.9.9, remote AS 65512, external link
  BGP version 4, remote router ID 10.9.13.1
  BGP state = Established, up for 00:33:23
  Last read 00:00:57, last write 00:00:23, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability:
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:               24         13
    Keepalives:            34         25
    Route Refresh:          0          1
    Total:                 63         40
  Default minimum time between advertisement runs is 30 seconds
  
 For address family: IPv4 Unicast
  Session: 9.9.9.9
  BGP table version 61, neighbor version 61/0
  Output queue size : 0
  Index 4, Advertise bit 1
  4 update-group member
  Outgoing update prefix filter list is PL_10.1.0.0/17
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:              45        13 (Consumes 832 bytes)
    Prefixes Total:                90        13
    Implicit Withdraw:             45         0
    Explicit Withdraw:             15         0
    Used as bestpath:             n/a        11
    Used as multipath:            n/a         0
    
     Outbound    Inbound
  Local Policy Denied Prefixes: --------    -------
    prefix-list 8 0
    AS_PATH loop: n/a 53
    Bestpath from this peer: 22 n/a
    Total: 30 53
  Number of NLRIs in the update sent: max 40, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: 00:11:04
  Last Sent Refresh End-of-rib: 00:11:04
  Refresh-Out took 0 seconds
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          2          0  
          Refresh End-of-RIB            2          0  
                                                      
  Address tracking is enabled, the RIB does have a route to 9.9.9.9
  Connections established 1; dropped 0
  Last reset never
  External BGP neighbor may be up to 2 hops away.
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 1.1.1.1, Local port: 15723
Foreign host: 9.9.9.9, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x200D38):          
Timer          Starts    Wakeups            Next  
Retrans            44          0             0x0  
TimeWait            0          0             0x0  
AckHold            34         30             0x0  
SendWnd             0          0             0x0  
KeepAlive           0          0             0x0  
GiveUp              0          0             0x0  
PmtuAger         1192       1191        0x200E65  
DeadWait            0          0             0x0  
Linger              0          0             0x0  
ProcessQ            0          0             0x0  
                                                  
iss: 1283527991  snduna: 1283530730  sndnxt: 1283530730
irs:  383559796  rcvnxt:  383561252              
                                                  
sndwnd:  15116  scale:      0  maxrcvwnd:  16384  
rcvwnd:  14929  scale:      0  delrcvwnd:   1455  
                                                  
SRTT: 997 ms, RTTO: 1021 ms, RTV: 24 ms, KRTT: 0 ms
minRTT: 8 ms, maxRTT: 1000 ms, ACK hold: 200 ms  
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 78 (out of order: 0), with data: 35, total data bytes: 1455
Sent: 80 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 46, total data bytes: 2738

Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x6B0FB630 FREE
R1#


Outbound Route Filters (ORF)

In the traditional approach to connecting the enterprise network to another autonomous system such as ISP, connectivity options include upstream provider sending a full BGP table, a default route only, or default route and some filtered routes. Normally, some complex view is not maintained. Inbound route filtering on the downstream neighbor is inefficient because we must receive the full view of the service provider's BGP table and process it via BGP before any filtering e.g. if we are interested in just 100 NLRI, we will still receive all the 900K routes and proccess them before we can extract the desired 100 routes. The outbound route filtering feature allows the downstream router to control what the upstream BGP peer is advertising to it. ORF is defined in RFC 5291 (outbound route filtering capacity for BGP-4). The downstream router sends the upstream provider a list of prefixes that it would like advertised to it. This is accomplished through the enterprise BGP router advertising a prefix-list upstream to the service provider's BGP router. This router then applies the prefix-list as a filter in the outbound direction to the enterprise. The service provider BGP peer does not send BGP Update messages (filters) containing prefixes that are not in the list.

ORF has the following features:

• ORF supports IPv4 and IPv6 unicast routes
• ORF does not support IP multicast routes.
• ORF can be used only with IP prefix-lists
• ORF has to be configured separately for every address family. It cannot be configured under the global BGP process.
• ORF is supported only over eBGP sessions.

When implementing ORF;

• On the upstream router;
  • Enable ORF capability for the downstream peer:
    R7(config)#router bgp 7
R7(config-router)#address-family ipv4 unicast
R7(config-router-af)#neighbor 30.255.6.6 capability orf prefix-list receive

    Note that the keyword receive is configured for the upstream peer.
• On the downstream BGP peer:
  1. Enable ORF for the BGP peer: neighbor <ip-address> capability orf prefix-list <both|receive|send>.
     R6(config)#router bgp 1000.1000
R6(config-router)#address-family ipv4 unicast
R6(config-router-af)#neighbor 77.255.7.7 capability orf prefix-list send


  2. Configure a prefix list:
     R6(config)#ip prefix-list PL_88.1.0.0/22 seq 10 permit 88.1.0.0/22 le 24

  3. Apply the prefix-list to the upstream peer in the inbound direction:
     R6(config-router-af)#neighbor 77.255.7.7 prefix-list PL_88.1.0.0/22 in

  4. Reset the BGP session:
     R6#clear ip bgp 77.255.7.7 soft in prefix-filter.

Verification of ORF

On the upstream BGP peer, ORF configuration can be confirmed using the command: show ip bgp neighbor <ip-address> received prefix-filter.

R7>show bgp ipv4 unicast neighbor 30.255.6.6 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 30.255.6.6: 1 entries
   seq 10 permit 88.1.0.0/22 le 24


On the downstream BGP peer, ORF can be confirmed by viewing configured policies:

R6>show bgp ipv4 unicast neighbor 77.255.7.7 policy
 Neighbor: 77.255.7.7, Address-Family: IPv4 Unicast
 Locally configured policies:
  prefix-list PL_88.1.0.0/22 in
  capability orf prefix-list send
 Inherited polices:
  route-map RM_EBGP in
  distribute-list ACL_AGGREGATES out
  send-community both
R6>

AS Path Access Control Lists

There may be times when conditionally matching network prefixes may be too complicated, and identifying all routes from a specific organization using autonomous system numbers (ASNs) is preferred. In such a scenario, AS_PATH access control lists can be used. AS_PATH filtering is accomplished using an AS Path Access Control List, which uses regular expressions for matching.

The following table shows regular expression characters that can be used in the AS Path ACLs:

Character	Usage
^	Start of string
$	End of string
[]	Range of characters
-	Used to specify range
()	Logical grouping
.	Any single character
*	Zero or more instances
+	One or more instances
?	Zero or more instances
_	Comma, open, or close brace, open or close parenthesis, start or end of string, or space

Examples:

Expression	Meaning
.*	Anything
^$	Locally originated routes
^100_	Learning from AS 100
_100$	Originated in AS 100
_100_	Any instance of AS 100
^[0-9]+$	Directly connected ASes

Filtering of prefixes from a BGP neighbor using the AS_PATH requires the definition of an AS_PATH ACL. Processing is performed in a sequential top-down order and the first qualifying match processes against the appropriate permit or deny action. An implicit deny exists at the end of the AS_PATH ACL. IOS supports up to 500 AS Path ACLs. This is useful for the enterprise that has more than one service provider and does not want to provide transit capability.

In the following configuration of AS Path ACLs, we will restrict the advertisement of prefixes to only locally generated prefixes i.e. to minimise the possibility of the autonomous system becoming a transit AS. The routes advertised by BGP devices R1 and R3 to eBGP peer R9 are displayed below:

R3(config#do show bgp ipv4 unicast neighbor 9.9.9.9 advertised-routes
BGP table version is 65, local router ID is 10.3.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 *>  3.3.3.3/32       0.0.0.0                  0         32768 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 r>i 6.6.6.6/32       6.6.6.6                  0    100      0 i
 *>i 10.1.0.0/16      1.1.1.1                  0    100      0 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>  10.3.5.0/24      0.0.0.0                  0         32768 i
 *>  10.3.6.0/24      0.0.0.0                  0         32768 i
 *>  10.3.7.0/24      0.0.0.0                  0         32768 i
 *>  10.3.8.0/24      0.0.0.0                  0         32768 i
 *>  10.3.9.0/24      0.0.0.0                  0         32768 i
 *>  10.3.10.0/24     0.0.0.0                  0         32768 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>i 10.6.10.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.11.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.12.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.13.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.14.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.15.0/24     6.6.6.6                  0    100      0 i
 *>i 10.7.10.0/24     6.6.6.6              20000    100      0 65536 i
 *>i 10.8.10.0/24     6.6.6.6              20000    100      0 65536 65539 i
 *>i 10.8.11.0/24     6.6.6.6              20000    100      0 65536 65539 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.67.1.0/30     6.6.6.6                  0    100      0 i
 *>i 10.78.1.0/30     6.6.6.6              20000    100      0 65536 i

Step 1: Create the AS Path access control list using the configuration command: ip as-path access-list <acl_num> [deny | permit] regex-query.

R3(config)#ip as-path access-list 1 permit ^$

The above regular expression matches locally advertised routes.

Step 2: To apply the AS_PATH ACL; neighbor <ip-address> filter-list <acl_num> [in | out].

R3(config)#router bgp 65000
R3(config-router)#address-family ipv4 unicast
R3(config-router-af)#neighbor 9.9.9.9 filter-list 1 out
R3(config-router-af)#end

Step 3: Reset the BGP session:

R3#clear bgp ipv4 unicast 9.9.9.9 out

View the advertised routes to the BGP peer:

R3(config#do show bgp ipv4 unicast neighbor 9.9.9.9 advertised-routes
BGP table version is 65, local router ID is 10.3.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 *>  3.3.3.3/32       0.0.0.0                  0         32768 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 r>i 6.6.6.6/32       6.6.6.6                  0    100      0 i
 *>i 10.1.0.0/16      1.1.1.1                  0    100      0 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>  10.3.5.0/24      0.0.0.0                  0         32768 i
 *>  10.3.6.0/24      0.0.0.0                  0         32768 i
 *>  10.3.7.0/24      0.0.0.0                  0         32768 i
 *>  10.3.8.0/24      0.0.0.0                  0         32768 i
 *>  10.3.9.0/24      0.0.0.0                  0         32768 i
 *>  10.3.10.0/24     0.0.0.0                  0         32768 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>i 10.6.10.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.11.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.12.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.13.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.14.0/24     6.6.6.6                  0    100      0 i
 *>i 10.6.15.0/24     6.6.6.6                  0    100      0 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.67.1.0/30     6.6.6.6                  0    100      0 i

R9#show bgp ipv4 unicast neighbor 3.3.3.3 received-routes
BGP table version is 64, local router ID is 10.9.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *   2.2.2.2/32       3.3.3.3                                0 65000 i
 r>  3.3.3.3/32       3.3.3.3                  0             0 65000 i
 *   5.5.5.5/32       3.3.3.3                                0 65000 i
 *   6.6.6.6/32       3.3.3.3                                0 65000 i
 *   10.1.0.0/16      3.3.3.3                                0 65000 i
 *   10.2.8.0/24      3.3.3.3                                0 65000 i
 *   10.2.9.0/24      3.3.3.3                                0 65000 i
 *   10.2.10.0/24     3.3.3.3                                0 65000 i
 *   10.2.11.0/24     3.3.3.3                                0 65000 i
 *   10.2.12.0/24     3.3.3.3                                0 65000 i
 *   10.2.13.0/24     3.3.3.3                                0 65000 i
 *   10.2.14.0/24     3.3.3.3                                0 65000 i
 *   10.2.15.0/24     3.3.3.3                                0 65000 i
 *   10.2.16.0/24     3.3.3.3                                0 65000 i
 *>  10.3.5.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.6.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.7.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.8.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.9.0/24      3.3.3.3                  0             0 65000 i
 *>  10.3.10.0/24     3.3.3.3                  0             0 65000 i
 *   10.4.10.0/24     3.3.3.3                                0 65000 i
 *   10.4.11.0/24     3.3.3.3                                0 65000 i
 *   10.4.12.0/24     3.3.3.3                                0 65000 i
 *   10.4.13.0/24     3.3.3.3                                0 65000 i
 *   10.5.1.0/24      3.3.3.3                                0 65000 i
 *   10.5.2.0/24      3.3.3.3                                0 65000 i
 *   10.5.10.0/24     3.3.3.3                                0 65000 i
 *   10.5.11.0/24     3.3.3.3                                0 65000 i
 *   10.5.12.0/24     3.3.3.3                                0 65000 i
 *   10.5.13.0/24     3.3.3.3                                0 65000 i
 *   10.5.14.0/24     3.3.3.3                                0 65000 i
 *   10.5.15.0/24     3.3.3.3                                0 65000 i
 *   10.6.10.0/24     3.3.3.3                                0 65000 i
 *   10.6.11.0/24     3.3.3.3                                0 65000 i
 *   10.6.12.0/24     3.3.3.3                                0 65000 i
 *   10.6.13.0/24     3.3.3.3                                0 65000 i
 *   10.6.14.0/24     3.3.3.3                                0 65000 i
 *   10.6.15.0/24     3.3.3.3                                0 65000 i
 *   10.12.1.0/30     3.3.3.3                                0 65000 i
 *   10.24.1.0/30     3.3.3.3                                0 65000 i
 *   10.67.1.0/30     3.3.3.3                                0 65000 i

Total number of prefixes 41

Route-map

Route-maps can be used to filter prefixes by referencing access control lists or prefix lists. Route-maps can also be used to manipulate prefix path attributes of routes matched by the referenced access control lists or prefix-lists. A different route map can be used for each direction.

The following configuration causes the BGP device R6 to not advertise prefixes 10.1.0.0 /17 and any subnets to its BGP peer 10.67.1.2. The following table shows the Loc-RIB table before the configuration of the route-map:

R6#show bgp ipv4 unicast neighbor 10.67.1.2 advertised-routes
BGP table version is 84, local router ID is 10.6.15.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 r>i 3.3.3.3/32       3.3.3.3                  0    100      0 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 *>  6.6.6.6/32       0.0.0.0                  0         32768 i
 *>i 9.9.9.9/32       3.3.3.3                  0    100      0 65512 i
 *>i 10.1.0.0/16      1.1.1.1                  0    100      0 i
 *>i 10.1.10.0/24     1.1.1.1                  0    100      0 i
 *>i 10.1.11.0/24     1.1.1.1                  0    100      0 i
 *>i 10.1.12.0/24     1.1.1.1                  0    100      0 i
 *>i 10.1.13.0/24     1.1.1.1                  0    100      0 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>i 10.3.5.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.6.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.7.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.8.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.9.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.10.0/24     3.3.3.3                  0    100      0 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>  10.6.10.0/24     0.0.0.0                  0         32768 i
 *>  10.6.11.0/24     0.0.0.0                  0         32768 i
 *>  10.6.12.0/24     0.0.0.0                  0         32768 i
 *>  10.6.13.0/24     0.0.0.0                  0         32768 i
 *>  10.6.14.0/24     0.0.0.0                  0         32768 i
 *>  10.6.15.0/24     0.0.0.0                  0         32768 i
 *>i 10.9.10.0/24     3.3.3.3                  0    100      0 65512 i
 *>i 10.10.9.0/24     3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.10.0/24    3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.11.0/24    3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.12.0/24    3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.13.0/24    3.3.3.3                  0    100      0 65512 65538 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.19.1.0/30     3.3.3.3                  0    100      0 65512 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.39.1.0/30     3.3.3.3                  0    100      0 65512 i
 *>  10.67.1.0/30     0.0.0.0                  0         32768 i
 *>i 10.109.1.0/30    3.3.3.3                  0    100      0 65512 i

Total number of prefixes 55

Step 1: Create a prefix list or access control list to identify prefixes to be filtered.

R6(config)#ip prefix-list PL_10.1.0.0/17 seq 10 deny 10.1.0.0/17 le 32
R6(config)#ip prefix-list PL_10.1.0.0/17 seq 20 permit 0.0.0.0/0 le 32


Step 2: Reference the prefix list or access control list with the route-map. In this case, we reference the prefix list created in step 1.

R6(config)#route-map RM_DENY_10.1.0.0/17 permit 10
R6(config-route-map)#match ip address prefix-list PL_10.1.0.0/17
R6(config-route-map)#exit

Step 3: Associate with route-map with the BGP peer. The route map is associated to a BGP neighbor with the command: neighbor <ip-address> route-map <RM_name> [in | out] under the address-family mode.

R6(config)#router bgp 65000
R6(config-router)#address-family ipv4 unicast
R6(config-router-af)#neighbor 10.67.1.2 route-map RM_DENY_10.1.0.0/17 out


Step 4: Reset the BGP session:

R6#clear bgp ipv4 unicast 10.67.1.2 out

The list of advertised routes to the BGP peer 10.67.1.2 confirms that the prefixes 10.1.0.0/17 - 32 have been filtered by the route-map.

R6#show bgp ipv4 unicast neighbor 10.67.1.2 advertised-routes
BGP table version is 84, local router ID is 10.6.15.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 2.2.2.2/32       2.2.2.2                  0    100      0 i
 r>i 3.3.3.3/32       3.3.3.3                  0    100      0 i
 r>i 5.5.5.5/32       5.5.5.5                  0    100      0 i
 *>  6.6.6.6/32       0.0.0.0                  0         32768 i
 *>i 9.9.9.9/32       3.3.3.3                  0    100      0 65512 i
 *>i 10.1.0.0/16      1.1.1.1                  0    100      0 i
 *>i 10.2.8.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.9.0/24      2.2.2.2                  0    100      0 i
 *>i 10.2.10.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.11.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.12.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.13.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.14.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.15.0/24     2.2.2.2                  0    100      0 i
 *>i 10.2.16.0/24     2.2.2.2                  0    100      0 i
 *>i 10.3.5.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.6.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.7.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.8.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.9.0/24      3.3.3.3                  0    100      0 i
 *>i 10.3.10.0/24     3.3.3.3                  0    100      0 i
 *>i 10.4.10.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.11.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.12.0/24     4.4.4.4                  0    100      0 i
 *>i 10.4.13.0/24     4.4.4.4                  0    100      0 i
 *>i 10.5.1.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.2.0/24      5.5.5.5                  0    100      0 i
 *>i 10.5.10.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.11.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.12.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.13.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.14.0/24     5.5.5.5                  0    100      0 i
 *>i 10.5.15.0/24     5.5.5.5                  0    100      0 i
 *>  10.6.10.0/24     0.0.0.0                  0         32768 i
 *>  10.6.11.0/24     0.0.0.0                  0         32768 i
 *>  10.6.12.0/24     0.0.0.0                  0         32768 i
 *>  10.6.13.0/24     0.0.0.0                  0         32768 i
 *>  10.6.14.0/24     0.0.0.0                  0         32768 i
 *>  10.6.15.0/24     0.0.0.0                  0         32768 i
 *>i 10.9.10.0/24     3.3.3.3                  0    100      0 65512 i
 *>i 10.10.9.0/24     3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.10.0/24    3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.11.0/24    3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.12.0/24    3.3.3.3                  0    100      0 65512 65538 i
 *>i 10.10.13.0/24    3.3.3.3                  0    100      0 65512 65538 i
 r>i 10.12.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.19.1.0/30     3.3.3.3                  0    100      0 65512 i
 r>i 10.24.1.0/30     2.2.2.2                  0    100      0 i
 *>i 10.39.1.0/30     3.3.3.3                  0    100      0 65512 i
 *>  10.67.1.0/30     0.0.0.0                  0         32768 i
 *>i 10.109.1.0/30    3.3.3.3                  0    100      0 65512 i

Total number of prefixes 55

Next Hop Tracking

Next hop tracking involves the IGP sharing next hop information and their viability so that when there is a problem, the IGP informs BGP. Next hop tracking is enabled in IOS by default. It can be enabled using the command bgp nexthop trigger enable. A delay can be added to the next hop tracking process. The delay ensures that BGP does not react to a flapping route: bgp nexthop trigger delay 5.

Fast External Fallover

BGP fast external fallover is critical for failovers of eBGP peers. It allows BGP to instantly detect failures of eBGP peers such as link failure between eBGP peers. It is not applicable to iBGP peers. It is enabled by default. If disabled, BGP fast external fallover can be enabled in the BGP configuration using the command bgp fast-external-fallover or on an interface to enable BGP fast external failover for the specific interface using the command ip bgp fast-external-fallover.

Bidirectional Forwarding Detection (BFD)

BFD is used to ensure that a link between any two devices is truly bidirectional i.e., the transmit and receive links are functional. Bi-directional link failure occurs particularly in fibre optic links where two separate fibers are used with one for transmit and the second for receiving. If the forward link functions and the return link does not function, this can break the connectivity between the two BGP peers.

BFD operates in two modes; async mode or demand mode. In async mode, hello packets flow between the two devices continuously. The echo feature makes sure the CPU is not involved in the BFD process.

Configuring BFD is a two stage process:

1. Enable BFD globally using the command bfd interval <milliseconds> min_rx <milliseconds> multiplier <value>
2. Enabling BFD in BGP using the command neighbor <ip-address> fall-over bfd

Prefix Independent Convergence (PIC)

PIC ensures that alternate paths are at the ready if the primary path fails. It is similar in concept to feasible successors of EIGRP. It can be configured using the following commands:

• bgp additional-paths install: applies this behaviour on the BGP database.
• no bgp recursion host: speeds things by stopping the scanning behaviour of the forwarding information base to get the info of the next hop.
• bgp additional-paths [send|receive]: BGP devices are configured to send or receive these additional paths or both.
• bgp additional-paths select ...: Dictate which paths are in the set that can be selected as the backup paths.

The backup paths are labelled with 'b' in the Loc-RIB.

Graceful Restart

Graceful restart allows a BGP device to continue to forward traffic to a BGP peer whose BGP process is restarting. BGP devices support two modes of graceful restart:

• Graceful-restart capable: all features of graceful restart are supported.
• Graceful-restart aware: not all features of graceful restart are supported but devices are aware that neighbors are capable of graceful restart.

Graceful restart is configured per neighbor, globally or in a session template. Graceful restart feature is agreed upon by BGP neighbors during peering. The restart time is the time that the BGP peer is expected to complete restarting the BGP process otherwise the peering will fail. By default, the graceful restart restart time is 120 seconds. and a stalepath time is 360 seconds (how long stalepaths are maintained until restart is complete). To configure graceful restart, under the BGP configuration issue the command bgp graceful-restart. The IOS will prompt to reset peering for the configuration to take effect.

Maximum Prefix

The BGP maximum prefix feature restricts the number of routes that are received from a BGP peer. This feature ensures that the BGP table does not overwhelm the router by exceeding its memory or processing capability. Maximum prefix feature works with both eBGP and iBGP peers; though in production, it is typically configured for eBGP peers.

A full view refers to the sharing of all prefixes in the BGP table. By default, a full view is allowed from all peers. A full view generally should not come from downstream customers.

Routers can place prefix restrictions on the number of prefixes that they are able to receive from a BGP neighbor. If the number of prefixes received exceeds the configured maximum, two actions can be taken; generation of a log message or shutdown of the peer relationship. If not explicitly configured, the default behaviour is to shutdown the peer session with the "offending" peer. The maximum prefix can be configured using the BGP address family configuration command neighbor ip-address maximum-prefix <prefix-count> [warning-percentage] [restart <minutes>] [warning-only].

R1(config-router-af)#neighbor 2.2.2.2 maximum-prefixes 45 75 warning-only

The above configuration sets the maximum number of prefixes from BGP neighbor with BGP ID 2.2.2.2 at 45 with warning messages issued when the number of received prefixes from the BGP peer is at 75% the maximum prefix configured. Additionally, warning messages are issued after the number of received prefixes exceeds the configured maximum. A warning is not generated before the prefix limit is reached. By adding a warning percentage, you can have a warning message sent when the percentage is exceeded.

The default action to end the BGP session can be changed by using the optional keyword warning-only so that a warning message is generated instead. When the threshold has been reached, additional prefixes are discarded.

*Dec 31 18:41:02.758: %BGP-4-MAXPFX: Number of prefixes received from 2.2.2.2 (afi 0) reaches 42, max 45
*Dec 31 18:57:34.138: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 2.2.2.2 (afi 0): 46 exceeds limit 45

If the warning-only keyword is not added when configuring the maximum-prefix, when a peer advertises more routes than the maximum prefix count:

1. The peer moves the neighbor to the idle state in the BGP finite-state machine (FSM),
2. Closes the BGP session,
3. And sends out the appropriate syslog message.
4. The BGP session is not automatically reestablished by default.
5. If you want to restart the BGP session after a certain amount of time, you can use the optional keyword restart <minutes>.

Enabling the maximum prefix feature takes effect immediately and does not require the reset of the BGP session.

Tuning CPU and Memory

CPU usage can be viewed using the command show processes cpu sorted. In production environments, CPU consumption may rise to over 60%. Processes can be filtered for BGP as follows: show process | include utilization | Runtime|BGP.

To optimize CPU utilization by BGP, consider the following:

• Implement update groups; these are implemented by default on Cisco devices. update groups are more efficient than peer groups in CPU efficiency.
• Number of routes: carryout aggregation as effectively as possible.
• Increase efficiency of TCP.

Tuning Memory

To view memory usage by BGP, use these commands show ip bgp summary, show ip route summary. show processes memory sorted | i PID|BGP . To tune memory consumption, consider the implementation of the following features:

• Aggregation
• Filtering
• neighbor reduction
• Route reflection
• Attribute reduction such as controlled use of communities.

Transport Optimization

TCP can be tuned to reduce the memory and CPU utilization by BGP through the following configurations:

• TCP optimization thru MSS and window size.
• BGP update generation is automatically implemented using update groups.
• Optimization of TCP ACK: ACks can be buffered

Default Route Propagation

A default route can be propagated to a BGP peer using the default-originate keyword of the BGP neighbor command. An optional route-map can be added to the command. This route-map can be used to configure the conditions that must exist before the default route can be propagated to the neighbor. This default route has an administrative distance of 200 if configured for an iBGP peer and 20 for an eBGP peer.

If a local static default route has been configured, it will be inserted into the routing table in preference to the BGP propagated default route because a static route has a lower administrative distance (of one) than the iBGP administrative distance of 200.

R9(config-router-af)#neighbor 1.1.1.1 default-originate
R9(config-router-af)#do clear bgp ipv4 unicast 1.1.1.1 soft out
################


R1#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 9.9.9.9 to network 0.0.0.0

B*    0.0.0.0/0 [20/0] via 9.9.9.9, 00:01:05
R1#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65537000", distance 20, metric 0, candidate default path
  Tag 9, type external
  Last update from 9.9.9.9 00:02:59 ago
  Routing Descriptor Blocks:
  * 9.9.9.9, from 9.9.9.9, 00:02:59 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 9
      MPLS label: none

Route Flap Dampening

Route flapping occurs when a route is advertised and then withdrawn repeatedly over a short period of time. The advertised route may alternatively have different BGP next hops for each advertisement. Each time a route flap occurs, a BGP Update message must be sent to advertise the new route and/or withdraw previously advertised routes. Processing these BGP Update messages increases the router's CPU load. eBGP neighbors going down/up is not considered a flap. Route flap dampening was introduced as a method to prevent the installation of flapping routes into the BGP table and lower the CPU load. BGP route flap dampening tries to ensure a stable BGP table from flapping routes.

The routers today have greater processing capacity to handle many BGP updates. As a result, BGP route flap dampening is not commonly used today.

Route dampening aims to reduce the scope of route flap propagation. Prefixes with a history of flapping have the label 'h' in the output of the Loc-RIB table.

Route flap dampening operation involves the following:

• Add a penalty for each flap that occurs.
• Exponentially decay penalty; half life determines the decay rate.
• Penalty above the suppress-limit; do not advertise the route to BGP peers.
• Penalty decayed below reuse-limit; re-advertise route to BGP peers.

Route flap dampening is only applied to inbound announcements from eBGP peers; alternate paths are still usable.

When a route flap occurs for a prefix:

• If a BGP withdrawal message is received, penalty on the prefix is increased by 1000 by default and the prefix is marked as having flap history
• If a BGP Update message is received, if the penalty is greater than suppress-limit, the prefix is not announced to any BGP peers and is marked as suppressed.
• If the prefix carries on flapping after being suppressed, penalty is incremented and decayed as normal.
• Once prefix is stable, it will be suppressed according to the decay rate given by the half life time.
• Penalty value is decayed every 5 seconds. Decay rate is same whether prefix is in the BGP table or is not in the BGP table.
• Once penalty reaches reuse-limit, prefix is reannounced.
• Once penalty is less than half reuse-limit, penalty is reset to zero.
• If the router receives an update about a route with a penalty, the half-life timer starts. The default half-life value is 15 minutes. When the half-life is reached, the penalty is reduced by 50%.
• If a route exceeds the suppress limit, the route is dampened. The default suppress-limit value is 2000. Once a route is dampened, it will not be installed into the routing table and won't be advertised to BGP neighbors.
• To install or advertise a route, the penalty has to be lower than a reuse limit. The default reuse limit is 750.
• If the penalty is below 50% of the reuse limit, the penalty is removed completely.

The maximum suppress time, by default is 60 minutes, ensures that a route is not dampened indefinitely based on the route's flapping behavior. The recommended suppress threshold is 6,000 and max suppress threshold is 50,000.

Configuration

Fixed Dampening

BGP flap dampening can be configured using the following command: bgp dampening <half-life> <reuse> <suppress> <max-suppress>

Example configurations using IOS defaults: bgp dampening 15 750 2000 60

• half-life of 15 minutes
• reuse-limit of 750 and suppress time of 60 minutes means maximum possible penalty of 12000
• once prefix stops flapping, penalty is decayed from a maximum possible value of 12000 to 750 - this will take 60 minutes.
• Once penalty reaches 375, it is reset to zero.

CAUTION: Care is required when setting the parameters:

• Penalty must be less than reuse-limit at the maximum suppress time.
• Maximum suppress time and half life must allow penalty to be larger than suppress limit.
• Decay rate is pre-calculated when flap dampening is configured. Numbers must be feasible, IOS does not check.
• Always ensure that suppress-limit is less than max-penalty otherwise there will be no route dampening.

The following are examples of configuration of route flap dampening with correct configuration and wrong configuration.

Examples (Wrong)
bgp dampening 30 750 3000 60
reuse-limit of 750 means maximum possible penalty is 3000 - no prefixes suppressed as penalty cannot exceed suppress-limit
• Examples - (Correct)
bgp dampening 30 2000 3000 60
reuse-limit of 2000 means maximum possible penalty is 8000 - suppress limit is easily reached

Examples -(Wrong)
bgp dampening 15 500 2500 30
reuse-limit of 500 means maximum possible penalty is 2000 - no prefixes suppressed as penalty cannot exceed suppress-limit
• Examples - (Correct)
bgp dampening 15 750 3000 45
reuse-limit of 750 means maximum possible penalty is 6000 - suppress limit is easily reached

Selective and variable dampening

Selective dampening can be based on AS-PATH, Communities and Prefixes. A route-map is referenced by the bgp dampening command.

• Define the route-map and set the values for the route dampening:
  • route-map <name> permit 10
  • match ip address prefix-list FLAP-LIST
  • set dampening <half-life> <reuse-value> <suppress-penalty> <maximum suppress time>
• Reference the route-map in the command bgp dampening: bgp dampening [route-map <name>]

Verification

Some verification commands include the following:

• show bgp ipv4 unicast flap-statistics
• show bgp ipv4 unicast dampened-paths
• clear bgp ipv4 unicast flap-statistics
• clear bgp ipv4 unicast dampening

Peering Using Loopback Addresses

BGP messages use the primary IP address of the outbound interface toward the BGP peer by default. When configuring a BGP neighbor, the IP address of one of the neighbor's interfaces is entered in the configuration. If the IP address of the BGP open message does not match with the neighbor's configured IP address, the relationship will not form. If a link failure occurs on the outbound interface, then the peering session is dropped. To maintain the peering session despite the failure of the outbound links, configure an IGP on the router's transit links, advertise the loopback interfaces into the IGP and then configure the BGP neighbors to establish a session to the remote router's loopback address. The loopback interface is virtual and always stays up. In the event of link failure, the peering session stays up and the IGP finds another path to the loopback address; in essence, turning a single hop iBGP session into a multi-hop iBGP session.

BGP processes messages from peers that it has an existing BGP session. If a BGP message source does not match an entry in the neighbor table, the BGP message cannot be associated to a peer and it is therefore discarded. The source IP address of the BGP message still reflects the IP address of the outbound interface. The source IP address of BGP messages needs to be explicitly configured for each neighbor with the command: neighbor <ip-address> update-source <interface_id> . Verification of peer's IP address can be confirmed using the command: show bgp ipv4 unicast neighbors <ip-address>

For eBGP peering using a loopback interface, the IP address or network of the loopback interface should exist in the routing table of the eBGP peer. In production networks, usually a static route is configured. Scenarios exist where an IGP is configured between eBGP peers. Here, the IP address of the loopback interface is advertised into the IGP. This will result in the peer session between the two prefixes to flap as the eBGP route (with AD of 20) is installed into the routing table. This results in the IGP route (with its higher AD) not being installed into the RIB. However, as the IGP route is not in the RIB, the eBGP route is again removed because it is not in the RIB.

One solution to this is to advertise the IP address loopback of the loopback with the added keyword backdoor. For example network 192.168.0.1 mask 255.255.255.255 backdoor.

Miscellaneous Neighbor Options

log-neighbor-changes

The bgp log-neighbor-changes command helps with logging the state of the BGP peering with a neighbor. On most Cisco IOS versions, this command is enabled by default.

BGP Synchronization

BGP configuration in more recent IOS versions, by default, includes the command no bgp synchronization. BGP Synchronization is a legacy black-hole prevention technique. BGP synchronization was an attempt to eliminate traffic blackholes in an iBGP multihop topology where intermediate routers are not running BGP.

With BGP synchronization, prefixes are advertised to iBGP peers only if they are available in the IGP as well. This would ensure that any intermediate non-BGP routers would be able to forward the traffic to/from prefixes that are advertised in BGP.

BGP synchronization is not commonly used because redistributing the large number of prefixes in the BGP table may overwhelm the IGP. Additionally, BGP synchronization is not used today because of the use of iBGP scalability techniques such as full mesh, route reflection, and BGP confederations reduces possibilites of traffic being black-holed.

Troubleshooting BGP

BGP Peerings

Some commands that can be used to verify the state of BGP peerings include:

• show bgp ipv4 unicast summary: view the state of the neighborship
• ping: test end to end connectivity using the correct source interface.
• debug ip bgp
• debug ip packet detail <acl>

BGP Neighborship Failure

The following are some of the reasons a BGP neighbor relationship might not form:

• Interface is down: The interface through-which the connection to the remote peer is made must be physically up and the line protocol must be up. Use the command show ip interface brief to verify the interface status.
• Layer 3 connectivity is broken: You need to be able to reach the source IP address of the remote BGP peer. Use the ping command to verify end-to-end connectivity. Keep in mind the source IP address used for ICMP packets when verifying connectivity.
• Path to the neighbor is through the default route: You must be able to reach the neighbor using a route other than the default route. BGP considers the most specific route in the routing table and disregards reachability through the default route.
• Neighbor does not have a route to the local router: The two routers forming a BGP peering must have routes to each other. The state of Idle or Active will be displayed in the State/Pfx column of the command show bgp ipv4 unicast summary.
• Incorrect neighbor statement: The IP address and autonomous system number in the peer configuration command neighbor <ip-address> remote-as <as_number> statement must be accurate.
• ACLs: An access control list (ACL) or a firewall may be blocking TCP port 179. BGP uses TCP port 179 when operating in the server role. If the ACL is blocking incoming packets to this port and not outbound packets to port 179, then the local BGP device can be made to operate in client-mode.
• BGP packets sourced from the wrong IP address: The source IP address of an inbound BGP packet must match the local neighbor statement. If packets are sourced from a loopback interface, ensure that the command neighbor <ip-addresss> update-source is configured.
• The TTL (time-to-live) of the BGP packet expires: The peer may be further away than is permitted. In the case of eBGP, increase the TTL if packets are sourced from a loopback interface. TTL can be verified using the command: show bgp ipv4 unicast neighbors | include BGP neighbor|TTL
• Mismatched authentication: The two routers must agree on the authentication parameters.
• Misconfigured peer group: Peer groups simplify repetitive BGP configurations; however, if not carefully implemented, they can prevent neighbor relationships from forming or routes from being learned.
• Timers: Timers do not have to match; however, if the minimum holddown from neighbor option is set, it could prevent a neighbor adjacency.

Troubleshooting Missing Prefixes

Some common reasons BGP routes might be missing from either the BGP table or the routing table:

• Missing or bad network mask command: An accurate network command is needed to advertise routes.
• Next-hop router not reachable: To use a BGP route, the next hop must be reachable.
• BGP split-horizon rule: A router that learns BGP routes through an iBGP peering does not share those routes with another iBGP peer.
• Better source of information: If exactly the same network is learned from a more reliable source, it is used instead of the BGP-learned information.
• Route filtering: A filter might be preventing a route from being shared with neighbors or learned from neighbors.
• BGP Synchronization: Prefixes may be missing because BGP synchronization has been enabled. BGP synchronization may have to be disabled to ensure prefixes are advertised.
• BGP Communities: Ensure that you send communities with the neighbor.

Multiprotocol BGP for IPv6

Originally, BGP was intended for routing IPv4 prefixes. RFC2858 added multi-protocol BGP(MP-BGP) capability by adding address family identifier (AFI) extensions. MP-BGP RFC 4760 defines the following new features:

• New address family identifier (AFI) model
• New BGPv4 optional and nontransitive attributes:
• Multiprotocol reachable NLRI
• Multiprotocol unreachable NLRI

The multiprotocol reachable NLRI attribute describes IPv6 route information, and the multiprotocol unreachable NLRI attribute withdraws the IPv6 route from service. The attributes are optional and nontransitive, so if an older router does not understand the attributes, the information can just be ignored. During the open message negotiation, the BGP peer routers exchange capabilities. The MP-BGP extensions include an address family identifier (AFI) that describes the supported protocols, along with SAFI attribute fields that describe whether the prefix applies to the unicast or multicast routing table: IPv4 unicast: AFI:1, SAFI:1 IPv6 unicast: AFI:2, SAFI:1 MP-BGP extensions include an AFI that describe the supported protocols along with subsequent address family identifier (SAFI) attribute fields that describe whether the prefix applies to the unicast or multicast routing table:

Protocol	AF1	SAFI
IPv4	1	1
2	1

Every address family maintains a separate database in configuration for each protocol in BGP. This means that a database exists for each protocol IPv4 unicast and a different one for IPv4 multicast routing. This allows for the routing policy of one address family to be different from the routing policy of a different address family even though the router uses a different BGP session with the other router. BGP includes AFI and SAFI with every route advertisement to differentiate between AFI and SAFI databases locally.

All the same underlying IPv4 path vector routing protocol features and rules also apply to MP-BGP for IPv6. MP-BGP for IPv6 continues to use the same well-known TCP port 179 for session peering that BGP uses for IPv6.

BGP configuration rules that apply to IPv4 apply to IPv6, except that the IPv6 address family must be initialized, and the neighbor is activated. Routers with only IPv6 addressing must statically define the BGP RID to allow sessions to form. The TCP session used by BGP is a Layer 4 protocol (TCP port 179), and it can use either an IPv4 or IPv6 address to form a session adjacency and exchange routes. Unique global unicast addressing is the recommended method for BGP peering to avoid operational complexity. BGP peering using the link-local address may introduce risk if the address is not manually assigned to an interface. A hardware failure or cable move changes the MAC address, resulting in a new link-local address. This causes the session to fail because the stateless address autoconfiguration generates a new IP address.

During the initial open message negotiation, the BGP peer routers exchange capabilities such as the AFI and SAFI that each router will support. All the same underlying IPv4 path vector routing protocol features and rules also apply to MP-BGP for IPv6.

The configuration of BGP session involves the following commands:

Step 1: Ensure that IPv6 unicast routing is enabled with the configuration command: ipv6 unicast-routing

Step 2: Initialise the BGP process with the command: router bgp <as_number>

Step 3 (Optional if IPv4 address configured on any interface): Define the BGP router ID statically with the command: bgp router-id <id> If no IP address is configured, the router will dynamically choose an ID of 0.0.0.0 and a BGP session will not be able to establish.

Step 4: Define the BGP neighbors's remote ASN with the command: neighbor <ip-address> remote-as <as_number>

Step 5 (Optional): Define the BGP sessions password with MD5 hash: neighbor <ip-address> password <password>

Step 6 (Optional): Modify the BGP session timers with the command: neighbor <ip-address> timers <keep-alive_time> <hold_time>

Step 7: Initialize the address family with the command: address-family <afi> <safi>

Step 8: Activate the address-family for that neighbor with the command: neighbor <ip-address> activate

Step 9: Advertise IPv6 prefixes that are in the Loc-RIB with the command: network <prefix/prefix-length> [route-map <rmap_name>] It is recommended not to use the same route-map for IPv4 and IPv6 prefixes.

BGP configuration can be made hierarchical when viewing configuration using the command bgp upgrade-cli

The following commands are helpful for understanding the current status of the router:

Command	Description
show bgp <afi> <safi> summary	Displays a brief summary of the BGP process, neighbor state and prefixes received or transmitted from a high-level perspective
show bgp <afi> <safi> neighbor <ip-address>	Displays a brief summary of the BGP process, neighbor state and capabilities. Prefixes
show tcp brief	Displays the TCP session status to see if BGP can establish a session using port 179.

Viewing BGP Prefixes

Command	Description
show ipv6 route <network>	Assuming this is a BGP learned prefix, it will provide a brief overview of the BGP best path that was presented to the RIB for installation.
show bgp <afi> <safi>	Displays the BGP Loc-RIB table with all the network prefixes and paths that are available. A brief list of common BGP path attributes are included.
show bgp <afi> <safi> <prefix>	It displays the BGP Loc-RIB for the specified network prefix with all path attributes and determines the best path.
show bgp <afi> <safi> neighbor <ip-address> advertised-routes	Displays a brief summary of the BGP paths that were advertised to the specific BGP peer.

MP-BGP IPv6 Route Summarization

The same process for summarizing or aggregating IPv4 routes occurs with IPv6 routes. The format is identical except that the configuration is placed under the IPv6 address family using the command: aggregate-address <prefix>/<length> [summary-only] [as-set]

Multi-Protocol BGP for IPv6 over IPv4

BGP can exchange routes using either an IPv4 or IPv6 session. Establish a BGP session with IPv4 addressing and activate the IPv6 address family. The IPv4 address family is always initialised by default. To disable IPv4 default address family, no bgp default ipv4-unicast

Step 1: Configure an IPv4 neighbor

Step 2: Disable the default IPv4 address family

Step 3: Activate IPv4 neighbor via IPv6 address family

show bgp ipv6 unicast summary shows neighbors have an IPv4 address but exchange IPv6 prefixes as shown by the command: show bgp ipv6 unicast

In the Loc-RIB table, the next-hop displays an IPv4 address preceeded by FFFF:. This means that the next-hop is unreachable because it is an IPv4 address. To correct this problem manually, set the next-hop in a route-map on the advertising router and assign the route-map to the neighbor in the out direction under the IPv6 address family. Implement a soft reset for the changes to be applied to the Loc-RIB.

VRF-Lite for BGP

VRFs provide a virtualization context or segmentation of the RIB. It separates the global routing table from another VRF. BGP supports VRFs. Every address family maintains a separate database and configurations in BGP. This allows for a routing policy in one address family to be different from a routing policy in a different address family, This logic arries over to an address family per VRF per protocol. BGP is used as the routing protocol to exhange multiple VRG routes with ampulous layer 3 VPN provder edge routers with other routers. Using VRF-lite follows the same syntax. it just does not require the configuration of the VPN-v4 address family or sessions to be established w with other provider=edge routers. Enabling VRF support on BGP is accomplished by the following steps:

Step 1: Define the BGP route distinguisher for the VRF under the VRF definition with the command: rd <route_distinguisher>. The RD is a path attribute used in ampulous layer 3 VPN that ensures uniqueness of a prefix. A VPN prefix is an RD+Prefix. There is only one ED associated to a prefix.

Step 2: Initialize the BGP process with the command: router bgp <as_number>.

Step 3: Initialize the address family for the VRF with the command address-family <afi> <safi> vrf <vrf_name>.

Step 4: Define the BGP neighbor's remote autonomous system number: neighbor <ip-address> remote-as <as_number>

BGP VPNv4 Diagnostic Commands

Command	Description
show bgp vpnv4 unicast [all | rd <route-distinguisher> | vrf <vrf_name>]	rd: Displays the routes associated on the router with the identified route distinguisher. vrf: Displays all the routes associated on the router with the locally configured VRF. all: Displays the routes associated with all network prefixes learned within the VPNv4 address family.
show ip route vrf	Displays RIB for that defined VRF.