BGP redistribution rules

Redistributing BGP into IGP and vice versa we need to remember about few rules that can be tricky.


IGP into BGP :
1) BGP automatically copies IGP metric to BGP
2) Origin attribute (LINK) will change to "?" - incomplete
3) Will not redistribute OSPF external by default.

BGP is not redistributing OSPF ext because of loop prevention. If some prefix has been  redistributed before from BGP int OSPF they will appear as OSPF ext, redistributing them back again into BGP will cause loops. This is default set up. To change that you need to configure

router bgp X
redistribute ospf Z match internal external

4) Sets weight attribute  to 32768

BGP  into IGP 
To be honest I have never seen this kind of redistribution  in practice. And that logical because there is no IGP who can handle (at this moment 16.09.2016) 655782 prefixes!

BTW here we can check what is current status of BGP table :
http://bgp.potaroo.net/index-bgp.html


and history of BGP table- this one is very impressive!



source : 
http://bgp.potaroo.net/

Back to the point:)
If you will ever do redistribution from BGP into IGP (e.g OSPF, EIGRP) you will do this in laboratory environment.
You need to remember about one big rules :
1) By default only eBGP routes are redistribute into IGP



 

BGP Path Attributes

BGP attributes are divided into :

1) Well-known mandatory : it must be recognized by all BGP implementation. Everyone supports them.
                                           Mandatory attributes must be included in all BGP Update message

• ORIGIN
• AS-PATH
• NEXT_HOP

2) Well-known discretionay : may or may not be sent int a specific Update required to support the attribute

• LOCAL_PREF
• ATOMIC_AGGREGATE

3) Optional transitive : BGP process should accept the path in which transitive att is included, even if it
                                    doesn't support and it should pass the path on to its peers

• AGGREGATOR
• COMMUNITY

4) Optional nontransitive : BGP process that doesn't recognize the attribute can ignore Update and not
                                          advertise the path to its other peer

• MULTI_EXIT_DISC (MED)
• ORIGINATOR_ID
• CLUSTER_LIST

 

BGP eBGP vs iBGP

Introduction

Border Gateway Protocol (BGP), is a protocol used for exchanging routes on a grand scale. It's old (latest version from 1995), slow (converging takes forever) and extremely scalable (laughs at areas/levels of IGPs). Because of its modularity it is also very flexible.

It's a path-vector type routing protocol, where traversed Autonomous Systems (AS) are the path and the interface from which to send a packet is the vector.

One of the most important characteristics of BGP is its scalability due to rarity of advertisements between neighbors. Whole routing knowledge is exchanged only during the session initiation. After that routes are advertised on "need to know" basis - i.e. when new information is learned or old information withdrawn.

BGP doesn't have its own connectivity protocol for communication between peers. It uses TCP port 179 to achieve reliable connections. Because of that, it's often argued that BGP isn't really a protocol per se, it's more of an application running on TCP protocol (like Telnet).

BGP is defined by:

• RFC 1771, "A Border Gateway Protocol (BGP-4)"
• RFC 1772, "Application of the Border Gateway Protocol in the Internet"
• RFC 1966, "BGP Route Reflection: An Alternative to Full-Mesh I-BGP"
• RFC 1997, "BGP Communities Attribute"
• RFC 2270, "Using a Dedicated AS for Sites Homed to a Single Provider"
• RFC 2385, "Protection of BGP Sessions through the TCP MD5 Signature Option"
• RFC 2439, "BGP Route Flap Damping"
• RFC 2842, "Capabilities Advertisement with BGP-4"
• RFC 2858, "Multiprotocol Extensions for BGP-4"
• RFC 2918, "Route Refresh Capability for BGP-4"
• RFC 3065, "AS Confederations for BGP"

Neighbors

EBGP vs IBGP

BGP forms two types of relationships - external (EBGP) and internal (IBGP).

External relationships are by default limited to immediate physical connections by TTL equal 1. EBGP sessions are therefor set up using neighbor facing interface IP address. Default TTL can be increased with multihop command, which allows to establish remote relationships or use loopbacks to maintain a single session over multiple redundant links.

EBGP has one simple advertising rule - forward all active BGP learned routes to all BGP neighbors.

Internal relationships are usually setup over multiple hops - default TTL is 64 (same value as multihop external sessions and confederations). Suggested method of setting up session is using loopbacks to allow IGP to reroute in case of interface failure, which aids stability.

Because IBGP doesn't have a mechanism for loop detection (like AS Path attribute in EBGP) advertising rules were modified to avoid forming routing loops - forward all active EBGP learned routes to all BGP neighbors, however forward active IBGP learned routes only to EBGP neighbors.

Due to that rule, maintaining full mesh connectivity between internal peers is a common practice.

BGP IP prefix list

Using IOS BGP IP prefix list we are able to provide the most powerful prefix based filtering mechanism. Like route maps, prefix lists are identified by a name (we also can use number but is rather situation). 

ip prefix-list NAME seq nr [ permit | deny ] A.B.C.D / nn  [ ge | le ] value

A.B.C.D -  is your prefix

nn - prefix lenght

ge - greater than or equal

le - less than or equal

BGP Attribute - CLUSTER_LIST

CLUSTER_LIST is a optional nontransitive attribute.Is a list of Cluster IDs that an update has traversed. When a Route Reflector sends a route, received from a client to a non-client, it appends the local Cluster ID to the CLUSTER_LIST. 

It is another loop prevention mechanism used in Route Refelction idea. When RR received an update, it first checks the CLUSTER_LIST. If it sees its own Cluster ID in the list, it knows that a routing loop has occured and ignores the update.

BGP Attribute - ORIGINATOR_ID

ORIGINATOR_ID is a optional nontransitive attribute. Used by Route Reflectors to prevent loops. The ORIGINATOR_ID is a 32 bit value created by RR, is a router ID of the originator of the route in the local AS. 

If originator sees his router ID in ORIGINATOR_ID knows that a loop has occured, then the update is ignored.

BGP Attribute - AS_PATH

AS_PATH is a well-known mandatory attribute that describes all the AS it has passed through. BGP router adds its AS number to the AS_PATH only when Update is sent to a neighbor in another AS. AS_PATH number is changed only when route is being advertised between EBGP peers.

The AS_PATH is displayed as a series of autonomous system (AS) numbers with the originator's AS number at the end of the path. 

Given the following diagram showing the relationship between several different AS.

This attribute is also very good loop prevention. If a BGP router receive a route from an external peer whose AS_PATH include its own AS number, the router knows that the route has looped so is dropped.

BGP Attribute - COMMUNITY

COMMUNITY is a optional transitive attribute. Even if community is not recognized by router it is propagated to other neighbors.

1) Format :  There are three format of community (in Cisco IOS 12.0 and later) :
 

• Decimal, range of0 to 4,294,967,200. Range of 0 to 65535 and 4294901760 to 4294967295 are reserved
• Hexadecimal
• New AA:NN format (AS number, 2-byte number). 

By default IOS uses decimal format. Nowadays most popular is AA:NN format, to use it you need issue the ip bgp-community new-format global configuration command.

2) Well known communites : 

• INTERNET : all routes belongs to this community by default, doesn't have a value
• NO_EXPORT (4294967041 or 0xFFFFFF01) : routes carrying this value cannot be advertised to EBGP peers or outside of the confederation
• NO_ADVERTISE (4294967042 or 0xFFFFFF02) : routes carrying this values cannot be advertised at all to either EBGP or IBGP peers
• LOCAL_AS (4294967043 or 0FFFFFF03) : routes received carrying this value cannot be advertised to EBGP oeers including peers in other AS within a confederation

3) Example of configuration : 

To set the community attributes you can use route maps :

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

• route-map test

  match ip address 1

  set community no-export

  route-map test2

  match as-path 1

  set community 100 additive

