Skip to content
Log in Sign up My account

3.2.c eBGP Between Directly Connected Neighbors

Blueprint 3.2.c: Configure and verify eBGP between directly connected neighbors (best path selection algorithm and neighbor relationships)

  • BGP fundamentals: path vector, autonomous systems, TCP 179, message types
  • Neighbor relationships: requirements, the finite state machine, timers
  • Advertising routes with the network statement
  • Path attributes and the best path selection algorithm
  • Verification with show ip bgp summary, show ip bgp and show ip bgp neighbors

ENCOR keeps BGP small: one eBGP session between two routers on a shared subnet. iBGP, route reflectors, multihop design and redistribution are ENARSI material. Inside that scope the exam expects you to configure a session from scratch, advertise prefixes correctly, read the BGP table and know the best path order well enough to predict a winner from an exhibit.

BGP in one page

BGP is a path vector protocol. Each route carries a list of the autonomous systems it has crossed (the AS_PATH). A router that sees its own AS number in a received AS_PATH discards the route, which is how BGP prevents loops between autonomous systems.

Value
Transport TCP port 179. Both sides try to connect; one TCP session survives
Administrative distance eBGP 20, iBGP 200, locally originated aggregate 200
eBGP vs iBGP eBGP: neighbor in a different AS. iBGP: neighbor in the same AS
Keepalive / hold time 60 s / 180 s by default. The lower hold time of the two peers is used
eBGP TTL 1 by default, so the peer must be directly connected unless you change it
Private AS numbers 64512 to 65534 (16-bit), 4200000000 to 4294967294 (32-bit)
Router ID bgp router-id, else highest loopback IPv4 address, else highest active interface IPv4 address

Message types

Message Purpose
OPEN Starts the session. Carries version, AS number, hold time, router ID and capabilities
KEEPALIVE Keeps the session up, and confirms an OPEN
UPDATE Advertises new prefixes with their attributes, or withdraws prefixes
NOTIFICATION Reports an error, then the session is closed
ROUTE-REFRESH Asks the peer to resend its updates, used by clear ip bgp ... soft in

Neighbor relationships

BGP does not discover neighbors. Each side names the other with neighbor <ip> remote-as <asn>. The session comes up only when:

  • The neighbor address on each side matches the source address of the other side's TCP packets. On a directly connected link this is the interface address.
  • The remote-as on each side matches the AS configured under router bgp on the other side.
  • TCP 179 is reachable and not blocked by an ACL.
  • For eBGP, the peer is reachable within the TTL (1 by default).
  • If configured, the MD5 password (neighbor <ip> password) matches on both sides.
  • The two router IDs are different.

States

graph LR
  I["Idle"] --> C["Connect<br/>TCP attempt"]
  C -->|"TCP fails"| A["Active<br/>retrying"]
  A -->|"TCP up"| OS["OpenSent"]
  C -->|"TCP up"| OS
  OS --> OC["OpenConfirm"]
  OC -->|"KEEPALIVE"| E["Established"]
  E -->|"NOTIFICATION or<br/>hold timer"| I
State Meaning What it tells you when stuck
Idle Not trying. Initial state, or after an error Idle (Admin) means neighbor shutdown. Plain Idle can mean no route to the neighbor
Connect Waiting for the TCP handshake Usually brief
Active TCP failed, retrying and listening Despite the name, this is bad: no TCP session. Check addressing, reachability, ACLs, wrong neighbor IP
OpenSent OPEN sent, waiting for the peer's OPEN
OpenConfirm OPEN received, waiting for KEEPALIVE A bad OPEN (wrong AS, duplicate router ID) triggers a NOTIFICATION and the session drops back to Idle
Established Session up, UPDATEs flow show ip bgp summary shows a prefix count instead of a state

Exam trap

Active is not a good state. A neighbor that cycles between Idle and Active has no TCP session. A wrong remote-as gets further: TCP comes up, then the OPEN is rejected and IOS logs a "bad remote AS" NOTIFICATION. Use the state to pick the layer: Active points to IP and TCP, a NOTIFICATION after OpenSent points to BGP parameters.

Peering between loopbacks

