BGP Attribute

BGP attributes are a confusing array of information carried in a BGP update capable of indicating anything from path preference to various additional pieces of information about a route, either within an autonomous system or outside an autonomous system. There are four basic types of attributes:

• Well known mandatory attributes; these attributes must be recognized by all BGP speakers, and must be included in all update messages. Almost all of the attributes impacting the path decision process ( Origin Code , AS Path , Next Hop).
• Well known discretionary attributes; these attributes must be recognized by all BGP speakers, and may be carried in updates, but are not required in every update.
• Optional transitive attributes; these attributes may be recognized by some BGP speakers, but not all. They should be preserved and advertised to all peers whether or not they are recognized.
• Optional non-transitive attributes; these attributes may be recognized by some BGP speakers, but not all. If an update containing an optional transitive attribute is received, the update should be advertised to peers without the unrecognized attributes.

BGP Aggregation

Source INE 

Route aggregation is the key for information hiding. It is critical to BGP because of
the tremendous amount of routing information passed on the Internet. There are
three basic ways to do summarization in BGP:

• Create a summary prefix in IGP and advertise it into BGP using the network
  command. This is usually accomplished by creating a static route to Null0 in the
  routing table of the advertising router. This is a common way to advertise local
  prefixes into BGP. However, you cannot summarize external BGP prefixes using this
  method.

• Use auto-summarization. As discussed in another task, this method summarizes
  networks to their classful boundaries and only applies to redistributed prefixes or
  when using the classful network command. It is not used in modern networks.

• Summarize prefixes found in BGP tables by using the aggregate-address command.This is the most flexible way to do summarization, because it may be applied to any paths learned by the BGP speaker.

The syntax for the command is aggregate-address <prefix> <mask>

For the command to work, there must be a subnet in the BGP table that is encompassed by
the summarized prefix. For example, if you issue the command aggregate-address
192.168.0.0 255.255.0.0 , at least one subnet, such as 192.168.1.0/24, must be in the
BGP table (Loc-RIB), but it does not necessarily need to be in the router’s routing
table (RIB).

If you do not specify any additional options to the command, it will create a new
prefix in the BGP table with an empty AS_PATH. It will look like the new prefix was
originated in the local AS. The new prefix will automatically have the weight value of
32768 and have a special attribute called ATOMIC_AGGREGATE assigned. The
new attribute is informational and tells the other BGP speakers that this prefix is a
result of route aggregation, and some information (like AS_PATH or other attributes)
from the original prefixes may be missing. In addition to the ATOMIC_AGGREGATE
attribute, BGP attaches another attribute called AGGREGATOR to the summarized
prefix. This attribute specifies the AS number and the BGP router-ID of the
aggregating router. Just like the ATOMIC_AGGREGATE, the new attribute is also
informational.
For every aggregate, the BGP process will install an automatic static route to Null0
for the new prefix, to prevent routing loops. Remember that the original (specific)
prefixes are still advertised, unlike in IGP, where summarization automatically
suppresses more specific prefixes.

BGP Aggregation – Summary Only

router bgp ***
aggregate-address 10.1.0.0 255.255.252.0 summary-only

BGP summarization using the aggregate address command creates new prefixes in the BGP table but does not suppress the advertisement of the specific prefixes that make up the summary. To generate just the summary prefix, use the option summary-only after the aggregate-address command. The BGP process will automatically suppress advertisement of the
prefixes in the BGP table encompassed by the new summary address.

R#show ip bgp | include 10.0.
s> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.0.0/22 0.0.0.0 32768 i
s> 10.0.1.0/24 0.0.0.0 0 32768 i
s> 10.0.2.0/24 0.0.0.0 0 32768 i
s> 10.0.3.0/24 0.0.0.0 0 32768 i

BGP Aggregation – Suppress Map

When you specify the summary-only keyword, all specific prefixes are suppressed. It
is possible to suppress prefixes selectively, using a route-map associated via the
parameter suppress-map . The prefixes permitted by this route-map are suppressed;
prefixes denied by this route-map are NOT suppressed when performing
summarization.

