Contents
- Introduction
- Autonomous Systems
- Types of Autonomous Systems
- Connections to ISPs
- Prefix Sharing with ISPs
- BGP Message Types
- Neighbor State
- Session Types
- BGP Security
- Verification
- BGP Tables
- Loc-RIB
- Adj-RIB-in
- Adj-RIB-out
- Prefix Advertisement
- Prefix Processing
- Path Attributes
- Best Path Selection
- Loop Prevention
- BGP Equal-Cost Multipath
- iBGP Scalability
- Full Mesh
- Route Reflector
- Confederations
- BGP Communities
- BGP Optimization
- Peer Groups
- Peer Templates: Session and Policy Templates
- Summarization
- Filtering
- Maximum Prefix
- Default Route Propagation
- 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:
- handling of fragmentation
- sequencing of packets
- 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.
- Support for a large number of prefixes.
- 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:
- Proof of a publically-allocated network range i.e. addresses are owned by
the enterprise.
- Proof that Internet connectivity is provided through multiple service provider connections.
- 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:
- as-plain is a simple decimal representation 0 - 4294967295. This is
the default AS notation used in Cisco IOS.
- 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 .
- 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.
- 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.
- 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.
-
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.
- 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:
- 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.
- 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.
- 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:
- 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.
- BGP versions must match.
- OPEN message autonomous system number must match the configured neighbor's
autonomous system number.
- 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:
- Statically defined router-id.
- Highest IP address configured on any loopback interface.
- 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:
- 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
- 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.
- 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.
- 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;
- Match the prefix using the
match ip address command.
- 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.
- 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:
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:
- Scheduler: schedules the various processes used by BGP.
- Router: processes policy, best path algorithm.
- I/O: responsible for moving prefixes into the InQ and and out of the OutQ.
- 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):
- BMP Server: for the BGP monitoring protocol for monitoring the BGP neighborships.
- NHT: next hop tracker process helps the scanner for scanning changes in the
reachability of the next hop
- Event: responds to new network statement, new redistribute statements.
- Import Scanner: to assist the scanner with labels in MPLS environment.
- 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:
- The next-hop path attribute is set to 0.0.0.0
- BGP origin attribute is set to i (for IGP)
- BGP weight is set to 32,768.
-
Static routes:
- The next-hop is set to 0.0.0.0.
- The origin is set to IGP.
- The local preference is set to 100.
- The weight is set to 32,768
- Prefixes learned from a routing protocol:
- Next-hop path attribute is set to the next-hop IP address in the RIB.
- BGP origin attribute is set to i (for IGP)
- BGP weight is set to 32,768
- The Local Pref is set to 100.
- Multi-exit discriminator (MED) is set to the IGP metric.
- Redistributed prefixes: prefixes explicitly redistributed from
another routing protocol into BGP;
- 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
- 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.
- The advertising router modifies the BGP next-hop path attribute to the IP
address sourcing the BGP connection(on eBGP routes.)
- The advertising router prepends its ASN to the existing AS_PATH.
- 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;
- 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.
- 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.
- 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.
- 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:
- 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.
- 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:
- Change in the next-hop or the reachability of the next-hop of a prefix
- Failure of an interface connected to an eBGP peer
- Redistribution change
- 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:
- Prefer the path with the highest weight
- Prefer the path with the highest local preference.
- 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.
- Prefer the path with the lower Accumulated Interior Gateway Protocol (AIGP) metric.
- Prefer the path with the shortest AS_PATH.
- Prefer the path with the lowest origin type where IGP is lower than external
gateway protocol (EGP), and EGP is lower than incomplete.
- Prefer the path with the lowest Multi-Exit Discriminator (MED).
- Prefer the external path over the internal path.
- Prefer the path with the lowest IGP metric to the BGP next hop.
- Prefer the path with the oldest session for eBGP paths.
- Prefer the path from the BGP peer with the lowest router ID.
- Prefer the path with the lowest cluster length for iBGP paths.
- 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:
- Routes that were advertised locally: these are paths that were sourced
into the Loc-RIB table using the BGP
network command.
- Prefer local paths that were redistributed into BGP.
- Networks that have been aggregated locally using the BGP command
aggregate-address (summarization).
- 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;
- IGP origin (i): These prefixes enter the BGP table through the network command.
- Exterior Gateway Protocol (EGP) (e): referencing the EGP (exterior gateway
protocol), the predecessor to BGP.
- 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:
- eBGP peers (most desirable)
- Confederation member AS peers. There is no distinction between confederation
internal and confederation external.
- 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 confederationbgp 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:
- 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.
- 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).
- 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:
- Advertisement policy
- Filtering policy
- 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:
- Full 32-bit number (older format): can be displayed in decimal (0 - 4294967200) or
Hex 0x0 - 0xFFFFFFA0. This format is not commonly used nowadays.
- 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:
- Configure a community list: The community list can be a standard list
or an extended list.
- 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;
- Configure a community list:
ip community list 1 permit no-export
- 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:
- Conditionally matching a prefix by community
- 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:
- Configure community-lists:
ip community-list 1 permit 100:90 and
ip community-list 2 permit 100:110.
- 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
- Apply the route-map to the neighbor:
neighbor 155.1.37.7 route-map
BGP_IN in (on router R3).
- 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:
- Reset of BGP neighborship: This can be a soft reset or hard reset e.g.
clear bgp ipv4 unicast peer-group AS65000 soft out.
- 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:
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 routessuppress-map: suppress subset of more specific routesas-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:
- Distribute-lists
- Prefix-list
- Filter-lists
- 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;
- On the downstream BGP peer:
- 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
- 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
- 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
- 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:
- Enable BFD globally using the command
bfd interval <milliseconds>
min_rx <milliseconds> multiplier <value>
- 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:
- The peer moves the neighbor to the idle state in the BGP finite-state machine (FSM),
- Closes the BGP session,
- And sends out the appropriate syslog message.
- The BGP session is not automatically reestablished by default.
- 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
neighborshipping: 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.
|