ENCOR only asks for directly connected eBGP, but you must recognise why loopback peering fails without two extra commands. The TCP packets are sourced from the outgoing interface unless you set update-source, and eBGP packets have TTL 1, so a peer two hops away (or behind a loopback) is not reached.

router bgp 65001
 neighbor 10.255.255.9 remote-as 65000
 neighbor 10.255.255.9 update-source Loopback0
 neighbor 10.255.255.9 ebgp-multihop 2
! plus a static or IGP route to 10.255.255.9

neighbor <ip> disable-connected-check is an alternative to ebgp-multihop when the loopbacks belong to directly connected routers.

Configuring eBGP

router bgp 65001
 bgp router-id 10.255.255.1
 bgp log-neighbor-changes
 neighbor 203.0.113.2 remote-as 65000
 neighbor 203.0.113.2 description ISP
 network 10.0.0.0 mask 255.0.0.0
!
ip route 10.0.0.0 255.0.0.0 Null0

router bgp 65001
 bgp router-id 10.255.255.1
 neighbor 203.0.113.2 remote-as 65000
 !
 address-family ipv4 unicast
  neighbor 203.0.113.2 activate
  network 10.0.0.0 mask 255.0.0.0
 exit-address-family

router bgp 65001
 bgp router-id 10.255.255.1
 neighbor 2001:db8:1:9::2 remote-as 65000
 !
 address-family ipv6 unicast
  neighbor 2001:db8:1:9::2 activate
  network 2001:db8:100::/48
 exit-address-family
!
ipv6 route 2001:db8:100::/48 Null0
show bgp ipv6 unicast summary
show bgp ipv6 unicast

IPv4 unicast is activated automatically for every neighbor unless no bgp default ipv4-unicast is configured. IPv6 neighbors must be activated under address-family ipv6 unicast, or the session comes up with nothing exchanged.

The network statement

The BGP network command is not like the OSPF or EIGRP one. It does not enable BGP on interfaces. It says: if this exact prefix is in the routing table, advertise it.

  • The prefix and mask must match a route in the RIB exactly. It can come from any source: connected, static, OSPF.
  • Without mask, IOS assumes the classful mask (/8, /16 or /24).
  • A route originated by network gets origin code i (IGP). Routes injected with redistribute get ? (incomplete).
  • To advertise an aggregate that is not in the RIB, create a static route to Null0 for it, as in the example. That route is always present, so the advertisement is stable.

Exam trap

network 192.168.10.0 mask 255.255.255.0 advertises nothing if the RIB only has 192.168.10.0/25 and 192.168.10.128/25. The match is exact, not "covers". Either match a real prefix, add a Null0 static for the /24, or use aggregate-address (ENARSI). Watch for a missing mask keyword too: network 172.16.1.0 means 172.16.0.0/16 classful, not /24.

Path attributes

Every BGP route carries attributes. The best path algorithm compares them.

Attribute Category Set by / scope Preferred
ORIGIN Well-known mandatory Originating router: i, e or ? i, then e, then ?
AS_PATH Well-known mandatory Each eBGP speaker prepends its AS Shorter
NEXT_HOP Well-known mandatory eBGP sets it to its own address Must be reachable
LOCAL_PREF Well-known discretionary Inside one AS only, not sent to eBGP peers. Default 100 Higher
MED (MULTI_EXIT_DISC) Optional non-transitive Sent to a neighboring AS to suggest an entry point. Default 0 when missing Lower
COMMUNITY Optional transitive Tags for policy Not compared
Weight Cisco proprietary, not a real attribute Local to one router, never advertised. 0 for learned routes, 32768 for locally originated Higher

The categories in one sentence each: well-known mandatory attributes are in every UPDATE; well-known discretionary attributes are understood by every BGP router but may be absent; optional transitive attributes are passed on even by routers that do not understand them; optional non-transitive attributes are dropped by routers that do not understand them, and MED is not passed beyond the neighboring AS.

Best path selection

A router may learn the same prefix from several neighbors. It picks one best path (marked > in show ip bgp), installs it in the RIB and advertises only that one. Paths whose next hop is unreachable are not considered. The order on IOS XE:

