A Networker Blog

BGP Summary

The main documentation of BGP can be found in the following path http://www.faqs.org/rfcs/rfc1771.html

BGP Overview

  • AS is a collection of networks under a single technical administration
  • IGPs operate within an AS
  • EGPs connect different Ass
  • AS is designated by 16 bits in range from 1 to 65535. A range of private AS are from 64512 through 65535.
  • BGP is used between AS and guarantee exchange of loop free routing information.
  • BGP is an Advanced Distance Vector with many enhancements
  • BGP use Path Vector or Attributes as Metric

When to use BGP

  • AS allow packets to transit through it reach other autonomous systems
  • AS has multiple connections to other AS
  • The flow of traffic entering and leaving your AS must be manipulated
  • And the effect of BGP are well understood. If the BGP not controlled and filtered properly, has the potential to allow an outside AS to affect your routing decisions.

How big is the Internet?

  • Over 100,000 BGP routes
  • Over 10,000 AS numbers
  • A routing table that uses more than 30Mb

When BGP is not appropriate

  • A single connection to Internet
  • Routing Policy and route selection are not a concern for your AS
  • Lack of memory or processor power on BGP routers to handle constant updates
  • Limited understanding of route filtering and BGP path selection
  • Low bandwidth between AS
  • USE STATIC ROUTE INSTEAD
  • COMMAND: ip route prefix mask address/interface [distance]

RIP Static Route Example:

Ip route 0.0.0.0 0.0.0.0 S0

Router rip
Network 172.16.0.0

OSPF example

Ip route 0.0.0.0 0.0.0.0 S0

Router ospf 111
Network 176.16.0.0 0.0.255.255 area 0

The default-information originate always command propagate a default route into OSPF routing domain. The always cause the default route to be always advertised whether or not the router has a the path up.

BGP Terminology

  • BGP is a distance vector protocol
  • BGP runs on top of TCP port 179
  • Incremental triggered updates only
  • Periodic keepalives to verify TCP connectivity
  • Rich metrics (Attributes) . Including a list of the full path that route should take to reach a destination network. This path information is used to build a graph of ASs that is loop free and where routing policies can be applied to enforce some restrictions on the routing behavior. The path is loop free, because a router running BGP will not accept a routing update that already includes its AS number in the path list.
  • Design to scale to huge internetworks

Floating Static Route

  • You can configure the administrative distance of the static route, higher than dynamic routing, so the static routing will be used as path of last resort when no Dynamic information is available.
  • Command: IP route prefix mask interface distance

BGP Table

  • BGP has its own table, in addition to the IP Routing table
  • Information can be exchanged between the two tables
  • The router can be configured to share both tables

Peers = Neighbors: Any two routers that have formed a TCP connection in order to exchange BGP routing information are called peers.

Neighbors:

  • Internal should not be necessary directly connected
  • External should be directly connected, or we can use the ebgp multihop command.

Policy Based Routing

  • BGP allows administrators to define policies, or rules , how data will flow through the autonomous systems
  • BGP and associated tools cannot express all routing policies. BGP does not enable one AS to send traffic to a neighbor AS, intending that the traffic take a different route from that taken by traffic originating in the neighbor AS. We cannot influence how our neighbors AS will route our traffic, but we can influence how our traffic goes to our neighbors AS.
  • Can support any policy conforming to the hop by hop routing paradigm

BGP Attributes

BGP metrics are called path attributes:

Well known Mandatory – Must be recognize and propagate. Must be present in the updates

  • AS-PATH
  • Next-hop
  • Origin

Well known Discretionary – Must be recognize and propagate . Could be present in updates

  • Local Preference
  • Atomic aggregate

Optional Transitive – if not recognized, is marked and propagate

  • Community
  • Aggregator

Optional nontransitive – Discard if not recognized

  • MED

Local preference

  • The path with highest preference value are most desirable
  • The local preference is an attribute that is configured on a router and exchanged only among routers within the same AS. The default value for local preference is 100.

MED

  • Path with lowest MED (also called metric) value are most desirable
  • MED is a indication to external BGP neighbors about preferred path into an AS. This is a dynamic way to influence another AS on which way it should choose to reach a certain route when multiple entry points into an AS exist. MED is exchanged between ASs , unlike local preference.
  • By using the MED attribute, BGP is the only protocol that can affect how routes are sent into an AS.

Origin

  • IGP – (i) (Network command)
  • EGP – (e) (Redistribute from EGP)
  • Incomplete (?) (Unknown or Redistributed from IGP or Static)

