Peering iBGP vs. EBGP

iBGP:

• Packets default to TTL 255
  • Neighbors do not have to be connected as long as IGP reachability exists.
• Peers typically peer via Loopbacks
  • ‘neighbor x.x.x.x update-source l0’
  • Allows rerouting around failed paths via IGP.
  • Required for things like MPLS L3VPN.
• Loop Prevention
  • iBGP learned routes cannot be advertised on to another iBGP neighbor.
  • BGP requires the following:
    • Full Mesh
    • Route Reflectors
    • Confederation
• Next Hop Processing
  • Outbound iBGP updates do not modify next-hop regardless of iBGP type.
  • Modifying next hop:
    • ‘neighbor next-hop-self’
    • Route map
      • action – set next-hop
    • IOS 15.1(1)SY – next-hop-self ALL

EBGP:

• Packets default to TTL 1
  • Can be modified if needed.
  • ‘neighbor ebgp-multihop <ttl>’
  • ‘neighbor ttl-security hops <ttl>’
• Single hop peers must be directly connected by default.
  • Can be modified if directly connected neighbors peer via Loopbacks.
  • neighbor disable-connected-check.
• Loop Prevention
  • AS-Path
    • Local ASN is prepended to outbound updates.
    • Inbound updates containing local ASN are discarded.
    • Can be modified with the following:
      • ‘neighbor allowas-in’
      • ‘as-override’
• Next Hop Processing
  • Outbound EBGP updates have local update-source set to next-hop by default.
  • Modification
    • Route map
      • action – set next-hop
    • ‘neighbor next-hop-unchanged’

General:

• BGP next hop controls IGP route recursion.
  • BGP knows the next hop but not the outgoing interface.
    • BGP is not a routing protocol by itself.
  • IGP must be able to perform recursion otherwise route cannot be used.
  • Result of failed recursion means route does not get installed into RIB.