Step Attribute Prefer Scope
1 Weight Highest This router only
2 Local preference Highest The whole AS
3 Locally originated Paths this router originated (network, aggregate-address, redistribute)
4 AS_PATH length Shortest
5 Origin i, then e, then ?
6 MED Lowest. By default only compared between paths from the same neighboring AS
7 Path type eBGP over iBGP
8 IGP metric to the next hop Lowest
9 Age Oldest eBGP path (stability)
10 Router ID Lowest neighbor router ID
11 Cluster list Shortest (route reflection)
12 Neighbor address Lowest

A common memory aid for the first eight is "We Love Oranges AS Oranges Mean Pure Refreshment": Weight, Local preference, Originated, AS path, Origin, MED, Paths (eBGP over iBGP), Router (IGP metric to next hop), then the tie-breakers.

graph TB
  S["Same prefix from<br/>several neighbors"] --> NH{"Next hop<br/>reachable?"}
  NH -->|"no"| X["Path ignored"]
  NH -->|"yes"| W["1 Highest weight"]
  W --> LP["2 Highest local pref"]
  LP --> LO["3 Locally originated"]
  LO --> AP["4 Shortest AS path"]
  AP --> OR["5 Lowest origin i, e, ?"]
  OR --> MED["6 Lowest MED"]
  MED --> EB["7 eBGP over iBGP"]
  EB --> IGP["8 Lowest IGP metric to next hop"]
  IGP --> TB["9 to 12 tie-breakers"]

Influence outbound traffic (which way your traffic leaves) with weight (one router) or local preference (whole AS). Influence inbound traffic (which way other ASes send traffic to you) with AS_PATH prepending or MED.

Exam trap

The algorithm stops at the first attribute that differs. A path with weight 100 and an AS_PATH of five ASes beats a path with weight 0 and an AS_PATH of one AS. When reading an exhibit, compare column by column in order (Weight, LocPrf, AS path length, origin code, Metric) and stop at the first difference. Do not start with the AS path because it is the most visible column.

Exam trap

Local preference is not sent to eBGP neighbors, so you cannot use it to influence how another AS reaches you. Setting local preference outbound toward an ISP has no effect on the ISP. For inbound influence use AS_PATH prepend or MED.

Verification

R1# show ip bgp summary
BGP router identifier 10.255.255.1, local AS number 65001
BGP table version is 4, main routing table version 4
...
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
203.0.113.2     4        65000      12      11        4    0    0 00:07:21        2

The number under State/PfxRcd means the session is Established and two prefixes were received. A word there (Idle, Active, Idle (Admin)) means it is not.

R1# show ip bgp
BGP table version is 4, local router ID is 10.255.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.0.0.0         0.0.0.0                  0         32768 i
 *>   192.0.2.0        203.0.113.2              0             0 65000 i
 *>   198.51.100.0     203.0.113.2              0             0 65000 i

How to read it:

  • *> means valid and best. r would mean the route lost to a better AD source in the RIB.
  • Next hop 0.0.0.0 and weight 32768 mean the route is locally originated.
  • The Path column lists AS numbers, nearest first, and ends with the origin code.
  • IOS omits the prefix length when it equals the classful mask, so 10.0.0.0 is 10.0.0.0/8 and 192.0.2.0 is a /24.
R1# show ip route bgp
B        192.0.2.0/24 [20/0] via 203.0.113.2, 00:07:10
B        198.51.100.0/24 [20/0] via 203.0.113.2, 00:07:10

R1# show ip bgp neighbors 203.0.113.2 | include BGP state|hold time
  BGP state = Established, up for 00:07:21
  Last read 00:00:21, last write 00:00:17, hold time is 180, keepalive interval is 60 seconds

Other useful commands: show ip bgp neighbors <ip> advertised-routes (what you send), show ip bgp neighbors <ip> routes (what you accepted), show ip bgp <prefix> (every path for one prefix, with the reason the best one won), and clear ip bgp <ip> soft in|out to apply a policy change without resetting the session.

Lab: eBGP to the ISP

Topology: module lab, R1 and ISP, starting from the week 4 OSPF baseline. R1 Gi0/0 203.0.113.1/30, ISP Gi0/0 203.0.113.2/30. ISP has Loopback1 192.0.2.1/24 and Loopback2 198.51.100.1/24. Goal: bring up eBGP, advertise the enterprise aggregate, and influence a path in each direction.

graph LR
  R2["R2 and R3<br/>OSPF, 10.x"] --- R1["R1 AS 65001<br/>advertises 10.0.0.0/8"]
  R1 -- "Gi0/0 203.0.113.0/30 eBGP" --- ISP["ISP AS 65000<br/>192.0.2.0/24<br/>198.51.100.0/24"]

  1. On ISP, configure AS 65000, a neighbor statement for R1 and network statements for both loopback prefixes with their /24 masks.

    router bgp 65000
 bgp router-id 10.255.255.9
 neighbor 203.0.113.1 remote-as 65001
 network 192.0.2.0 mask 255.255.255.0
 network 198.51.100.0 mask 255.255.255.0

  2. On R1, configure AS 65001 with router ID 10.255.255.1 and a neighbor statement for ISP, with a deliberate mistake: remote-as 65009. Watch the log and show ip bgp summary. TCP comes up, but R1 receives an OPEN from AS 65000, sends a NOTIFICATION (peer in wrong AS) and drops the session. Both routers log it; the exact wording varies by release. Fix it to 65000 and confirm the prefix count reaches 2.

  3. On R1, add network 10.0.0.0 mask 255.0.0.0. Check ISP: nothing arrives, because R1 has no exact 10.0.0.0/8 in its RIB. Add ip route 10.0.0.0 255.0.0.0 Null0 on R1 and check again.

    ISP# show ip bgp | include 10.0.0.0
 *>   10.0.0.0         203.0.113.1              0             0 65001 i

  4. Give R2 and R3 a way out. On ISP, add neighbor 203.0.113.1 default-originate so R1 learns B* 0.0.0.0/0 [20/0]. Then add default-information originate under router ospf 1 on R1, which only works while a default route is in R1's RIB. R2 and R3 now show O*E2 0.0.0.0/0, and R1 is an ASBR. Ping 192.0.2.1 from R3 with ping 192.0.2.1 source Loopback1.

  5. Outbound policy on R1: give 192.0.2.0/24 a local preference of 200 with an inbound route-map, then soft-reset.

    ip prefix-list DOC2 seq 5 permit 192.0.2.0/24
route-map FROM-ISP permit 10
 match ip address prefix-list DOC2
 set local-preference 200
route-map FROM-ISP permit 20
!
router bgp 65001
 neighbor 203.0.113.2 route-map FROM-ISP in
!
clear ip bgp 203.0.113.2 soft in

    show ip bgp now shows 200 in the LocPrf column for 192.0.2.0 only. The empty permit 20 sequence keeps every other prefix; without it the implicit deny would drop them.

  6. Inbound policy toward R1: prepend AS 65001 twice on routes sent to ISP.

    route-map TO-ISP permit 10
 set as-path prepend 65001 65001
router bgp 65001
 neighbor 203.0.113.2 route-map TO-ISP out
!
clear ip bgp 203.0.113.2 soft out

    On ISP, the path for 10.0.0.0 now reads 65001 65001 65001 i. With a second provider, that longer path would steer other networks toward the other entry point. Sim 05 has the dual-homed version.

  7. Save copy running-config flash:week5-bgp.cfg. The PBR lab on the next page starts here.

Quick check

show ip bgp summary on R1 shows the neighbor in Active state for several minutes. Name three things to check.

Reachability of the neighbor address (ping it from the correct source), that the neighbor IP configured on each side is the other side's actual interface address, and that no ACL blocks TCP 179. Active means the TCP session itself is not forming.

Two paths to 172.20.0.0/16: path A has weight 0, local preference 300, AS path 65010 65020 65030. Path B has weight 0, local preference 100, AS path 65040. Which wins and at which step?

Path A, at step 2. Weight ties at 0, and local preference 300 beats 100. The AS path length is never compared.

Why does R1 show 32768 in the Weight column for 10.0.0.0/8?

The route is originated locally by the network statement. IOS gives locally originated routes a weight of 32768 and learned routes a weight of 0.

References