ip prefix-list NET_2 permit 10.0.2.0/24
!
route-map SUPPRESS_MAP deny 10
match ip address prefix-list NET_2
!
route-map SUPPRESS_MAP permit 100
!
router bgp 200
aggregate-address 10.0.0.0 255.255.252.0 suppress-map SUPPRESS_MAP

The above example  allows the 10.0.2.0/24 subnet to be leaked through the summary , the rest of the prefix’s are suppressed.Note the DENY Statement on the route-map.& Seq 100 blocks the rest.

BGP Aggregation – Unsuppress Map

It is often desirable to load-balance traffic ingress to the local AS, so that traffic to some subnets enters via one BGP peer and the other peer is used as the entry point for other subnets. Generally, to accomplish this, you need to advertise all specific prefixes on both uplinks and use AS_PATH prepending to modify prefixes’preference.  This scheme implements load balancing and provides backup in case of any uplink failures.However, it is possible to achieve the same goal using a different technique. It is based on the fact that classless routing always prefers the most specific prefix to reach the destinations. If there is a specific prefix in the routing table (for example, 10.0.1.0/24) and the summary one (for example, 10.0.0.0/22), the router will prefer /24 and use /22 only if the most specific prefix vanishes. Thus, by configuring the
border BGP peers for advertising both the summary and selected specific prefixes, you may achieve the same load-balancing with the necessary level of redundancy. To implement this technique, you may use the unsuppress-map BGP feature. This feature can only be configured on the router that performs prefix aggregation using the command aggregate-address with summary-only .

ip prefix-list NET_1 permit 10.0.1.0/24
!
route-map UNSUPPRESS_MAP permit 10
match ip address prefix-list NET_1
!
router bgp 200
aggregate-address 10.0.0.0 255.255.252.0 summary-only
neighbor 155.1.37.7 unsuppress-map UNSUPPRESS_MAP

BGP Aggregation – AS-Set

It is important to remember that aggregation hides information previously found in the specific prefixes. This includes all attributes, such as NEXT_HOP, AS_PATH, and so on. The new prefix appears to be originated from within the local AS where aggregation is perfpormed. This causes no problems if all specific prefixes belong to
the local AS. However, when you summarize prefixes learned from other ASs, information hiding may result in the following dangerous consequences:

• Suboptimal routing, caused by loss of path information, such as AS_PATH, MED and
  so on.
• Routing loops, because removing the AS_PATH attribute and replacing it with an
  empty list prevents the BGP loop-detection mechanism from working properly.
  The second issue is more dangerous.

To prevent it, it is possible to insert a special new member into the AS_PATH of the newly created summary prefix. This elementis called AS_SET and contains the AS numbers found in all AS_PATHs of the specific prefixes.This list of AS numbers is unordered, unlike the regular AS_SEQUENCE element. Its only use is for routing loop prevention; when BGP
receives a prefix, it scans the AS_PATH attribute. If the local AS number is found in any of the AS_SET or AS_SEQUENCE elements, the prefix is dropped. By default, the aggregated address in BGP will not include the AS-Set information.
To force the use of this information, specify the as-set option as follows: aggregate address <subnet> <mask> as-set

BGP Aggregation – Attribute-Map

When you use the as-set parameter to the aggregate-address command, the resulting prefix will inherit “additive” attributes of the specific prefixes. This includes the AS_PATH attributes, condensed into AS_SET and the community attributes, which are grouped together from all prefixes. We will explore community signaling in further detail, but for now remember that any prefix bearing the community attribute value of “no-export” is not advertised to the adjacent ASs.

route-map ATTR_MAP

set community none

router bgp 200
aggregate-address 112.0.0.0 248.0.0.0 summary-only as-set attribute-map ATTR_MAP

BGP Aggregation – Advertise Map

