Skip to content

[doc/voq]: Add HLD for BGP in the VoQ chassis - #674

Merged
arlakshm merged 4 commits into
sonic-net:masterfrom
jmmikkel:master-chassisbgphld
Apr 7, 2021
Merged

[doc/voq]: Add HLD for BGP in the VoQ chassis#674
arlakshm merged 4 commits into
sonic-net:masterfrom
jmmikkel:master-chassisbgphld

Conversation

@jmmikkel

Copy link
Copy Markdown
Contributor

This document describes how BGP will be configured between each FSI in the chassis.

Signed-off-by: jmmikkel@arista.com
@ghost

ghost commented Sep 10, 2020

Copy link
Copy Markdown

CLA assistant check
All CLA requirements met.

Comment thread doc/voq/bgp_voq_chassis.md Outdated
# 1 Requirements

Traffic ingressing on any FSI should be routed the same, regardless of which
FSIs learned the route from their eBGP peers.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replace FSI with Asic Instance

- Each FSI must advertise eBGP-learned routes to the other FSIs in the chassis.
- Each FSI in a chassis should choose the same BGP route for each prefix.
- When ECMP is enabled and equal-cost routes are learned by any FSI, all FSIs should compute the same ECMP nexthop.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a note on preserving the nexthop and the AS_PATH

Comment thread doc/voq/bgp_voq_chassis.md Outdated

# 1 Requirements

Traffic ingressing on any FSI should be routed the same, regardless of which

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarify that forwarding behavior can be different, but the nexthop set for the ECMP will be same

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarify that this is substantially different from an internal-ethernet-clos based chassis because the forwarding decision is made once at the ingress in voq chassis and several times in an ethernet based chassis.

- Each FSI must advertise eBGP-learned routes to the other FSIs in the chassis.
- Each FSI in a chassis should choose the same BGP route for each prefix.
- When ECMP is enabled and equal-cost routes are learned by any FSI, all FSIs should compute the same ECMP nexthop.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Restriction: The external routers are connected via eBGP and not iBGP

Comment thread doc/voq/bgp_voq_chassis.md Outdated
To ensure that each FSI computes the same ECMP group:
- Enable additional-path send all for each chassis iBGP peer. If FSI1 learns a route from both R1 and R4, both must be advertised to other FSIs.
- Allow BGP to form ECMP groups with paths learned from both eBGP and iBGP peers. The best path algorithm normally prefers eBGP paths (RFC 4271 section 9.1.2.2 step d). Without this change, if a route is learned from R1, R2, and R4, FSI1 would create ECMP group {R1,R4}, FSI2 would use {R2}, and FSI3 would use {R1,R2,R4}.
- The maximum ECMP group size must be set the same for eBGP and iBGP.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expand this point a bit more.

Comment thread doc/voq/bgp_voq_chassis.md Outdated
- `neighbor <neighbor> addpath-tx-all-paths`
- `bgp bestpath peer-type multipath-relax`
- `maximum-paths ibgp <n>` (where <n> is the same as used in `maximum-paths <n>`)
- `bgp disable-ebgp-connected-route-check`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can change existing eBGP behavior. Need to note down what FRR does today when the nexthop is not over a connected route.

Comment thread doc/voq/bgp_voq_chassis.md Outdated
<a:ASN>64542</a:ASN>
<a:Hostname>OCPSCH0104001MS</a:Hostname>
<a:RouteMaps/>
<a:VoQChassisPeer>1</a:VoQChassisPeer>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add this to BGP_SESSION definition

<a:VoQChassisPeer>1</a:VoQChassisPeer>
</a:BGPRouterDeclaration>
```

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a Cli section

  1. "show ip bgp" shows both internal and external today, should we update the command to show only the external sessions and add a new command to include the internal.
  2. A flag that brings up the instance with bgp sessions shut down must not do it for the internal BGP sessions.
  3. 'shutdown' should bring down only the external sessions, not the internal BGP sessions. We need an additional token to also shutdown the internal sessions if needed.

The functional changes are:
- Propose to modify bgpd's publish of nexthop groups to RIB instead
  of using "bgp disable-ebgp-connected-route-check".
- Change the new element in the minigraph to
  BGPSession>VoQChassisInternal.
- Add discussion of BGP commands in the CLI.
@anshuv-mfst

Copy link
Copy Markdown
Collaborator

@minionatwork

@rlhui

rlhui commented Feb 6, 2021

Copy link
Copy Markdown
Contributor

@arlakshm

@anshuv-mfst
anshuv-mfst requested a review from arlakshm March 22, 2021 18:42
@arlakshm
arlakshm merged commit 6fdeba0 into sonic-net:master Apr 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants