From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 12

1,068 Words. Plan about 7 minute(s) to read this.

Presumably, the basic operation of BGP isn’t news to you. If you’re brand new to BGP, then my synopsis of the OECG chapters on BGP are likely to leave you befuddled. You’ll need to get a good book on BGP, or spend some quality time with the many BGP papers available at cisco.com. Conversely, if you ARE familiar with BGP, I suspect my synopsis will leave you bemused, as BGP is not an area of strength for me. Certainly some of what I cover in this chapter will be new to me, and I think nearly all of the next (regarding BGP policies). While I’ve set up the odd BGP router for extranet and internet connectivity, and while you can even find my ARIN handle for the ASNs I manage, it’s simply not a topic I’ve had reason to spend much time with.

To the sonorous strains of Myslivecek, we move now from interior gateway protocols, to a big-league exterior gateway protocol – Border Gateway Protocol, or BGPv4. Whereas IGPs compute best routes based on a metric, BGP computes best routes based on path attributes, the autonomous system path being the most basic of these. BGP routers are grouped together in autonomous systems. So, at the most simplistic decision-making level, a BGP router will compute a best path based on how many autonomous system numbers (ASNs) must be traversed to reach a particular IP prefix. Note that this has nothing to do with how many routers might be inside of a particular AS. An AS is considered a hop, no matter how many routers might be traversed within the AS.

That fundamental premise of BGP operations in mind, let’s discuss BGP neighbor relationships.

  • The basics:
    • TCP port 179
    • Keepalive interval defaults to 60 seconds; hold time defaults to 180 seconds. These values are exchanged by routers in BGP open messages. They do not have to match; if they do not match, the lower of the 2 will be used.
    • RID defined by (in order) – bgp router-id command; highest IP of up/up loopback; highest IP of another up/up interface.
    • Neighbors in the same ASN are considered “internal” BGP neighors, or iBGP.
    • Neighbors in different ASNs are considered “external” BGP neighbor, or eBGP.
    • BGP neighbor relationships can only form between explicitly configured peers (using the “neighbor update-source” command to define the local source IP and “neighbor” command to define the remote neighbor IP). The router will reject incoming TCP/179 messages from routers with whom he does not have an explicit defined neighbor.
    • Auto-summarization is off by default, but enabled with the “auto-summary” command.
    • MD5 is the only authentication scheme, via the “neighbor password” command.
    • BGP neighbors will form a TCP connection to one another. They will then exchange BGP Open messages. Once this is complete, the BGP neighbors will reach the “Established” state. This is the all-important state you want BGP neighbors to read. Once BGP peers are “established”, they can send BGP Update messages containing routing information.
  • Internal BGP neighbors:
    • It is considered a best practice to use a loopback interface for your neighbor addresses when configuring iBGP peers. The idea is that although you CAN use a physical interface IP, you run the risk of losing your BGP session if that physical interface goes down. Using a loopback works around this shortcoming, assuming multiple physical paths between the iBGP neighbors.
    • If you are peering with multiple neighbors, you can leverage the “neighbor <groupname> peer-group” command, which creates a peer-group. You can then apply commands to the peer group, rather than to every individual neighbor. This also reduces a bit of overhead on the BGP router, as the router will configure a common policy to be used by the group, rather than the same policy created several times, once for each peer.
    • iBGP and eBGP aren’t explicitly defined, but rather are inferred by the router by the ASN the neighbor is peering with.
  • External BGP neighbors:
    • eBGP peers often are connected via one physical link, and so using the physical interface as the source address is acceptable. If however, multiple physical paths are available, you can (and should) use a loopback interface so that the BGP session will survive a physical interface outage.
    • eBGP packets, by default, have a TTL of 1. Therefore, if your peer lives more than one hop away (true when you’re using loopbacks, among the more typical scenarios you might think of naturally), then you need to use the “neighbor ebgp-multihop” command, which allows you to place an optional integer at the end, representing the new TTL. If you don’t set this, the packet TTL will be decremented to 0 and die at the next router, not reaching the IP address needed to form a neighbor relationship.
  • What BGP routers check enroute to becoming “established”:
    • The incoming TCP request must come from a source address in the router’s configured “neighbor” command.
    • Although not true of confederations, the ASN the neighbor is coming from must match the configured ASN the local router thinks that neighbor is supposed to be coming from.
    • The BGP RIDs cannot be the same.
    • MD5 authentication, assuming it’s being used, must pass.
  • BGP router states (states they can be in on their way to being “established”):
    • Idle
    • Connect – listens for TCP
    • Active – listens for TCP, and initiates TCP (if neighbor IP addresses are mismatches in the peers’ configurations, this is where the BGP neighbor process will stall).
    • Open sent – TCP has been established, and a “BGP Open” message has been sent.
    • Open confirm – TCP has been established, and a “BGP Open message has been received as well as sent.
    • Established – the neighbor is up.
  • BGP message types (types of messages that BGP peers will send to one another)
    • Open – establish a neighbor relationship and exchange basic parameters.
    • Keepalive – maintains the neighbor relationship. If a keepalive isn’t heard within the “hold timer” expiration, then the neighbor is considered down.
    • Update – exchange of routing information
    • Notification – used when BGP errors happen. The neighbor will be reset when a notification message is sent.
  • Last but not least for tonight – you can reset the BGP session in a couple of different ways:
    • “neighbor xx.xx.xx.xx shutdown” in the router bgp paragraph will administratively shut down the connection to that neighbor.
    • From the # prompt, you can “clear ip bgp *” to reset all BGP neighbor relationships.