When using the as-set keyword with BGP aggregation, some of the specific prefix attributes got mixed together in the new prefix. Specifically, you should watch out for the resulting AS_SET and list of community attributes. In the previous task, you learned how to modify some of the aggregated prefix attributes. However, you cannot manipulate an important attribute such as AS_SET directly. Instead, you may specify the specific prefixes that will be used to make up the attribute list for the aggregate prefix. This is accomplished by using the advertise-map parameter to the aggregate-address command. The route-map used as advertise-map should permit specific prefixes to be used to compose the aggregate attributes, such as AS_SET. You can use only access-list, prefix-list, or as-path access-lists to match the specific
prefixes. Information from the prefixes denied by the route-map is not used when constructing the resulting summary-prefix. You may use this method to remove the prefixes with unwanted BGP community attributes as well.

ip prefix-list AS300_PREFIX permit 222.22.3.0/24

route-map ADVERTISE_MAP deny 10
match ip address prefix-list AS300_PREFIX

route-map ADVERTISE_MAP permit 100

router bgp 100
aggregate-address 222.22.0.0 255.255.252.0 summary-only as-set advertise-map ADVERTISE_MAP

BGP Route Reflectors & Confederations

• The above topology shows an iBGP full mesh setup.The topology has 6 routers that requires 15 iBGP Peerings to establish a full Mesh.
• The formula N(N-1)/2 (where N is the amount of  routers) , used to calculate the amount of required iBGP Peerings to establish a full mesh.
• iBGP full mesh is required because the iBGP loop prevention rule states that  ” An iBGP learned route will not be advertised to other iBGP Peers.”
• If a router does not have full mesh connectivity with other peers , the router will not have a full view of the entire topology/Prefixes.

Confederation

• If we apply BGP Confederations  on the above topology , the required iBGP peerings will be reduced to  8.

Route Reflectors

• If we apply BGP Route Reflectors on the above topology , the required iBGP peerings will be reduced to  6.
  

BGP Confederations

• Defined in RFC 5065, Autonomous System Confederations for BGP, confederations, like route reflectors, are used to reduce the need for fully meshed iBGP peerings in large-scale deployments. In confederation, a public AS is split into smaller Sub Autonomous Systems (Sub-ASs), which exhibit a hybrid behavior of both iBGP and EBGP. Inside a Sub-AS, the requirement for either fully meshed iBGP peerings or route reflection still applies, but between Sub-ASs, EBGP advertisement rules apply.
• First, the BGP process is initialized using the Sub-AS number, as opposed to the normal initialization with the public AS number. Sub-AS numbers are typically in the private AS range (64512 – 65535), but technically can be any valid number, private or not. Next, the bgp confederation identifier informs the router that it is part of a confederation, with the ID number being its public AS number.
• Any neighbor whose remote-as matches either the local Sub-AS or a number listed in the bgp confederation peers statement is considered to be part of the confederation. In the latter case, these peers are considered “confederation EBGP peers.” Neighbors whose AS matches neither the local Sub-AS nor a confederation peer AS are considered normal EBGP neighbors. The most notable difference between confederation implementations and route reflection or full mesh is the introduction of a new BGP attribute known as the AS_CONFED_SET. The confederation set, or simply confed set, is an unordered list of Sub-ASs that is prepended onto the normal AS-Path of a BGP prefix as it is passed between Sub-ASs. The confed set, however, is stripped and replaced by the confederation identifier when a prefix is advertised to a true EBGP peer.
• Note : From a bestpath selection point of view, the entire AS_CONFED_SET counts as only one AS.

BGP Route Reflectors

Source INE :

• BGP route reflectors, as defined in RFC 2796, are used in large-scale iBGP deployments to reduce the need for [n*(n-1)/2] fully meshed peerings. Route reflectors accomplish this by creating an exception for passing advertisements between IBGP peers
• A route reflector can have three types of peers: EBGP peers, client peers, and nonclient peers. EBGP peers are neighbors in a different AS number, including peers in different Sub-ASs in confederation. Client peers are iBGP neighbors that have the route-reflector-client statement configured. Non-client peers are normal iBGP peers that do not have the route reflector-client statement configured. Routing advertisements sent from the route reflector must conform to the following three rules:
• 1. Routes learned from EBGP peers can be sent to other EBGP peers, clients, and nonclients. 2. Routes learned from client peers can be sent to EBGP peers, other client peers, and non-clients. 3. Routes learned from non-client peers can be sent to EBGP peers, and client peers, but not other non-clients.
• Note : When a route is advertised, or “reflected,” from the route reflector to a client or nonclient, BGP attributes such as the next-hop value are not updated:

