-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Issue 1968 defaultvrfonly #2042
Issue 1968 defaultvrfonly #2042
Conversation
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-3255/ This is a comment from an EXPERIMENTAL automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings:
CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base20 Static Analyzer issues remaining.See details at |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
d7cd097
to
9266916
Compare
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-3259/ This is a comment from an EXPERIMENTAL automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base20 Static Analyzer issues remaining.See details at |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
9266916
to
e407804
Compare
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-3299/ This is a comment from an EXPERIMENTAL automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base20 Static Analyzer issues remaining.See details at |
} | ||
|
||
if (vrf_is_user_cfged(vrf)) { | ||
} else if (vrf_is_user_cfged(vrf)) { |
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.
This is the wrong fix. We should use the vty_frame() code to display vrf config information.
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.
Hi Donald,
the issue is related to default routing table.
please tell me if I am wrong.
I am on VRF netns mode.
if I configure a static route on default VRF, then I should not see default VRF table appear.
I expect static route be on configure terminal.
Actually this is not the case.
#configure terminal
ip route 5.5.5.0/24 tun1
#
#show running-config
...
vrf Default-IP-Routing-Table
ip route 5.5.5.0/24 tun1
!
...
I don't see the point here with vty_frame().
Unless I did not understand how to solve the issue, please refine.
Thanks,
Cheers,Philippe
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.
@pguibert6WIND, Donald (and I) agree with you that it should not show the default VRF. If I understand Donald correctly, he is saying that your approach to fixing this is not ideal (again I agree). We have facilities in lib/vty.c
for this exact scenario that allow you to enter a "config frame" by calling vty_frame()
. You exit the frame by calling vty_endframe()
. Any calls to vty_out()
are cached in that frame between entry and exit. If you ended up not calling vty_out()
at all, then that entire frame is destroyed and nothing is output (including the very first line that you started the frame with).
Incidentally, I have touched this code to use vty_frame()
in an unrelated but overlapping PR:
#2079
Ergo you can just revert this part of the patch.
e407804
to
dbac81e
Compare
Add the table keyword for all ip route/ip mroute/ipv6 route commands that are available. Also, the main structure is being added a table identifier. Signed-off-by: Philippe Guibert <[email protected]>
In the case where vrf backend is netns, then the list of ns tables may be extended. A single list is kept,but an attribute is added: the ns_id. Signed-off-by: Philippe Guibert <[email protected]>
when configuring a route on default vrf, the show running displays default vrf subnode. Instead, if it is the default vrf that is used, then the vrf subnode is not displayed. Signed-off-by: Philippe Guibert <[email protected]>
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-3341/ This is a comment from an EXPERIMENTAL automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base6 Static Analyzer issues remaining.See details at |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
re->table = zebra_vrf_lookup_by_id(si->vrf_id) | ||
->table_id; | ||
else if (si->table_id) /* case default VRF, table used | ||
*/ |
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.
Please put this comment on its own line above the else, or move the terminating */
onto the same line as /*
.
*/ | ||
re->table = si->table_id; | ||
else /* case default VRF, default table | ||
*/ |
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.
Same here
} | ||
|
||
if (vrf_is_user_cfged(vrf)) { | ||
} else if (vrf_is_user_cfged(vrf)) { |
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.
@pguibert6WIND, Donald (and I) agree with you that it should not show the default VRF. If I understand Donald correctly, he is saying that your approach to fixing this is not ideal (again I agree). We have facilities in lib/vty.c
for this exact scenario that allow you to enter a "config frame" by calling vty_frame()
. You exit the frame by calling vty_endframe()
. Any calls to vty_out()
are cached in that frame between entry and exit. If you ended up not calling vty_out()
at all, then that entire frame is destroyed and nothing is output (including the very first line that you started the frame with).
Incidentally, I have touched this code to use vty_frame()
in an unrelated but overlapping PR:
#2079
Ergo you can just revert this part of the patch.
This permits configuring static routes per table identifier.