Skip to content

GoBGP incorrectly accepts confederation-internal session with a non-member peer and installs routes #3315

@rsingha108

Description

@rsingha108

Description

When a BGP session is configured as internal within a confederation, GoBGP accepts and installs routes from a neighbor that is not actually a member of the confederation. In this scenario, the neighbor shares the confederation ID but has no sub-AS membership. FRR and Batfish correctly reject the route, but GoBGP installs it, indicating it misclassifies the peer as confed-internal and permits Member-AS usage toward a non-member.

Steps to Reproduce

  1. Start two GoBGP instances:
    • Router2: AS 65000, configured as a confederation member with subAS 101.
    • Router3: AS 65000, not configured as a confederation member.
  2. Configure an internal (iBGP) session between Router2 and Router3 (peer-as 65000 for both).
  3. From Router2, advertise a route originated by AS 65153 with LocalPref 200; do not remove or replace private ASNs.
  4. Check Router3’s RIB: observe that the route from Router2 is installed.

Buggy Behavior

Router3 (GoBGP) installs the route in its RIB even though the neighbor is not a confederation member; the AS_PATH on Router3 is empty, suggesting the session was treated as confed-internal. In contrast, FRR and Batfish reject the route in this setup.

Expected Behavior

A session to a neighbor that is not a confederation member should not be treated as confed-internal, and routes using Member-AS toward such a neighbor should be rejected (no route installed).
As per RFC [4]: A member of a BGP confederation MUST use its Member-AS Number in all transactions with peers that are members of the same confederation as the local BGP speaker.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions