skip to content

How do single-hop BFD (RFC 5881) and multihop BFD (RFC 5883) sessions differ, and why does single-hop insist on a TTL of 255?

level: middleimportance: should knowfreq 16%

answer

  1. one link versus any routed path
  2. 3784 versus 4784
  3. TTL check versus authentication
  4. no echo across hops
  5. loopback-to-loopback eBGP

basics

~20 s

Single-hop BFD runs over one link on UDP 3784 and sends and checks TTL 255, so only an on-link neighbour can inject packets; multihop BFD runs over routed paths on UDP 4784, relies on authentication instead, and forbids echo.

solid answer

~50 s

RFC 5881 single-hop BFD protects one IP hop: Control packets go to UDP port 3784 from a source port in 49152-65535, one session per interface and address family, bound to that interface. Packets MUST be sent with TTL or Hop Limit 255, and without authentication every received packet whose TTL is not 255 is discarded: any router in between would have decremented it, so a packet still at 255 can only come from the attached link (the GTSM idea of RFC 5082). RFC 5883 multihop BFD covers arbitrary routed paths, such as eBGP between loopbacks or an OSPF virtual link: it uses UDP 4784, demultiplexes the first packets by source and destination address, cannot use the TTL trick so it SHOULD use cryptographic authentication, and MUST NOT use the echo function, which intermediate hops would loop back early.

go deeper

for a junior

Recall the split: single-hop protects one link, multihop protects a routed path, and they use different UDP ports.

for a middle

Explain the TTL 255 rule as spoofing protection and why it cannot work across hops, and name what multihop uses instead.

for a senior

Pick the right session type per client: hand-off eBGP, loopback eBGP, OSPF virtual links and bundles, and predict what each one will and will not detect.

for a principal

Weigh where detection should sit: per-link single-hop sessions and micro-BFD against fewer multihop sessions that only fail when every path is gone.

## Two application documents for one protocol RFC 5880 defines BFD's packets and state machine but leaves **encapsulation** to application documents. Two of them carry BFD over IP: - **RFC 5881, single hop**: two systems on one IP hop, whether a physical link, a virtual circuit or a tunnel. - **RFC 5883, multihop**: two systems separated by any number of routed hops, over paths that may change and overlap. | Aspect | Single hop (RFC 5881) | Multihop (RFC 5883) | |---|---|---| | Control packets | UDP destination port 3784 | UDP destination port 4784 | | Source port | 49152-65535, fixed per session | Same encapsulation as single hop | | Echo function | Allowed, UDP port 3785 | MUST NOT be used | | Anti-spoofing | Send TTL/Hop Limit 255, check 255 on receipt | Cryptographic authentication SHOULD be used | | First-packet demultiplexing | By interface and address family | By source and destination address pair, or discriminators signalled out of band | | Typical clients | OSPF and IS-IS adjacencies, directly connected eBGP, static next hops | eBGP between loopbacks, OSPF virtual links | ## Why TTL 255 works on one hop Every router that forwards an IP packet decrements its TTL (IPv4) or Hop Limit (IPv6). If a sender always transmits with **255**, a packet that arrives still carrying 255 cannot have crossed a router: it was sent by a system on the attached link. RFC 5881 section 5 therefore says: 1. All Control packets MUST be sent with TTL or Hop Limit 255. 2. Without BFD authentication, every received packet demultiplexed to the session MUST be discarded unless its TTL is 255. 3. With authentication in use, the check becomes a MAY, and it may run before the cryptographic check to save CPU. This is the mechanism RFC 5082 generalises as the **Generalized TTL Security Mechanism (GTSM)**. An attacker several hops away cannot forge a BFD packet that would tear down a session, because the packet would arrive with a TTL below 255. ## Why multihop needs other answers RFC 5883 lists three problems a multihop path creates: - **Spoofing.** The TTL trick fails by definition, since legitimate packets also arrive with lower TTLs. Authentication SHOULD be used, and RFC 5883's security section strongly encourages strong forms of it. - **Demultiplexing.** Single-hop sessions are told apart by the interface they arrive on. Across hops two sessions can share interfaces, so the first packet (whose Your Discriminator is zero) is matched by the **source/destination address pair**, which means two sessions between the same systems need at least one different endpoint address. Alternatively the discriminators can be signalled out of band, as BFD for MPLS does. - **Echo.** An echo packet is addressed so the next router sends it straight back; across several hops the *first* router would return it, proving nothing about the rest of the path. Echo MUST NOT be used over multiple hops. ## Choosing between them in a design - **eBGP over a directly connected hand-off**: single-hop BFD to the peer's interface address. RFC 5882 says the session should go to the BGP neighbour, not to some other advertised next hop. - **eBGP between loopbacks across several links**: multihop BFD between the loopbacks. It detects loss of *every* path between them; if one link fails and routing moves the traffic in time, the multihop session can stay up, which is the intended behaviour. - **OSPF virtual links**: RFC 5882 says they MUST use the multihop mechanism, since a virtual link can traverse any number of hops. - **IPv4 and IPv6 on the same link**: two separate single-hop sessions, one per address family. - **A link bundle**: one single-hop session over the bundle runs on whichever member the hash picks, so it cannot see a single dead member. RFC 7130 adds **micro-BFD**, one asynchronous session per member on UDP port 6784, and a member is not used for traffic until its micro-BFD session is Up. ## Common misreadings - Multihop BFD is not simply single-hop BFD with a lower TTL check; it changes the port, the demultiplexing and the security model. - Port 3785 belongs to single-hop echo packets, not to multihop sessions. - RFC 5881's IANA section prints the echo port as 3875, a typographical slip; section 4 of the same RFC, which defines the encapsulation, says 3785.

  • Why can't one single-hop BFD session over a link bundle detect a single failed member, and what fixes it?
    A session over the bundle is one flow, so the hash places it on one member; if another member breaks, the session never notices while traffic hashed onto that member is lost. RFC 7130 micro-BFD runs an asynchronous session on every member, on UDP port 6784, and a member may not carry traffic until its micro-BFD session is Up.
  • An eBGP session runs between loopbacks with multihop BFD, and one of two parallel links fails. Does BFD go Down?
    Usually not, and that is correct. Multihop BFD follows whatever path routing gives the loopback addresses; if the IGP or static routing moves the traffic to the surviving link before the detection time expires, BFD keeps seeing packets. It goes Down only when no path between the loopbacks forwards for a full detection time.

saying these in an interview costs you the question

  • Multihop BFD is just single-hop BFD with the TTL check relaxed.
  • Multihop sessions should use the echo function to test the whole path.
  • The TTL 255 check is a performance optimisation, not an anti-spoofing measure.
  • One BFD session can protect IPv4 and IPv6 on the same link together.
  • A single BFD session over a link bundle detects any one failed member.