Hi Neale, In icmp6_neighbor_solicitation_or_advertisement function , a comment like this is mentioned: /* If src address unspecified or link local, do not learn neighbor MAC */
How else are we supposed to resolve link local IPv6 addresses? The ip6_discover_neighbor_node is sending a neighbor solicitation request with (global source ip6, link local multicast group address) - and an advertisement is coming back with (link local source ip6, global destination ip6) Thanks, -nagp On Thu, Apr 13, 2017 at 10:49 AM, Nagaprabhanjan Bellaru < nagp.li...@gmail.com> wrote: > Makes sense! Thanks much for the help!! > > Thanks, > -nagp > > On Thu, Apr 13, 2017 at 12:03 AM, Neale Ranns (nranns) <nra...@cisco.com> > wrote: > >> >> >> Hi nagp, >> >> >> >> If the neighbour is not resolved, the adjacency will be ‘incomplete’ and >> yes you should use this state to choose between ip6_rewrite and >> ip6_discover_neighbor (e.g. see bfd_udp_input()*) >> >> >> >> There is a subtle difference between a glean and an incomplete adjacency: >> >> - An incomplete adjacency is represents an explicit next-hop, >> i.e. one for which we know the IP address, but do not yet know the MAC >> address. When packets encounter an incomplete address an ARP/ND packet is >> sent to discover the next-hop address the adjacency represents. When the >> MAC address is discovered, this adjacency object instance transitions to >> the ‘complete’ state. >> >> - A glean adjacency represents the whole subnet, i.e. given >> ‘set int ip addr XXX 10.10.10.10/24’ the glean adjacency is used for >> traffic matching 10.10.10.0/24. If packets encounter a glean adjacency >> then an ARP/ND packet is sent to discover that packet’s destination IP >> address. >> >> >> >> These functions are implemented in two different VLIB nodes (e.g. ip4_arp >> and ipv4_glean respectively). >> >> When you find the adjacency via ‘adj_nbr_add_or_lock’ you will never get >> a glean adj, you’ll only get [in]complete ones. >> >> >> >> Regards, >> >> Neale >> >> >> >> *there are other ways to do this if you have an object you can >> ‘dpo_stack’ and re-stack when the adj changes state. There are various >> examples of features stacking on a fib_entry (e.g. LISP and VXALN), but not >> on an adjacency – but the principle is the same. >> >> >> >> *From: *Nagaprabhanjan Bellaru <nagp.li...@gmail.com> >> *Date: *Wednesday, 12 April 2017 at 18:30 >> >> *To: *"Neale Ranns (nranns)" <nra...@cisco.com> >> *Cc: *vpp-dev <vpp-dev@lists.fd.io> >> *Subject: *Re: [vpp-dev] How to send packets from control plane to a >> link local IPv6 address? >> >> >> >> Thanks! One small question - if the neighbor is not resolved yet, will >> the lookup yield a glean adjacency? If that is the case, depending on the >> type of the result, I should punt the packet to either ip6_rewrite or >> ip6_discover_neighbor? >> >> Thanks, >> >> -nagp >> >> >> >> On Wed, Apr 12, 2017 at 10:40 PM, Neale Ranns (nranns) <nra...@cisco.com> >> wrote: >> >> >> >> Hi nagp, >> >> >> >> I do indeed mean the result of a ip6_fib_table_lookup. The goal of a >> lookup is ultimately to find the adjacency to use (and thus eventually get >> to ip6_rwrite node). Since you know the adjacency’s full description, it is >> more efficient to retrieve it directly from the adjacency data-base and go >> directly to ip6_rewrite. >> >> >> >> As you say, if one where to do a lookup for a link-local address in the >> FIB, then one should use the interface as part of the key, i.e. a /160 >> lookup, or perhaps in a per-interface link-local address only ‘FIB’. But >> VPP has no such function. The adjacency data-base serves this purpose*. >> >> >> >> Regards, >> >> Neale >> >> >> >> *if you are using this in the data-plane though, we should consider >> alternatives. >> >> >> >> *From: *Nagaprabhanjan Bellaru <nagp.li...@gmail.com> >> *Date: *Wednesday, 12 April 2017 at 14:04 >> *To: *"Neale Ranns (nranns)" <nra...@cisco.com> >> *Cc: *vpp-dev <vpp-dev@lists.fd.io> >> *Subject: *Re: [vpp-dev] How to send packets from control plane to a >> link local IPv6 address? >> >> >> >> Thanks Neale! >> >> By the "result of the lookup" do you mean looking up through >> ip6_fib_table_lookup? I don't this lookup taking a interface also (for the >> link local case). Please correct my understanding. >> >> Thanks, >> >> -nagp >> >> >> >> On Wed, Apr 12, 2017 at 4:30 PM, Neale Ranns (nranns) <nra...@cisco.com> >> wrote: >> >> Hi nagp, >> >> >> >> If you know the destination address is link local and you know on which >> interface, then the result of the lookup will result in the adjacency for >> that link-local address on that interface, i.e. the adjacency you would get >> back from; >> >> adj_index_t ai = adj_nbr_add_or_lock(FIB_PROTOCOL_IP6, VNET_LINK_IP6, >> <ll_add>, <interface>); >> >> >> >> now you have the adjacency, the lookup is not required, so you can send >> the packet directly to ip6_rewrite/ip6_discover_neighbor. There is an >> example of this in the BFD code (see bfd_udp_input()). >> >> >> >> Hth, >> >> neale >> >> >> >> *From: *<vpp-dev-boun...@lists.fd.io> on behalf of Nagaprabhanjan >> Bellaru <nagp.li...@gmail.com> >> *Date: *Wednesday, 12 April 2017 at 11:27 >> *To: *vpp-dev <vpp-dev@lists.fd.io> >> *Subject: *[vpp-dev] How to send packets from control plane to a link >> local IPv6 address? >> >> >> >> Hi, >> >> How can I send packets to a link local IPv6 address? I know the interface >> on which the packet has to be sent, but when I enqueue the packet to >> "ip6_lookup" node, how can I encode the interface such that the neighor >> resolution happens on that interface and the packet gets transmitted? >> >> Thanks, >> >> -nagp >> >> >> >> >> >> >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
