Skip to content
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

[Feature Request] Support IPv6 nexthops for IPv4 routes #4707

Open
SkalaNetworks opened this issue Nov 6, 2024 · 9 comments
Open

[Feature Request] Support IPv6 nexthops for IPv4 routes #4707

SkalaNetworks opened this issue Nov 6, 2024 · 9 comments
Labels
feature New network feature

Comments

@SkalaNetworks
Copy link
Contributor

Description

Currently, putting an IPv6 gateway for an IPv4 route yields the follow error:
failed to add route '{0.0.0.0 00000000} via fd00:0:641:1::1 dev net1': gateway, source, and destination ip are not the same IP family

Route annotation:
'[{"dst":"::/0","gw":"fd00:0:641:1::1"},{"dst":"0.0.0.0/0","gw":"fd00:0:641:1::1"}]'

This would be useful for NAT gateways where BGP extended-nexthop is active. This issue is associated to PR #4704 where extended-nexthop is proposed.

Who will benefit from this feature?

DCs with IPv6 only fabrics would benefit from this feature.

Anything else?

No response

@SkalaNetworks SkalaNetworks added the feature New network feature label Nov 6, 2024
@oilbeater
Copy link
Collaborator

oilbeater commented Nov 13, 2024

The cni will set the route in pod netns. I am not sure if this is a valid format for linux route.

@SkalaNetworks
Copy link
Contributor Author

From a Linux standpoint, it is perfectly valid:
ip route add 1.1.1.1 via inet6 fd00::1

This is useful when the underlay is an IPv6 fabric, something more and more common especially in the datacenter.

@bobz965
Copy link
Collaborator

bobz965 commented Nov 15, 2024

maybe it is a new feature. In most case, subnet should use it gw inside its cidr.

in this case , the gw is outside subnet cidr.

@SkalaNetworks
Copy link
Contributor Author

There's no particular reason for the GW to be inside the same subnet, at its heart, this is just L2 forwarding of a packet, and indicating an L3 address is purely done to look up the ARP table and determine who should be the recipient. This is also why the BGP capability for extended-nexthops was introduced and is now used in IPv6-only datacenter fabrics.

My PR for extended-nexthop has been merged in master, this is more of a proposition to further help Kube-OVN operate in IPv6-only envs.

@oilbeater
Copy link
Collaborator

failed to add route '{0.0.0.0 00000000} via fd00:0:641:1::1 dev net1': gateway, source, and destination ip are not the same IP family

@SkalaNetworks this error log is generated by netlink library. If netlink not support this, I think we cannot easily set this route.

Also when I try ip route add 1.1.1.1 via inet6 fd00::1 in ubuntu 22.04.1, it also generate error message RTNETLINK answers: No route to host

@SkalaNetworks
Copy link
Contributor Author

SkalaNetworks commented Nov 18, 2024

You need a route to the default gateway, c.f https://forum.vyos.io/t/ability-to-have-ipv6-nexthops-for-ipv4-static-routes/13601

Note: This is a VyOS post discussing linux ipv6 nexthop capabilities

@oilbeater
Copy link
Collaborator

@SkalaNetworks Thanks for the information. I finally understand what IPv6-only datacenter fabrics is. I think add a netlink route family option can resolve this.

@zhangzujian
Copy link
Member

upstream issue: vishvananda/netlink#908

@oilbeater
Copy link
Collaborator

There is a bug exist in netlink, which wrongly use src family as the dst family to validate gateway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New network feature
Projects
None yet
Development

No branches or pull requests

4 participants