zebra: Prevent vrf table 254 being used by non-default vrf #18702
Conversation
|
@Mergifyio backport stable/10.3 stable/10.2 stable/10.1 stable/10.0 |
✅ Backports have been created
|
35a7763 to
a51a3c1
Compare
If an operator configures a vrf that happens to overlap with the default table, don't allow it just like we don't allow two vrf's to have the same tableid. Fixes: FRRouting#18699 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
a51a3c1 to
3c009ff
Compare
|
@donaldsharp would it be a better approach to just return "vrf not found" if more that one VRF refers to the same table ID? Kernel does not prevent creation of multiple VRFs with the same table ID. (For our use case, we want a way to route some traffic using only main table (254), but not e.g. "local" table (255), and we use a VRF for that. Of course it would be still possible to achieve by other means, VRF is just the most convenient in our case.) |
|
I'm not terribly interested in trying to figure out how to get this right inside all the code paths. Nor am I interested in figuring out what it means. So as of this moment I would prefer that this be the behavior. |
zebra: Prevent vrf table 254 being used by non-default vrf (backport #18702)
zebra: Prevent vrf table 254 being used by non-default vrf (backport #18702)
zebra: Prevent vrf table 254 being used by non-default vrf (backport #18702)
zebra: Prevent vrf table 254 being used by non-default vrf (backport #18702)
|
Fair enough. But in that case, should zebra at least refuse to work consistently, both when it starts up, and when it is dynamically reconfigured? As far as I can see, it runs after being restarted. Is that correct behaviour? |
If an operator configures a vrf that happens to overlap with the default table, don't allow it just like we don't allow two vrf's to have the same tableid.
Fixes: #18699