Community

  • BGP communities are one way to filter incoming or outgoing routes. In BGP communities, routers tag routes with an indicator (the community) and allow other routers to make decisions based on that tag. BGP communities are used for destinations that share some common properties and therefore share common policies; router act on the community rather than on individual routes. Communities are not restricted to one network or one AS and have no physical boundaries.
  • By default, communities are stripped in outgoing . To propagate the community, it must be configured.

Weight

  • Path with highest weight are most desirable
  • Weight are not sent to any BGP neighbors
  • Value could be from 0 to 65535 and the default is 32768
  • Other paths have the weight 0 by default
  • Weight is configured locally on the router and is not propagated to any other routers.

BGP Synchronization

  • Synchronization rule: Do not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from IGP. If an AS is passing traffic to another AS, BGP should not advertise a route before all routers in the AS have learned about the route via the IGP.
  • A router learning a route via IBGP will wait until the IGP has propagated the route within the AS and then will advertise it to external peers. This rule ensures that all routers in the AS are synchronized and will be able to route traffic that the AS advertises to other ASs . This approach ensures consistency of routing information (avoid black holes) within the AS.
  • BGP synchronization is on by default
  • It is safe to turn off BGP synchronization only if all routers in the AS are running BGP (full mesh IBGP)
  • The IBGP must have a matching IGP before start to advertise.

BGP Operation

Messages types:

  • Open – Hold Time and Router ID
  • Keepalive
  • Update
  • Notification – When error detected, BGP connection closed after sent

Route Selection Decision:

  • Highest weight (local to router)
  • Highest local preference (Global within AS)
  • Route originated by the local router
  • Shortest AS-Path
  • Lowest origin code
  • Lowest MED - Conditions applys check out this link
  • EBGP path over IBGP path
  • Path through the closest IGP neighbor
  • Oldest route for EBGP paths
  • Lowest neighbor BGP router ID
  • Lowest neighbor IP address

BGP-4 supports CIDR and Aggregate

  • BGP update message include both the prefix and the prefix length. Previous version only included the prefix and the length was assumed from the address class.
  • Address can be aggregate when advertised by a BGP router
  • The AS-Path attribute can include a combined list of all ASs that all the aggregated routes have passed through. This combined list should be considered to ensure that the route is loop-free.
  • There are two related attributes to aggregate addressing. The well-known discretionary attribute ATOMIC AGGREGATE informs the neighbors AS that the originating router has aggregated the routes. The optional transitive attribute AGGREGATOR specifies the BGP router ID and the AS number of the router that performed the route aggregation.
  • By default, the aggregate route will be advertised as coming from the AS that performed the aggregation and will have the Atomic Aggregate Attribute set to show that information might be missing. The AS numbers in the nonaggregated routes are not listed. The routers can be configured to include the list of all ASs contained in all paths that are being summarized.

Implementing BGP in scale networks

BGP Split horizon

  • Routes learned via IBGP are never propagated to other IBGP peers
  • Therefore need full mesh of IBGP peers required within AS

Full Mesh IBGP Problems

  • Avoid routing information loops
  • Does not scale, Many TCP sessions, Replicate Routing Traffic

Route Reflector

  • Modifies BGP split horizon rule by allowing the router configured as route reflector to propagate routes learned by IBGP to other IBGP peers

Benefits

  • Solves the IBGP full mesh problem
  • Packet forwarding is not affected
  • Can have multiple route reflector for redundancy
  • Can have multiple levels of route reflection
  • Normal BGP can coexist
  • Easy migration

Route Reflector Terminology

  • Route reflectors
  • Clients
  • Cluster
  • Nonclients
  • Originator-ID
  • Cluster ID

Route Reflector Design

  • Divide AS into multiple clusters (At least one route reflector and few clients per cluster)
  • Route Reflectors are fully meshed with IBGP
  • Use single IGP to carry next-hop and local routes

Route Reflector Operation

  • Reflector receives updates from clients and non-clients
  • Update is from client, reflect to non-client and client (except originator)
  • Update is from nonclient, reflect to clients
  • Update is from EBGP peer, reflect to all non clients and clients

Route Reflector Migration TIPS

  • Follow the physical connection
  • Configure one route reflector at a time
  • Eliminate redundant IBGP sessions
  • Place one route reflector per cluster

Route Reflector Configuration

  • Neighbor ip address route-reflector-client (this configuration is on the Router Reflector)

Obs: the ip address is the client address.

Verify the Route Reflector

Show ip bgp neighbor

Policy Control Introduction

  • To restrict routing information to and from neighbors use:
  • Distribute lists (Using Access-List)
  • Prefix lists