Two new attributes are added onto the reflected prefix, the Originator ID and the Cluster List:Recall that previously, loop prevention in iBGP was achieved simply by not advertising routes learned from one iBGP neighbor to another. Because route reflection violates this rule, new loop prevention must be implemented.

• Originator ID: is set by the route reflector as the BGP router-id of the neighbor from which it learned the prefix , When any BGP speaker learns a route from an iBGP neighbor, and the Originator ID matches their own local router-id, the route is discarded.This is why it is essential that the BGP router-id value be unique throughout the entire routing domain, just like in OSPF and EIGRP.
• Cluster List : the Cluster List, contains the Cluster-IDs of the route reflectors that the route transited through in the network. This attribute is used to prevent loops between route-reflectors, when a hierarchical design called Clustering is implemented. A “cluster” in BGP is defined as a route reflector and its clients.

Note :that because the other attributes in the prefix are not updated by the route reflector, the reflector is analogous to the DR in OSPF, and in many cases traffic does not physically transit through this device. Instead, the reflector is simply a central point for network control traffic, but not necessarily an aggregation point for traffic.

BGP Clusters

The term “cluster” refers to a route-reflector and its clients, or multiple routereflectors that service the same clients. Clustering is used to create a balance between the amount of BGP control traffic that must be maintained through peering and redundancy. Many large-scale service providers use clustering to create hierarchy in their iBGP designs by constraining clusters to different geographic regions, which reduces the number of long-haul BGP peerings that must occur.

Inter-cluster peerings ( When route reflectors are clients of each other. )

inter-cluster peerings configured as client peerings, each update message sent out results in a feedback loop of update messages received back in. With only a few prefixes in the BGP table, this may not seem like a big issue, but with the hundreds of thousands of prefixes in the Internet BGP table, these type of loops can quickly cause utilization problems.

BGP Miscellaneous

• The default TTL for EBGP peers is 1. This means that non-directly connected EBGP peers cannot be established, because the TTL will  expire in transit. By issuing the ebgp-multihop [ttl] command, the TTL can be increased to support your design.
• With default EBGP sessions, a TTL of one prevents non-directly connected neighbors from forming. Additionally, IOS prevents the initiation of nondirectly connected EBGP sessions when the TTL is one (multihop is not configured), because it assumes that the TTL will expire in transit. One way of resolving this problem is to simply increase the TTL between the peers. In designs where the peers are directly connected but the peering address is a Loopback instead of the connected interface between them, the disable-connected-check neighbor option may also be used.
• Although the ebgp-multihop & disable-connected-check  the difference between these features is that the disable-connected-check prevents cases in which the EBGP session between two devices is routed over another transit router  155.1.0.4 rcv UPDATE about 155.1.23.0/24 — DENIED due to: NEXTHOP is our own address;, because the TTL value remains 1.
• The BGP split-horizon rule governs the route advertisements between IBGP peers, which specifies that routes learn via IBGP are never propagated to other IBGP peers.
  Note: The BGP split-horizon rule is slightly different that the split-horizon rule as in the distance vector routing protocols.
  Note: Regular split-horizon rule still govern the route advertisements between EBGP peers, in which a route is not advertised back to the EBGP peer from which the route was received.
• RIB-failure by itself is not necessarily bad, but there are certain cases in which this disconnect between the BGP table and the routing table can cause traffic loops. By default, BGP routes that have RIB-failure can be advertised to other neighbors, because the command no bgp suppress-inactive is the default option under the routing process. To stop RIB-failure routes from being advertised, issue the bgp suppress-inactive command under the process.

