[chassis/multi-asic] Make sure iBGP session established as directly connected #16777
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peer device's Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
higher value so that BGP learnt default route is higher priority. Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
by using Generic TTL security mechanisim. Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
abdosi
changed the title
|
@arlakshm can you please help with review of this |
|
@lguohan / @StormLiangMS can you please help with merge of this. |
judyjoseph
approved these changes
Oct 6, 2023
lguohan
approved these changes
Oct 10, 2023
|
@abdosi PR conflicts with 202305 branch |
|
@yxieca can you review if this can be approved for 202205? |
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Oct 25, 2023
…onnected (sonic-net#16777) What I did: Make Sure for internal iBGP we are one-hop away (directly connected) by using Generic TTL security mechanism. Why I did: Without this change it's possible on packet chassis i-BGP can be established even if there no direct connection. Below is the example - Let's say we have 3 LC's LC1/LC2/LC3 each having i-BGP session session with each other over Loopback4096 - Each LC's have static route towards other LC's Loopback4096 to establish i-BGP session - LC1 learn default route 0.0.0.0/0 from it's e-BGP peers and send it over to LC2 and LC3 over i-BGP - Now for some reason on LC2 static route towards LC3 is removed/not-present/some-issue we expect i-BGP session should go down between LC2 and LC3 - However i-BGP between LC2 and LC3 does not go down because of feature ip nht-resolve-via-default where LC2 will use default route to reach Loopback4096 of LC3. As it's using default route BGP packets from LC2 towards LC3 will first route to LC1 and then go to LC3 from there. Above scenario can result in packet mis-forwarding on data plane How I fixed it:- To make sure BGP packets between i-BGP peers are not going with extra routing hop enable using GTSM feature neighbor PEER ttl-security hops NUMBER This command enforces Generalized TTL Security Mechanism (GTSM), as specified in RFC 5082. With this command, only neighbors that are the specified number of hops away will be allowed to become neighbors. This command is mutually exclusive with ebgp-multihop. We set hop count as 1 which makes FRR to reject BGP connection if we receive BGP packets if it's TTL < 255. Also setting this attribute make sure i-BGP frames are originated with IP TTL of 255. How I verify: Manual Verification of above scenario. See blow BGP packets receive with IP TTL 254 (additional routing hop) we are seeing FIN TCP flags as BGP is rejecting the connection Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
|
Cherry-pick PR to 202205: #16997 |
mssonicbld
pushed a commit
that referenced
this pull request
Oct 25, 2023
…onnected (#16777) What I did: Make Sure for internal iBGP we are one-hop away (directly connected) by using Generic TTL security mechanism. Why I did: Without this change it's possible on packet chassis i-BGP can be established even if there no direct connection. Below is the example - Let's say we have 3 LC's LC1/LC2/LC3 each having i-BGP session session with each other over Loopback4096 - Each LC's have static route towards other LC's Loopback4096 to establish i-BGP session - LC1 learn default route 0.0.0.0/0 from it's e-BGP peers and send it over to LC2 and LC3 over i-BGP - Now for some reason on LC2 static route towards LC3 is removed/not-present/some-issue we expect i-BGP session should go down between LC2 and LC3 - However i-BGP between LC2 and LC3 does not go down because of feature ip nht-resolve-via-default where LC2 will use default route to reach Loopback4096 of LC3. As it's using default route BGP packets from LC2 towards LC3 will first route to LC1 and then go to LC3 from there. Above scenario can result in packet mis-forwarding on data plane How I fixed it:- To make sure BGP packets between i-BGP peers are not going with extra routing hop enable using GTSM feature neighbor PEER ttl-security hops NUMBER This command enforces Generalized TTL Security Mechanism (GTSM), as specified in RFC 5082. With this command, only neighbors that are the specified number of hops away will be allowed to become neighbors. This command is mutually exclusive with ebgp-multihop. We set hop count as 1 which makes FRR to reject BGP connection if we receive BGP packets if it's TTL < 255. Also setting this attribute make sure i-BGP frames are originated with IP TTL of 255. How I verify: Manual Verification of above scenario. See blow BGP packets receive with IP TTL 254 (additional routing hop) we are seeing FIN TCP flags as BGP is rejecting the connection Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
mssonicbld
added
Included in 202205 Branch
and removed
Approved for 202205 Branch
Created PR to 202205 Branch
labels
|
@abdosi , |
lguohan
pushed a commit
that referenced
this pull request
Nov 18, 2023
What I did: Revert the GTSM feature for VOQ iBGP session done as part of #16777. Why I did: On VOQ chassis BGP packets go over Recycle Port and then for Ingress Pipeline Routing making ttl as 254 and failing single hop check. Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
abdosi
added a commit
to abdosi/sonic-buildimage
that referenced
this pull request
Nov 20, 2023
…onnected (sonic-net#16777) What I did: Make Sure for internal iBGP we are one-hop away (directly connected) by using Generic TTL security mechanism. Why I did: Without this change it's possible on packet chassis i-BGP can be established even if there no direct connection. Below is the example - Let's say we have 3 LC's LC1/LC2/LC3 each having i-BGP session session with each other over Loopback4096 - Each LC's have static route towards other LC's Loopback4096 to establish i-BGP session - LC1 learn default route 0.0.0.0/0 from it's e-BGP peers and send it over to LC2 and LC3 over i-BGP - Now for some reason on LC2 static route towards LC3 is removed/not-present/some-issue we expect i-BGP session should go down between LC2 and LC3 - However i-BGP between LC2 and LC3 does not go down because of feature ip nht-resolve-via-default where LC2 will use default route to reach Loopback4096 of LC3. As it's using default route BGP packets from LC2 towards LC3 will first route to LC1 and then go to LC3 from there. Above scenario can result in packet mis-forwarding on data plane How I fixed it:- To make sure BGP packets between i-BGP peers are not going with extra routing hop enable using GTSM feature neighbor PEER ttl-security hops NUMBER This command enforces Generalized TTL Security Mechanism (GTSM), as specified in RFC 5082. With this command, only neighbors that are the specified number of hops away will be allowed to become neighbors. This command is mutually exclusive with ebgp-multihop. We set hop count as 1 which makes FRR to reject BGP connection if we receive BGP packets if it's TTL < 255. Also setting this attribute make sure i-BGP frames are originated with IP TTL of 255. How I verify: Manual Verification of above scenario. See blow BGP packets receive with IP TTL 254 (additional routing hop) we are seeing FIN TCP flags as BGP is rejecting the connection Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
|
StormLiangMS
pushed a commit
that referenced
this pull request
Nov 22, 2023
* [chassis/multi-asic] Make sure iBGP session established as directly connected (#16777) What I did: Make Sure for internal iBGP we are one-hop away (directly connected) by using Generic TTL security mechanism. Why I did: Without this change it's possible on packet chassis i-BGP can be established even if there no direct connection. Below is the example - Let's say we have 3 LC's LC1/LC2/LC3 each having i-BGP session session with each other over Loopback4096 - Each LC's have static route towards other LC's Loopback4096 to establish i-BGP session - LC1 learn default route 0.0.0.0/0 from it's e-BGP peers and send it over to LC2 and LC3 over i-BGP - Now for some reason on LC2 static route towards LC3 is removed/not-present/some-issue we expect i-BGP session should go down between LC2 and LC3 - However i-BGP between LC2 and LC3 does not go down because of feature ip nht-resolve-via-default where LC2 will use default route to reach Loopback4096 of LC3. As it's using default route BGP packets from LC2 towards LC3 will first route to LC1 and then go to LC3 from there. Above scenario can result in packet mis-forwarding on data plane How I fixed it:- To make sure BGP packets between i-BGP peers are not going with extra routing hop enable using GTSM feature neighbor PEER ttl-security hops NUMBER This command enforces Generalized TTL Security Mechanism (GTSM), as specified in RFC 5082. With this command, only neighbors that are the specified number of hops away will be allowed to become neighbors. This command is mutually exclusive with ebgp-multihop. We set hop count as 1 which makes FRR to reject BGP connection if we receive BGP packets if it's TTL < 255. Also setting this attribute make sure i-BGP frames are originated with IP TTL of 255. How I verify: Manual Verification of above scenario. See blow BGP packets receive with IP TTL 254 (additional routing hop) we are seeing FIN TCP flags as BGP is rejecting the connection Signed-off-by: Abhishek Dosi <abdosi@microsoft.com> * Update peer-group.conf.j2 * Update result_all.conf * Update result_base.conf --------- Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
StormLiangMS
added
Included in 202305 Branch
and removed
Cherry Pick Conflict_202305
labels
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Nov 29, 2023
What I did: Revert the GTSM feature for VOQ iBGP session done as part of sonic-net#16777. Why I did: On VOQ chassis BGP packets go over Recycle Port and then for Ingress Pipeline Routing making ttl as 254 and failing single hop check. Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
yxieca
pushed a commit
that referenced
this pull request
Nov 30, 2023
What I did: Revert the GTSM feature for VOQ iBGP session done as part of #16777. Why I did: On VOQ chassis BGP packets go over Recycle Port and then for Ingress Pipeline Routing making ttl as 254 and failing single hop check. Signed-off-by: Abhishek Dosi <abdosi@microsoft.com> Co-authored-by: abdosi <58047199+abdosi@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I did:
Make Sure for internal iBGP we are one-hop away (directly connected) by using Generic TTL security mechanism.
Why I did:
Without this change it's possible on packet chassis i-BGP can be established even if there no direct connection. Below is the example
0.0.0.0/0from it's e-BGP peers and send it over to LC2 and LC3 over i-BGPip nht-resolve-via-defaultwhere LC2 will use default route to reach Loopback4096 of LC3. As it's using default route BGP packets from LC2 towards LC3 will first route to LC1 and then go to LC3 from there.How I fixed it:-
GTSMfeatureHow I verfiy:
Manual Verification of above scenario. See blow BGP packets receive with IP TTL 254 (additional routing hop) we are seeing FIN TCP flags as BGP is rejecting the connection