Hi,
Someone pointed out to me that if an IPv6 address is configured on an IPsec
or GRE tunnel interface, the address is visible if you look at 'vppctl show
int addr' but the address is not included in the data we retrieve from the
API. This does not prevent IPv6 packets from being sent, it just affects
how our control plane can determine whether an IPv6 address is already
configured on an interface in order to decide whether to attempt to add or
delete it.
It seems that if I send an IP_DUMP message to the API with is_ipv6 set to
1, the tunnel interfaces will be filtered out by this condition in
vl_api_ip_dump_t_handler():
if (mp->is_ipv6 && !ip6_interface_enabled (vm, si->sw_if_index))
{
continue;
}
ip6_interface_enabled() returns false for the tunnel interfaces.
If I send IP_ADDRESS_DUMP for the tunnel interface with is_ipv6 set to 1, I
do get back an address for the IPv6 address I set on the interface. So it's
possible to get those addresses, but my code is skipping the
IP_ADDRESS_DUMP for IPv6 addresses on the interface because no IP_DETAILS
was received for IPv6 on that interface.
There's no written explanation of IP_DUMP and IP_ADDRESS_DUMP that I recall
seeing, but I inferred that IP_DUMP would indicate whether you should
bother sending an IP_ADDRESS_DUMP for a particular combination of
{sw_if_index, is_ipv6}. Vpp_api_test seems to make the same inference,
which makes sense since I probably copied the behavior of vpp_api_test
initially when I was figuring out how things are supposed to work. Here's
what vat does with the above situation:
vat# ip_dump ipv6
vat# ip_address_dump ipv6 ipsec0
ip address details arrived but not storedip_dump should be called firstvat#
(Note: vat's error output is missing some "\n"s).
vppctl says:
[root@dev-mgsmith-vm-1 ~]# vppctl show int addr ipsec0
ipsec0 (up):
L3 172.19.0.1/30
L3 abcd:ef01::1/64
For the short term, I can easily deal with this in my client code and just
dump IP addresses for a particular {sw_if_index, is_ipv6} whether or not I
received an IP_DETAILS for that interface/af. I'm trying to determine for
the longer term whether vl_api_ip_dump_t_handler() or
ip6_interface_enabled() or something else should be modified. Or if this is
just the expected behavior.
Some possibilities:
1. Change vl_api_ip_dump_t_handler(). Only skip an interface if IPv6 is
not enabled and there are no IPv6 addresses configured on the interface.
2. Change ip6_interface_enabled(). It currently seems to return false if
there is no RA configuration for the interface. This could be expanded so
that it returns false if there is no RA configuration and there are no IPv6
addresses configured on the interface.
3. Change enable_ip6_interface() so that some RA configuration gets set
up for tunnel interfaces as it does with ethernet interfaces. I have no
idea whether this is actually feasible.
4. Don't do anything.
5. Some other, much better, idea that I am not mentioning.
If I get feedback on what is the preferred course of action, I can submit a
patch.
-Matt
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13581): https://lists.fd.io/g/vpp-dev/message/13581
Mute This Topic: https://lists.fd.io/mt/32599641/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