Using automatic tunneling techniques along with BGP is the core of MPLS VPNs. In this case we’ll use simple manual tunnels along with BGP to better understand possible effects. Two devices peer BGP (this could be eBGP or iBGP session) across a non-BGP-capable router cloud. This configuration means that any attempt to reach a BGP prefix across the non-BGP cloud ould result in prefix blackholing. However, if we establish a direct tunnel between the BGP peers and force all packets go across the tunnel, the non-BGP devices will never notice those packets. Thus, the “unknown” addresses will be hidden from the “core” network, only appearing at the edge routers that know about them. Notice the trick used in the solution. Although the “core” IP addresses are used for BGP peering, next-hops in BGP prefixes are modified to point to the tunnel endpoints. Alternatively, you could have peered directly off the tunnel endpoints or even used policy routing to divert packets to the tunnel interfaces:

Enabling BGP on all transit devices in the AS is one way to ensure that all routers have full external routing information. This solution is scalable, because it avoids feeding large BGP tables into IGP. In some situations, you cannot enable BGP on all routers in your network. This may be the case of an enterprise network, in which only border routers peer eBGP with
the ISP. In such situations, it is common to advertise a default route from the border routers toward the rest of the network.
There could be even more complicated scenarios, such as migrating your network or gradually enabling BGP on all devices. In situations like these, you may find that iBGP peers are separated by non-BGP cloud or that non-BGP speakers need BGP
routes from the devices that learned them via iBGP (no eBGP!). So what’s wrong with redistributing iBGP prefixes into IGP? As you remember, BGP uses AS_PATH attributes to detect routing loops. When exchanging iBGP routes, AS_PATH
attributes are not prepended and thus the route loop prevention technique does not work. Because of that, feeding iBGP prefixes into an IGP may result in routing loops, because the “split-horizon” rules for BGP prefixes may be broken. To make
this situation even worse, iBGP has the AD value that makes it less preferred than any IGP. Thus, iBGP prefixes redistributed into an IGP may preempt iBGP-learned prefixes on other iBGP speakers. To prevent the above issues, iBGP-learned prefixes are not automatically redistributed into IGP when you issue the statement redistribute bgp under any IGP process on the router, only eBGP prefixes are redistributed. To make iBGP redistribution possible, you need an additional statement configured under the BGP process: bgp redistribute internal . Be very careful when enabling this feature, because you may quickly end up with routing loops, and try to avoid multiple points of iBGP to IGP redistribution.

Peer Groups

The major benefit you achieve when you specify a BGP peer group is that a BGP peer group reduces the amount of system resources (CPU and memory) necessary in an update generation. In addition, a BGP peer group also simplifies the BGP configuration. A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. Based on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised, this can significantly reduce the load. It is recommended that you group together peers with identical outbound announcement policies.

router bgp 100
bgp log-neighbor-changes
neighbor 1.1.1.1  peer-group SPOKES
neighbor DMVPN_SPOKES peer-group
neighbor DMVPN_SPOKES remote-as 100
neighbor DMVPN_SPOKES route-reflector-client

BGP Update Source.

• 
• Because BGP peerings use TCP for transport, it is not a requirement that neighbors
  be directly connected. When neighbors are not directly connected, the choice of IP
  addresses used in peering can greatly affect the redundancy design of a BGP
  network.
• Normally the IP source address used in a BGP packet is the IP address of the
  outgoing interface in the routing table.
• The TCP server of the BGP session must approve where the session is coming from. If the SYN packet arrives from an
  address that is not specified in a neighbor statement, the connection is refused ( Reset )
• This exercise is based on the  BGP Peering  between R15 and R12

R15#sh ip bgp summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.0.1        4          200       4       4        1    0    0 00:00:25     

R12#sh ip bgp summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.0.2        4          200       5       5        1    0    0 00:01:11        0

• In this setup iBGP Peering is established via a shared segment 10.4.0.0/24 , meaning R12 BGP source update will be 10.4.0.1 and R15 source will be 10.4.0.2
• In our topology R15 is the Server , and its receiving a BGP message from R12 with  Source of 10.4.0.1 which corresponds to its neighbor statement.

