Hi Neale, can you please point me a code example of how to access the adjacency-DB in order to get the adjacency index to use for the ip4-rewrite node?
Thanks, Alessio On Wed, Jun 21, 2017 at 12:53 PM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > Hi Dharmaray, > > The short answer is that ip4-lookup performs the lookup in a FIB table of > the packet’s destination address, the result of which is an adjacency. The > ip4-rewrite node applies the ‘L2’ encap of an adjacency and transmits the > packet on the output port*. So typically packets will go first to > ip4-lookup, get the adjacency, then proceed to ip4-rewrite. > > When choosing between which of the two nodes to send your packet to, you > should consider which of the pre-conditions for the required data you meet. > In order to perform the IP lookup, the node needs to know which FIB table > to use. In order to perform the rewrite, the node needs to know which > adjacency to use. > So if you want to send your packet to the ip4-rewrite node, then you must > have already chosen which adjacency to use. For single-hop BFD this is a > simple matter of getting the adjacency from the adjacency-DB based on the > peer and interface – you can think of this as caching the result of the > lookup. The advantage of this is that we bypass the ip4-lookup node and so > don’t pay its performance cost. > > If you know the next-hop to send to, but not the interface (and so can’t > use the adjacency-DB directly) then you can register with the FIB to track > that next-hop and be informed of the changing adjacency to use. > > Hth, > neale > > *typically. The exception being tunnels. > > -----Original Message----- > From: <vpp-dev-boun...@lists.fd.io> on behalf of Dharmaray Kundargi < > dharmaray.kunda...@mavenir.com> > Date: Wednesday, 21 June 2017 at 10:48 > To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" < > ksek...@cisco.com>, Alessio Silvestro <ale.silver...@gmail.com> > Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] VPP: Answer UDP Packets > > BFD UDP code is interesting example. > > I was looking at bfd_udp_input rather and one question in relation to > this. > Though both ' bfd_udp_input ()' and ' bfd_send_periodic()' form the IP > and UDP headers using ' bfd_add_transport_layer', they pass the packet to > different next nodes. > bfd_udp_input uses "ip4-lookup" as the next node whereas ' > bfd_send_periodic()' uses "ip4-rewrite". > > So what's the difference between these two nodes? (ip4-rewrite vs ip4- > lookup) and when to use what ? > > Regards > Dharmaray > > > > > -----Original Message----- > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] > On Behalf Of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) > Sent: Monday, June 19, 2017 12:09 PM > To: Alessio Silvestro <ale.silver...@gmail.com> > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] VPP: Answer UDP Packets > > Couple of potential issues which I see: > > 1.) if this buffer is generated by vpp, it should be flagged as such > (b->flags |= VNET_BUFFER_LOCALLY_ORIGINATED;) > > 2.) I don't see it passed to another node - you need to create a frame > and associate the buffer with it, then pass the frame to the next node, > which would be either ip4-arp or ip4-rewrite for ipv4 case depending on > whether the arp resolution has taken place or not... > > take a look at functions > > bfd_udp_init() - where the next nodes are resolved > bfd_transport_udp4() - where the next node is decided and frame created > > You can take a look at show error and show trace to see what happens > to the packet.. > > HTH, > Klement > > > Quoting Alessio Silvestro (2017-06-16 17:20:30) > > Dear Klement, > > > > thanks for the hint. I had a look at the code bfd_main.c and in > particular > > at the function bfd_send_periodic(). > > > > I wrote the function send_udp_packet() -- see below -- in order > to send > > out UDP packets. > > > > The function is executed (I can see from the VPP terminal) and no > > exception is raised, however I do not see any packet out. > > > > 1 -- is the function correct or I am missing something? > > > > 2 -- if it is not correct, how I can see where the problem is? > > > > Thanks, > > > > Alessio > > > > static void send_udp_packet(vlib_main_t * vm, vlib_node_runtime_t > * rt){ > > u32 bi; > > vlib_buffer_alloc (vm, &bi, 1) > > vlib_buffer_t *b = vlib_get_buffer (vm, bi); > > ASSERT (b->current_data == 0); > > memset (vnet_buffer (b), 0, sizeof (*vnet_buffer (b))); > > VLIB_BUFFER_TRACE_TRAJECTORY_INIT (b); > > add_udp4_transport (vm,b); > > } > > > > int add_udp4_transport (vlib_main_t * vm, vlib_buffer_t * b) > > { > > vnet_buffer (b)->ip.adj_index[VLIB_RX] = ~0; > > vnet_buffer (b)->ip.adj_index[VLIB_TX]= ~0; > > vnet_buffer (b)->sw_if_index[VLIB_RX] = 0; > > vnet_buffer (b)->sw_if_index[VLIB_TX] = ~0; > > u8 *data; > > udp_header_t *udp; > > ip4_header_t *ip; > > data = vlib_buffer_get_current (b); > > udp = (udp_header_t *) (data - sizeof (udp_header_t)); > > ip = (ip4_header_t *) ((u8 *) udp - sizeof (ip4_header_t)); > > // Build packet header > > u32 src_address = 167772161; //[1]10.0.0.1 u32 version > > u32 dst_address = 167772162; // 10.0.0.2 u32 version > > ip->src_address.as_u32 = src_address; > > ip->dst_address.as_u32 = dst_address; > > ip->ip_version_and_header_length = 0x45; > > ip->ttl = 254; > > ip->protocol = IP_PROTOCOL_UDP; //0x45 == IP_PROTOCOL_UDP > > ip->length = clib_host_to_net_u16 (b->current_length + sizeof > (*udp)); > > ip->checksum = ip4_header_checksum (ip); > > udp->src_port = DNS_SERVER_PORT; > > udp->dst_port = DNS_DST_PORT; > > udp->length = clib_host_to_net_u16 (b->current_length); > > udp->checksum = 0; > > b->current_length = sizeof (*ip) + sizeof (*udp); > > return 1; > > } > > > > On Wed, Jun 14, 2017 at 6:56 PM, Klement Sekera -X (ksekera - > PANTHEON > > TECHNOLOGIES at Cisco) <[2]ksek...@cisco.com> wrote: > > > > Hi Alessio, > > > > you can take a look at BFD code which > > > > a.) creates and sends its own UDP packets - bfd_main.c - > > bfd_send_periodic() creates, encapsulates (UDP) and sends a > packet out > > b.) loops back packets received - bfd_udp.c - > > bfd_udp_echo_input() > > > > I'm not sure what's your use case, whether you are trying to > reuse > > existing buffer, but one of these should fit it. > > > > Regards, > > Klement > > > > Quoting Alessio Silvestro (2017-06-14 17:22:14) > > > Dear all, > > > I implemented a new VPP node that receives UDP traffic > using the > > following > > > function: > > > > > > udp_register_dst_port (vm, PORT, my_node.index , 1 /* > is_ip4 */); > > > > > > I am able to parse the packet and I would like to be able > to send > > back an > > > UDP packet. > > > > > > Looking at the source code, the only function that seems > fit my > > scope is > > > the following (in ~/vpp/src/vnet/udp/udp.h) > > > > > > ip_udp_encap_one (vlib_main_t * vm, vlib_buffer_t * b0, u8 > * ec0, > > word > > > ec_len, > > > > > > u8 is_ip4) > > > > > > Is that correct or there is another function for this > purpose? > > > > > > Thanks in advance for any help. > > > > > > Best regards, > > > > > > Alessio > > > > References > > > > Visible links > > 1. http://10.0.0.1/ > > 2. mailto:ksek...@cisco.com > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev > ________________________________ > Please Note: My email address is changing. Starting May 1st 2017 my > email will solely be my Mavenir email firstname.lastn...@mavenir.com. All > other prior email accounts will become inactive. To ensure continuity, > please send all emails to my Mavenir email ID which is currently active and > available for use. > > > This e-mail message may contain confidential or proprietary > information of Mavenir Systems, Inc. or its affiliates and is intended > solely for the use of the intended recipient(s). If you are not the > intended recipient of this message, you are hereby notified that any > review, use or distribution of this information is absolutely prohibited > and we request that you delete all copies in your control and contact us by > e-mailing to secur...@mavenir.com. Thank You. This message contains the > views of its author and may not necessarily reflect the views of Mavenir > Systems, Inc. or its affiliates, who employ systems to monitor email > messages, but make no representation that such messages are authorized, > secure, uncompromised, or free from computer viruses, malware, or other > defects. > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev > > >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
