Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create README for RT-1.63_BGP_multihop #3512

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

ihebboubaker
Copy link
Contributor

This test case validates the multihop eBGP feature, where two BGP speakers establish a peering session even when they are not directly connected.

@ihebboubaker ihebboubaker requested review from dplore and a team as code owners October 11, 2024 12:23
@OpenConfigBot
Copy link

OpenConfigBot commented Oct 11, 2024

Pull Request Functional Test Report for #3512 / 9d8b64d

No tests identified for validation.

Help

@coveralls
Copy link

coveralls commented Oct 11, 2024

Pull Request Test Coverage Report for Build 11381880940

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 55.268%

Totals Coverage Status
Change from base Build 11379494154: 0.0%
Covered Lines: 1983
Relevant Lines: 3588

💛 - Coveralls

1) Configure the eBGP peering session: Establish an eBGP peering relationship between the DUT's loopback interface and the eBGP peer connected to ATE2. This means the DUT will use its loopback address as its BGP identifier.
2) Specify the neighbor address: Configure the DUT to use the eBGP peer's IP address (connected to ATE2) as the neighbor address for this BGP session.
3) Enable multihop: Since the eBGP peer is not directly connected to the DUT, enable the multihop option for this BGP neighbor on the DUT. Set the Time-to-Live (TTL) value to 2 to allow the BGP packets to traverse the intermediate link between the DUT and ATE2.
4) Validate session establishment: Confirm that the eBGP session is successfully established between the DUT's loopback interface and the eBGP peer connected to ATE2. This can be verified by checking the BGP neighbor status on both the DUT and the peer.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
4) Validate session establishment: Confirm that the eBGP session is successfully established between the DUT's loopback interface and the eBGP peer connected to ATE2. This can be verified by checking the BGP neighbor status on both the DUT and the peer.
4) Validate session establishment: Confirm that the eBGP session is successfully established between the DUT's loopback interface and the eBGP peer connected to ATE2. This can be verified by checking the BGP neighbor status on both the DUT and the ATE.

Copy link
Member

Choose a reason for hiding this comment

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

You'll need to specify the OC path for the DUT verification.

feature/bgp/multihop/README.md Show resolved Hide resolved
* BGP-V6 = 2001:db8:128:200::/64
2) Verify prefix reception: Confirm that the DUT successfully receives the advertised prefixes from the eBGP peer.
3) Check routing table: Inspect the DUT's routing table to ensure that the received prefixes have been installed correctly.
4) Validate next hop: Verify that the next hop associated with the installed prefixes in the DUT's routing table is the IP address of ATE Port 2. This confirms that the DUT knows to forward traffic for these prefixes towards ATE2.
Copy link
Member

Choose a reason for hiding this comment

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

Need to specify the paths used for this as there are a couple of options. I recommend using the afts table as we generally have not required the bgp rib paths (and adding them creates new dependencies on features only needed for test, which is not desirable if there are suitable alternatives) and there are no BMP paths in the OC model.

Here are some of the relevant leaves in the AFT tree (and AFTs is something we heavily use for many features)

/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/prefix

/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/next-hop-group

/network-instances/network-instance/afts/next-hop-groups/next-hop-group/state/id

/network-instances/network-instance/afts/next-hop-groups/next-hop-group/next-hops/next-hop/state/index

/network-instances/network-instance/afts/next-hops/next-hop/state/ip-address

/network-instances/network-instance/afts/next-hops/next-hop

feature/bgp/multihop/README.md Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants