As a BGP route for 203.0.113.0/24 crosses two eBGP borders and an iBGP mesh, which path attributes change, and where?
answer
- border versus inside
- prepend and rewrite at eBGP
- preference is added inside
- MED stops one AS out
basics
~20 sAt each eBGP border AS_PATH gains the sender's AS and NEXT_HOP is normally rewritten; LOCAL_PREF never crosses and is set afresh inside each AS; a received MED stops at the next AS; ORIGIN stays; COMMUNITIES pass unless policy edits them.
solid answer
~40 sCrossing an **eBGP** border, the sender prepends its own AS to `AS_PATH` and normally sets `NEXT_HOP` to its own address on the shared link. It never sends `LOCAL_PREF`; the receiving AS computes its own from local policy and must include it on every **iBGP** update. Inside the AS, `AS_PATH` and `NEXT_HOP` stay as they arrived, so internal routers need a route to the external next hop. A `MULTI_EXIT_DISC` received from the origin AS may travel over iBGP but MUST NOT go to any other neighbouring AS. `ORIGIN` is set once by the originator and SHOULD NOT change. `COMMUNITIES`, optional transitive, ride along unless an AS's policy adds or strips values.
go deeper
Recall the headline: AS_PATH grows and NEXT_HOP changes at eBGP borders, while LOCAL_PREF stays inside one AS.
Walk every attribute across both kinds of session and give the RFC 4271 rule for each, including MED's one-AS reach and the unchanged next hop inside the AS.
Connect each rule to a symptom: routes ignored for an unreachable next hop, a neighbour's MED appearing two ASes away, a preference that never left the AS.
Decide which attributes your AS honours, rewrites or strips at its borders, and how those choices stay consistent across every edge router.
## The set-up AS 64496 originates **203.0.113.0/24**. Its border router R1 (192.0.2.1) peers over eBGP with R2 (192.0.2.2) in transit AS 64500. Inside AS 64500, R2, R3 and R4 run iBGP in a full mesh. R4 (198.51.100.1) peers over eBGP with R5 (198.51.100.2) in AS 64510, and R5 runs iBGP with the rest of AS 64510. AS 64496 attaches `MULTI_EXIT_DISC` 20 to tell AS 64500 which of its links into AS 64496 to prefer, and the community `64496:100`. ## The route at every hop | Attribute | R1 to R2 (eBGP) | R2 to R3, R4 (iBGP in 64500) | R4 to R5 (eBGP) | R5 to iBGP peers in 64510 | |---|---|---|---|---| | `ORIGIN` | IGP | IGP | IGP | IGP | | `AS_PATH` | `64496` | `64496` | `64500 64496` | `64500 64496` | | `NEXT_HOP` | 192.0.2.1 | 192.0.2.1 | 198.51.100.1 | 198.51.100.1 | | `LOCAL_PREF` | not sent | set by 64500's policy, e.g. 200 | not sent | set by 64510's policy | | `MULTI_EXIT_DISC` | 20 | 20 may be carried | 64496's value not sent | whatever 64500 attached, if anything | | `COMMUNITIES` | `64496:100` | carried | carried unless policy strips it | carried | The value 200 is illustrative: RFC 4271 defines no default `LOCAL_PREF`, and any default number is an implementation choice. ## Attribute by attribute 1. **`ORIGIN`** is generated by the originating speaker and **SHOULD NOT** be changed by anyone else, so it reads IGP (0) end to end. 2. **`AS_PATH`** grows only at eBGP borders. R1 originates it as `64496`; R2 receives it, checks that 64500 is absent (the loop check) and passes it unchanged over iBGP; R4 prepends 64500 toward AS 64510. 3. **`NEXT_HOP`** toward an external peer one hop away is by default the address the sender uses for that session, so R1 sends 192.0.2.1 and R4 sends 198.51.100.1. RFC 4271 also allows a "third-party" next hop on a shared subnet. Toward an internal peer a speaker **SHOULD NOT** change it unless explicitly configured to announce its own address. 4. **`LOCAL_PREF`** **MUST NOT** be sent to an external peer (confederations aside), and one received from an external peer is ignored; RFC 7606 makes that an *attribute discard*. Each AS therefore computes its own value at its border and **SHALL** include it in every update to internal peers. 5. **`MULTI_EXIT_DISC`** is optional non-transitive. A value received over eBGP **MAY** be carried over iBGP, but **MUST NOT** be propagated to other neighbouring ASes. R4 may attach a fresh MED of 64500's own toward AS 64510; it may not forward 64496's 20. 6. **`COMMUNITIES`** is optional transitive. Speakers that do not recognise it pass it on; speakers that do may append, change or remove values by local policy. ## What the unchanged next hop costs inside an AS R3 receives the route with `NEXT_HOP` 192.0.2.1, an address on the link between AS 64496 and AS 64500. RFC 4271 has the speaker resolve that address through its routing table, and a route whose next hop **cannot be resolved MUST be excluded** from selection. So either the interior routing protocol must carry the border link, or R2 must be configured to announce its own address as next hop. Which approach to take belongs to the design of eBGP and iBGP sessions; the attribute rule is simply that iBGP leaves `NEXT_HOP` alone. ## Seeing the walk on a real speaker RFC 4271 gives each speaker three tables that make the walk observable: the **Adj-RIB-In** for each peer holds routes exactly as received, the **Loc-RIB** holds the routes the speaker selected, and the **Adj-RIB-Out** for each peer holds what it will advertise to that peer. Comparing R4's Adj-RIB-In entry from R2 with its Adj-RIB-Out entry toward R5 shows every border change at once: the prepended `64500`, the new `NEXT_HOP`, the missing `LOCAL_PREF` and the missing MED from AS 64496. If an attribute differs where the table above says it should not, local policy changed it. ## What the walk shows - **Two attributes normally change at every eBGP border** (`AS_PATH`, `NEXT_HOP`), and **neither changes inside an AS** by default. - **`LOCAL_PREF` lives and dies inside one AS**: every AS starts its own preference afresh. - **`MULTI_EXIT_DISC` reaches at most one AS beyond the one that set it.** - **`ORIGIN` and, absent policy, `COMMUNITIES` reach the far end unchanged**, which is what lets AS 64510 see how AS 64496 tagged its route. - **`ATOMIC_AGGREGATE` and `AGGREGATOR`** would appear only if some AS on the path had aggregated the prefix into a shorter one.
- In the walk, could R4 send AS 64510 a MULTI_EXIT_DISC at all?Yes, but only its own. RFC 4271 forbids passing the MED received from AS 64496 to another neighbouring AS. AS 64500 may attach a new MED of its own toward AS 64510, telling 64510 which of 64500's entry points to prefer when the two ASes have several links.
- R3 shows the route but never forwards along it. Which attribute is the first suspect?`NEXT_HOP`. Over iBGP it still reads 192.0.2.1, the external border link. If R3 has no route to that address, RFC 4271 requires the route to be excluded from selection. The fixes are carrying the link in the interior protocol or having the border announce its own address as next hop.
saying these in an interview costs you the question
- LOCAL_PREF set in AS 64500 still reaches AS 64510 over eBGP.
- Every iBGP speaker prepends its AS to the path as it passes the route on.
- MED is passed along from AS to AS like the communities are.
- NEXT_HOP is rewritten to the sending router on every iBGP session by the protocol.
- RFC 4271 gives LOCAL_PREF a default value of 100.
- A transit AS should reset ORIGIN to INCOMPLETE because it did not originate the route.