zebra, topotests: autorise nexthop interface labelled routes #15043
+199
−1
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
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
bb23d3f to
21d4970
Compare
ton31337
requested changes
Dec 20, 2023
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
21d4970 to
2ff0980
Compare
done |
|
ci:rerun |
ton31337
reviewed
Dec 22, 2023
ton31337
reviewed
Dec 22, 2023
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
2ff0980 to
25b733c
Compare
|
ci:rerun |
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
25b733c to
4be1606
Compare
|
Before it was a test, but now it's gone, or is this unintentional? |
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jan 9, 2024
When coming from staticd, some nexthop interface based routes
should be able to add a label. This helps recursive routes to
reuse the label.
> interface eth0
> ip address 192.0.2.1/32
> !
> ip route 192.0.2.2/32 eth0 label 55
> ip route 172.31.0.0/24 192.0.2.2
> ip route 172.31.1.0/24 192.0.2.2
The nexthop interface route is a connected route with no next-hop,
and the destination packets with DA=192.0.2.2/32 be sent with a
broadcast DMAC. This will result in dropping those packets on
the receiving router.
However, the recursive routes will take the real MAC address of the
192.0.2.2 IP and the label 55 to forge outgoing packets going to
the 172.31.0.0 or 172.31.1.0 sub-networks.
Fixes: ("7fcb24bbaa91") zebra: reject routes without nexthops
Link: FRRouting#10058
Signed-off-by: Philippe Guibert <[email protected]>
Link: FRRouting#15043
Signed-off-by: Philippe Guibert <[email protected]>
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
4be1606 to
e5240fc
Compare
re-added it. this was a mistake from my side. |
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
e5240fc to
94fb8f6
Compare
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Mar 5, 2024
When coming from staticd, some nexthop interface based routes
should be able to add a label. This helps recursive routes to
reuse the label.
> interface eth0
> ip address 192.0.2.1/32
> !
> ip route 192.0.2.2/32 eth0 label 55
> ip route 172.31.0.0/24 192.0.2.2
> ip route 172.31.1.0/24 192.0.2.2
The nexthop interface route is a connected route with no next-hop,
and the destination packets with DA=192.0.2.2/32 be sent with a
broadcast DMAC. This will result in dropping those packets on
the receiving router.
However, the recursive routes will take the real MAC address of the
192.0.2.2 IP and the label 55 to forge outgoing packets going to
the 172.31.0.0 or 172.31.1.0 sub-networks.
Fixes: ("7fcb24bbaa91") zebra: reject routes without nexthops
Link: FRRouting#10058
Signed-off-by: Philippe Guibert <[email protected]>
Conflicts:
zebra/zapi_msg.c, minor, MPLS auto mode not present on upstream
Link: FRRouting#15043
Signed-off-by: Philippe Guibert <[email protected]>
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
94fb8f6 to
e396ac2
Compare
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Mar 11, 2024
When coming from staticd, some nexthop interface based routes
should be able to add a label. This helps recursive routes to
reuse the label.
> interface eth0
> ip address 192.0.2.1/32
> !
> ip route 192.0.2.2/32 eth0 label 55
> ip route 172.31.0.0/24 192.0.2.2
> ip route 172.31.1.0/24 192.0.2.2
The nexthop interface route is a connected route with no next-hop,
and the destination packets with DA=192.0.2.2/32 be sent with a
broadcast DMAC. This will result in dropping those packets on
the receiving router.
However, the recursive routes will take the real MAC address of the
192.0.2.2 IP and the label 55 to forge outgoing packets going to
the 172.31.0.0 or 172.31.1.0 sub-networks.
Fixes: ("7fcb24bbaa91") zebra: reject routes without nexthops
Link: FRRouting#10058
Signed-off-by: Philippe Guibert <[email protected]>
Conflicts:
zebra/zapi_msg.c, minor, MPLS auto mode not present on upstream
Link: FRRouting#15043
Signed-off-by: Philippe Guibert <[email protected]>
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
e396ac2 to
04d3ec8
Compare
When coming from staticd, some nexthop interface based routes
should be able to add a label. Following configuration can
help:
interface eth0
ip address 10.125.0.1/32
!
ip route 10.125.0.0/24 eth0 label 55
Fixes: ("7fcb24bbaa91") zebra: reject routes without nexthops
Signed-off-by: Philippe Guibert <[email protected]>
When coming from staticd, some nexthop interface based routes
should be able to add a label. This helps recursive routes to
reuse the label.
> interface eth0
> ip address 192.0.2.1/32
> !
> ip route 192.0.2.2/32 eth0 label 55
> ip route 172.31.0.0/24 192.0.2.2
> ip route 172.31.1.0/24 192.0.2.2
The nexthop interface route is a connected route with no next-hop,
and the destination packets with DA=192.0.2.2/32 be sent with a
broadcast DMAC. This will result in dropping those packets on
the receiving router.
However, the recursive routes will take the real MAC address of the
192.0.2.2 IP and the label 55 to forge outgoing packets going to
the 172.31.0.0 or 172.31.1.0 sub-networks.
Fixes: ("7fcb24bbaa91") zebra: reject routes without nexthops
Link: FRRouting#10058
Signed-off-by: Philippe Guibert <[email protected]>
Conflicts:
zebra/zapi_msg.c, minor, MPLS auto mode not present on upstream
Link: FRRouting#15043
Signed-off-by: Philippe Guibert <[email protected]>
pguibert6WIND
force-pushed
the
autorise_label_nexthop_iface_2
branch
from
04d3ec8 to
fe3a55f
Compare
|
This PR is stale because it has been open 180 days with no activity. Comment or remove the |
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.
When coming from staticd, some nexthop interface based routes should be able to add a label. This helps recursive routes to reuse the label.
The nexthop interface route is a connected route with no next-hop, and the destination packets with DA=192.0.2.2/32 be sent with a broadcast DMAC. This will result in dropping those packets on the receiving router.
However, the recursive routes will take the real MAC address of the 192.0.2.2 IP and the label 55 to forge outgoing packets going to the 172.31.0.0 or 172.31.1.0 sub-networks.
Fixes: ("7fcb24bbaa91") zebra: reject routes without nexthops
Link: #10058