-
Notifications
You must be signed in to change notification settings - Fork 147
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
base: main
Are you sure you want to change the base?
Conversation
Pull Request Test Coverage Report for Build 11381880940Details
💛 - Coveralls |
feature/bgp/multihop/README.md
Outdated
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
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
Outdated
* 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. |
There was a problem hiding this comment.
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-hops/next-hop/state/ip-address
This test case validates the multihop eBGP feature, where two BGP speakers establish a peering session even when they are not directly connected.