BGP Attribute - ORIGIN

ORIGIN is a well-known mandatory attribute that specifies the origin of the routing update. 

There are 3 values : 

• i - Iternal/IGP - The route originated in an IGP. The NLRI was learn from a protocol internal to the originating AS. IP subnet is injected using network or aggregate command
• e - EGP - The route was learned from EGP (Exterior Gateway Protocol) which is not used anymore
• ? - Incomplete - The route was redistributed into BGP. The NLRI was learned by some other means. There is no way to determine the original source of the route.

 i < e < ? - lower is better !

BGP router will always prefer "i" routes, next "e" routes and "?" routes.

BGP Path Algorithm

On cisco.com (http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml) there is a great doc describes :

How the Best Path Algorithm Works

BGP assigns the first valid path as the current best path. BGP then compares the best path with the next path in the list, until BGP reaches the end of the list of valid paths. This list provides the rules that are used to determine the best path:

1. Prefer the path with the highest WEIGHT.
   Note:  WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured.
   
2. Prefer the path with the highest LOCAL_PREF.
   Note: A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preference command, or to have a value of 100 by default.
   
3. Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.
   Local paths that are sourced by the network or redistribute commands are preferred over local aggregates that are sourced by the aggregate-address command.
   
4. Prefer the path with the shortest AS_PATH.
   Note: Be aware of these items:
   
   • This step is skipped if you have configured the bgp bestpath as-path ignore command.
     
   • An AS_SET counts as 1, no matter how many ASs are in the set.
     
   • The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.
     
5. Prefer the path with the lowest origin type.
   Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.
   
6. Prefer the path with the lowest multi-exit discriminator (MED).
   Note: Be aware of these items:
   
   • This comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored.
     In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored.
     
   • If bgp always-compare-med is enabled, MEDs are compared for all paths.
     You must disable this option over the entire AS. Otherwise, routing loops can occur.
     
   • If 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.
     
   • THE MED of paths that are received from a neighbor with a MED of 4,294,967,295 is changed before insertion into the BGP table. The MED changes to to 4,294,967,294.
     
   • Paths received with no MED are assigned a MED of 0, unless you have enabled bgp bestpath med missing-as-worst .
     If you have enabled bgp bestpath med missing-as-worst, the paths are assigned a MED of 4,294,967,294.
     
   • The bgp deterministic med command can also influence this step.
     Refer to How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection for a demonstration.
     
7. Prefer eBGP over iBGP paths.
   If bestpath is selected, go to Step 9 (multipath).
   Note: Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation. Therefore, these paths are treated as internal paths. There is no distinction between Confederation External and Confederation Internal.
   
8. Prefer the path with the lowest IGP metric to the BGP next hop.
   Continue, even if bestpath is already selected.
   
9. Determine if multiple paths require installation in the routing table for BGP Multipath.
   Continue, if bestpath is not yet selected.
   
10. When both paths are external, prefer the path that was received first (the oldest one).
    This step minimizes route-flap because a newer path does not displace an older one, even if the newer path would be the preferred route based on the next decision criteria (Steps 11, 12, and 13).
    Skip this step if any of these items is true:
    
    • You have enabled the bgp best path compare-routerid command.
      Note: Cisco IOS Software Releases 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T, and 12.1.3.E introduced this command.
      
    • The router ID is the same for multiple paths because the routes were received from the same router.
      
    • There is no current best path.
      The current best path can be lost when, for example, the neighbor that offers the path goes down.
      
11. Prefer the route that comes from the BGP router with the lowest router ID.
    The router ID is the highest IP address on the router, with preference given to loopback addresses. Also, you can use the bgp router-id command to manually set the router ID.
    Note: If a path contains route reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process.
    
12. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.
    This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be aware of the RR-specific BGP attribute.
    
13. Prefer the path that comes from the lowest neighbor address.
    This address is the IP address that is used in the BGP neighbor configuration. The address corresponds to the remote peer that is used in the TCP connection with the local router.