Policy Control

  • Prefix List (IOS 12.0) can be used as an alternative to Access List in many BGP route filtering commands. The advantages are:
  • Significant performance improvement
  • Support for incremental modifications
  • More user friendly command line interface
  • Greater flexibility
  • Filtering with Prefix List
  • Empty prefix list permit all routes
  • Permit = use route
  • Router begins the search at the statement at the top of the prefix list, with lowest sequence number.
  • When there is a match, the rest of the list is ignored
  • Implicit deny is assumed at the end of the prefix list

Configuring the Prefix list

  • Ip prefix-list list name [seq seq value] deny/permit network/length
  • Neighbor ip address prefix-list prefix-listname in/out
  • Cannot use PREFIX-LIST and DISTRIBUTE-LIST to the same neighbor.

Prefix List Sequence Number

  • Sequence numbers are generated automatically by default
  • Used to insert an entry in a specific order
  • Used to delete an individual entry
  • By default, the entries of a prefix list will have sequence values of 5, 10, 15 and so on.
  • To disable certain entry, just use the command NO IP PREFIX-LIST SEQUENCE-NUMBER and IP PREFIX-LIST SEQUENCE-NUMBER to enable again.
  • Verify : Show ip prefix-list name and clear ip prefix-list
  • Show ip prefix-list detail : Display the information of all prefix lists
  • Show ip prefix-list detail name: Display de information of the specific prefix list
  • Show ip prefix-list name: Display the policy associated with specific prefix

Multihoming

  • Describe the situation where the AS is connected to more than one ISP. Usually is done for two reasons:
  • Increase reliability , if one connection fail, another still connected
  • Increase the performance, so that the better path can be used to certain destinations.

Types of Multihoming

  • Default routes from all providers – All ISPs pass only default routes to the AS
  • Customer routes and default routes from all providers – All ISPs pass default routes and selected specific routes to the AS
  • Full routes from all providers – The ISPs pass all routes to the AS

Default Routes from ISPs

  • Low CPU and Memory usage
  • Providers sends BGP default route, choice of provider decided by IGP metrics to reach default route
  • AS sends all of its routes to provider , inbound path decided by internet

Customer and Default Routes from all ISPs

  • Medium CPU and Memory usage
  • Best path is usually shortest AS-path
  • Can override path choice using Local Preference for example
  • IGP metric to default route used for all other destinations

Full Routes from All Providers

  • Higher memory and CPU usage
  • Reach all destinations by best path, usually best AS-Path , however this can be overriden
  • Can still manually tune path choice

Configuring Weight and Local Preference

  • (config-router) neighbor ip address weight value
  • (config-router) bgp default local-preference value

Advertising Network (IGP) into BGP

  • Network command
  • Redistributing static route
  • Use null0 interface in the Static Route

Config example:

router bgp 64520
redistribute static

ip route 192.168.0.0 255.255.0.0 null 0

or

Aggregate-address ip address

The prefer method is to use the aggregate-address command as long as more specific route exist in the BGP table, then the aggregate is sent.

Redistributing dynamic IGP routes

  • Redistribution from the IGP is not recommended as it may cause instability
  • Include only local routes
  • Filter out other routes, can be complex

Advertising from BGP into IGP

  • Done with redistribution , if necessary
  • For ISP AS, redistribution not required
  • All routers run BGP; IBGP full mesh
  • IBGP carrier exterior routes
  • IGP carries local information only, and next-hop information
  • Use no synchronization
  • Redistribution is not done, but filter for other AS
  • Use default routes instead
  • Non-ISP Redistributing from BGP into IGP, redistribution required if:
  • Not all routers run BGP
  • Require external route knowledge

Victor Cappuccio

9 Responses