The issue with our design is that our BGP Peering has no redundancy if SW4 goes down , the BGP peering is lost. Even though we have an alternate R13 router we can use.An alternate solution is to peer using our loopback addresses of R12 & R15.This will allow the BGP Session to be re-routed via R13 if Sw4 goes down therefore maintaining our BGP session between R12 & R15.

• First will apply the Neighbor statements pointing to the loopbacks of R12 & R15 without specifying the update source.

R12#sh ip bgp summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.15.15   4          200       0       0        1    0    0 00:01:15 Idle

R15#sh ip bgp summary 
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.12.12   4          200       0       0        1    0    0 never    Idle

• As we can see the BGP Peering is not coming up , even through R12 & R15 can ping each others loopbacks via the underlying IGP ( EIGRP ).
• In the background  the Peers are busy trying to establish the peering  , but they keep resetting each other peering’s because the update source does not match the neighbor statements.
• R12 is expecting a TCP SYN with a Source of 192.168.15.15( its neighbor statement ) but is getting 10.4.0.2
• R15 is expecting a TCP SYN with a Source of 192.168.12.12( its neighbor statement ) but is getting 10.4.0.1

• To resolve the issue we need to specify the update source of Loopback 0 , which we can specify on one side. The side were we specify the update source will automatically become the TCP client.
• The update source of loopback 0  is added to R15 , this means when R15 sends his TCP SYN to R12 with a source of  192.168.15.15 which matches R12’s neighbor statement.

R15#sh ip bgp neighbors 192.168.12.12  

iBGP & eBGP

• BGP is an application running on TCP port 179
• The main purpose of BGP is to advertise prefixs(subnets ) with the next Hop values associated with them.
• BGP does not have its own transport so it  relies on the underlying IGP( Static , EIGRP , OSPF , RIP & IS-IS ) for transport , this is why BGP considered an application rather than a routing protocol.
• BGP OPEN Messages – used during the initial BGP Peer establishment, carries BGP parameters used to establish a BGP peer.
• BGP UPDATE Messages – carries topology change information
• BGP Keepalive – Sent every 60 sec by default , Hold down timer is 180 Seconds.
• BGP Ack – Used to Acknowledge OPEN , UPDATE , Keepalive Messages.
• For two BGP Speakers to form a peering they have to go  through a normal  TCP 3 WAY Handshake.

3 WAY TCP Handshake

• Below output shows a BGP session establishment between R11 & R15

• R15(10.3.0.1) initiates the TCP Handshake by sending a SYN to with to destination TCP port of 179.
• Because R15 initiated the connection to TCP port 179 it automatically becomes the client for the session.
• If both BGP peers attempt to establish the connection at the same time, RFC 4271 (A Border Gateway Protocol 4) defines a “BGP Connection Collision Detection” mechanism, in which essentially the session originated from the device with the higher BGP router-id is maintained, and the secondary session is dropped.
• After the 3 Way Handshake is completed routers R15 & R11 will send each other OPEN Massages , these massages include  BGP Parameters ( AS number, BGP version , Hold Timer  , Optional Parameters etc ).
  

iBGP

• BGP speakers in the same AS( Autonomous System ) are considered as iBGP peers.
• The main rule of thumb for iBGP is : Do not advertise iBGP learned routes to other iBGP peers unless exceptions such as route reflection or confederation are implemented.
• If Route reflection or confederation is not is use ,  a full-mesh of iBGP is required for all iBGP speakers to have fully converged BGP Tables.
• The iBGP  TTL for  outbound sessions is set to 255.This means that the iBGP neighbors need not be directly connected, as long as IGP reachability exists between them.

eBGP

• BGP speakers in different AS( Autonomous System ) are considered as eBGP peers.
• By default  eBGP  TTL for outbound sessions is set to 1.This means that the eBGP peers need to be directly connected to form a peering.If the TTL value is exceeded the packets are dropped.
• Note :  When iBGP routers learn prefixes from their eBGP peers they do not default  update the next-hop value when they advertise the prefixes to their iBGP peers .If the iBGP peers do not have a route to the next-hop value in the prefix, bestpath selection fails and the route cannot be used.