Hello All,
Good evening.
I have a use case with IPIP tunnel. Can someone suggest a solution if already
done ? or share thoughts ?
IPIP tunnel encapsulation Requirement:
The ip-route that points to ipip-tunnel should be sent on a neighbor-ip that is
different than the destination-ip of the ipip-tunnel.
In other words, the ipip-tunnel should only be responsible for adding outer
header (i.e. encapsulation) and should not decide the forwarding.
For example:
ip route add 70.70.70.0/24 via 55.55.55.55 ipip0
The neighbor-ip 55.55.55.55 is another route that is resolved.
55.55.55.55/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:73 buckets:1 uRPF:84 to:[0:0]
drop:[0:0]]
[0] [@5]: ipv4 via 12.1.1.2 TenGigabitEthernet3/0/1.60: l3-mtu:1400
l2-mtu:1508 next:6 000081bee3f8322a643982f4810000030800
The ipip-tunnel configuration is like below.
[0] instance 0 src 22.22.22.22 dst 33.33.33.33 table-ID 0 sw-if-idx 77 flags
[none] dscp CS0
The tunnel destination-ip is resolved like below.
33.33.33.33/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:78 buckets:1 uRPF:88 to:[0:0]
drop:[0:0]]
[0] [@5]: ipv4 via 11.1.1.2 GigabitEthernet5/0/0.59: l3-mtu:1400
l2-mtu:1504 next:5 000081bee3f6322a643982f4810000020800
As per my requirement, the route should be sent via via 12.1.1.2
TenGigabitEthernet3/0/1.60.
But the route is getting stacked on 11.1.1.2 GigabitEthernet5/0/0.59.
In the VPP code, I see that the ipip-tunnel header is updated by the
adj_nbr_midchain_update and immediately after the midchain_delegate_stack
happens with the destination-ip of the tunnel.
Since the ipip-tunnel is P2P interface (highlighted code), it looks like the
nexthop_addr is passed as ZERO.
static fib_path_t*
fib_path_attached_next_hop_get_adj (fib_path_t *path,
vnet_link_t link,
dpo_id_t *dpo)
{
fib_node_index_t fib_path_index;
fib_protocol_t nh_proto;
adj_index_t ai;
fib_path_index = fib_path_get_index(path);
nh_proto = dpo_proto_to_fib(path->fp_nh_proto);
if (vnet_sw_interface_is_p2p(vnet_get_main(),
path->attached_next_hop.fp_interface))
{
/*
* if the interface is p2p then the adj for the specific
* neighbour on that link will never exist. on p2p links
* the subnet address (the attached route) links to the
* auto-adj (see below), we want that adj here too.
*/
ai = adj_nbr_add_or_lock(nh_proto, link, &zero_addr,
path->attached_next_hop.fp_interface);
}
else
{
ai = adj_nbr_add_or_lock(nh_proto, link,
&path->attached_next_hop.fp_nh,
path->attached_next_hop.fp_interface);
}
dpo_set(dpo, DPO_ADJACENCY, vnet_link_to_dpo_proto(link), ai);
adj_unlock(ai);
return (fib_path_get(fib_path_index));
}
Can such a adj_nbr exist ? or should it be a new type ?
Or can I simply make the IPIP-hw-interface-type as NBMA instead of P2P and make
some changes in the ipip_tunnel_stack to get nh_addr from ai and do the
midchain_delegate_stack on this address ?
Any inputs are highly appreciated.
Thanks,
Leela sankar
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#26499): https://lists.fd.io/g/vpp-dev/message/26499
Mute This Topic: https://lists.fd.io/mt/116211264/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
