[FRR]: Port some patches from sonic-quagga repo#3017
[FRR]: Port some patches from sonic-quagga repo#3017pavel-shirshov merged 11 commits intosonic-net:masterfrom
Conversation
|
can you uncomment the invalid_nexthop vs test to make the patch is working? |
lguohan
left a comment
There was a problem hiding this comment.
uncomment invalid nexthop vs test please.
|
@lguohan Sure. Already did that. |
|
vs test failed. please check. https://sonic-jenkins.westus2.cloudapp.azure.com/job/vs/job/buildimage-vs-all-pr/85/console |
|
The nexthop patch is not correct. I have pushed a different version of it a while back into frr latest and I also have diffs to push for the others. The log change needs to be under a cli. Best to hold on to these for a bit until I push into frr the rest of the code. I'm fine after that to push into 7.0 latest and sync to that or commit into sonic-frr but please wait and lets not create patches. |
|
@nikos-github Thank you for your comment. I've ported your patch from the master to frr-7. |
|
retest this please |
|
retest vs please |
The change from info to debug in vty log needs to go under a cli cmd option. I have that already. Also the other patch that Guohan pointed me in quagga regarding the dscp, is also not correct and I had pointed that out to him and I have fixed in my diffs. |
|
@nikos-github |
|
|
||
| /* If NEXT_HOP is present, validate it. */ | ||
| if (attr->flag & ATTR_FLAG_BIT(BGP_ATTR_NEXT_HOP)) { | ||
| - if (attr->nexthop.s_addr == 0 |
There was a problem hiding this comment.
What failure are you seeing with the presence of the previous patch above that's forcing you to make this change?
There was a problem hiding this comment.
There was a problem hiding this comment.
@pavel-shirshov @lguohan This isn't the right way to address the case of an IPv6 NLRI being sent and a nexthop attribute of 0. The flag needs to be either cleared or the martian check needs to happen earlier for the relevant AFI/SAFIs. The diffs are just punching a hole in the code but the nexthop attribute flag still remains set. So for AFI/SAFI 1/1 with IPv6 nexthop and also the nexthop attribute present, this is still a problem. Same goes for any AFI/SAFI that is sent along with the 0 nexthop attribute - we will be skipping a valid check.
There was a problem hiding this comment.
@nikos-github Currently, when we allow bgpd to have 0.0.0.0 as next-hop ip address, bgpd tries to resolve the next-hop using zebra, zebra responds with the message "unresolved" and this next-hop is not used.
Also, why do you consider that this check was valid? I tried to find in the RFC why NEXT_HOP attribute can't be 0.0.0.0 and I didn't find anything. Probably I miss something. Can you please point me to the place in the RFC which says us we should filter-out next_hops equal to 0.0.0.0?
There was a problem hiding this comment.
@paulnice There is no such thing as nexthop of 0.0.0.0 for a prefix learned via a neighbor. Nexthops for prefixes received by peers, correspond to an interface address. 0.0.0.0 is not a valid interface address. It's all described in the RFC.
|
retest vs please |
1 similar comment
|
retest vs please |
|
@pavel-shirshov , tests are still failing. |
|
Hello, could someone tell me what vendor bug is |
|
Arista. |
…lly (#18051) #### Why I did it src/sonic-swss ``` * b18cbac - (HEAD -> master, origin/master, origin/HEAD) [Ci] Fix the test script naming issue (#3021) (81 minutes ago) [xumia] * 5fd896f - [PortOrch] Add FEC codeword errors in port stats (#3029) (87 minutes ago) [vdahiya12] * 77d56e6 - Fix the Orchagent crash seen during Port channel OC test cases. (#3042) (9 hours ago) [saksarav-nokia] * 4d47059 - Fix memory leak and object copying bugs in orchagent (#3017) (10 hours ago) [Saikrishna Arcot] ``` #### How I did it #### How to verify it #### Description for the changelog
Please don't merge it
- What I did
Port 3 patches from sonic-quagga.
- How I did it
Manually
- How to verify it
Build it and run on your dut
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)