Subscribe to comments with RSS.

  1. Faisal said, on October 12, 2007 at 1:52 pm

    A very concise & nicely written article on BGP.

  2. [...] BGP Summary Notes BSCI Review Notes Catalyst QOS Notes MPLS Summary Notes Multicast Summary Notes Quality of Service Notes [...]

  3. mschedrin said, on June 19, 2008 at 5:01 pm

    “The local preference is an attribute that is configured on a router and exchanged only among routers within the same AS. The default value for local preference is 100.”
    As i know the local preference set by default by router that originates the route is 32768, not 100.

  4. vcappuccio said, on June 19, 2008 at 5:33 pm

    Hello Mschedrin , thanks for your comment!

    The weight attribute is a Cisco-defined attribute. This attribute uses weight to select a best path. The weight is assigned locally to the router. The value only makes sense to the specific router. The value is not propagated or carried through any of the route updates. A weight can be a number from 0 to 65,535. Paths that the router originates have a weight of 32,768 by default, and other paths have a weight of 0.

    
    R3#show ip bgp
    BGP table version is 4, 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
    Origin codes: i - IGP, e - EGP, ? - incomplete
    
       Network          Next Hop            Metric LocPrf Weight Path
    *  3.3.3.3/32       0.0.0.0                  0         32768 ?
    R3#
    
    
    R3#show run | sec bgp
    router bgp 3
     no synchronization
     bgp log-neighbor-changes
     redistribute connected route-map Lo0
     neighbor 10.1.34.4 remote-as 4
     neighbor 10.1.37.7 remote-as 57
     no auto-summary
    
    
    R3#show run | sec route-map
    route-map Lo0 permit 10
     match interface Loopback0
    
    R3#show ip bgp 3.3.3.3
    BGP routing table entry for 3.3.3.3/32, version 4
    Paths: (1 available, best #1, table Default-IP-Routing-Table)
      Advertised to update-groups:
            1    2
      Local
        0.0.0.0 from 0.0.0.0 (3.3.3.3)
          Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced,
    best
    R3#
    

    Local preference is an indication to the AS about which path has preference to exit the AS in order to reach a certain network. A path with a higher local preference is preferred more. The default value for local preference is 100.

    Unlike the weight attribute, which is only relevant to the local router, local preference is an attribute that routers exchange in the same AS.

    Best Regards

    Victor Cappuccio
    CCIE R/S# 20657
    CCSI# 30452
    http://www.vcappuccio.wordpress.com

  5. mschedrin said, on June 19, 2008 at 5:59 pm

    Well, you’re right :) I mixed up two this attributes, thanks!!!

  6. vcappuccio said, on June 19, 2008 at 6:17 pm

    :) You are very welcome mschedrin, if you have any question, and I could help just let me know

    On your success
    Victor.-

  7. TeKirkland said, on June 19, 2008 at 10:53 pm

    Victor, Can BGP local preference be used to force outbound voice traffic over one router and data traffic over another different router? Can MED be used to influence inbound voice traffic over one router and data traffic over another different router?

    Both edge routers are co-located with separate MLPPP links into the cloud.

    Thank you

    TK

  8. vcappuccio said, on June 20, 2008 at 9:06 pm

    Hello TeKirkland

    Thanks for your question!

    Yes we agree on how LP and MED works, in resume about the 2 attributes

    Paths with highest local preference value are preferred,
    The Local preference is used to advertise to IBGP neighbors about how to leave their AS.
    The local preference is sent to IBGP neighbors only (that is, within the AS only).
    The local preference attribute is well-known and discretionary and the Default value is 100,

    For The MED attribute, also called the metric, and is an indication to EBGP neighbors about the preferred path into an AS. The MED attribute is a dynamic way to influence another AS about which path that it should choose to reach a certain route when multiple entry points into an AS exist and a lower metric is preferred.

    Unlike local preference, the MED is exchanged between autonomous systems. The MED is sent to EBGP peers; those routers propagate the MED within their AS, and the routers within the AS use the MED but do not pass it on to the next AS.

    Back to your question yes can can probably use this 2 attributes, but that if the voice traffic goes to a particular network different than the network used for the data flow, there is not way in BGP to determine what is inside that packet. BGP Just cares about announcing those NLRI . This is clear something I have not seen before, normal networks share the same network address space for voice and for data flows, now if the voice path is advertised over a proper subnet different than the data subnet, then you can also use QoS policy propagation via the BGP (QPPB) this allows you to classifying packets based on access lists, BGP community lists, etc, and, after a packet has been classified, other QoS features such as LLQ for the voice traffic and CBWFQ for the data traffic can be used to specify any business policies

    for the MLPPP, part, if I understand you clearly when an EBGP router is peering with an external neighbor, the only address that it can reach without further configuration is the interface that is directly connected to that EBGP router, so are you trying to configure BGP using the directly connected interface or are you trying to use a loopback interface? if that is the case a loopback interface is never directly connected, therefore , if you want to use a loopback interface instead, use static routes pointing at the physical address of the directly connected network (the next-hop address), and In addition to that, you need to use the neighbor ebgp-multihop command.

    I hope this helps

    Best Regards,

    Victor Cappuccio
    CCIE R/S# 20657
    CCSI# 30452
    http://www.vcappuccio.wordpress.com

  9. [...] The BGP MED – Deterministic vs Always-compare. tin tin !!! Posted in BGP, Cisco, Technologies by vcappuccio on July 15th, 2008 For a Summary of this great protocol please check out this link: BGP Summary [...]


Leave a Reply