[dpdk-users] Question regarding packet availability

[dpdk-users] Question regarding packet availability

[yingzhi]

Hi All,


I'm new to DPDK and would like to ask some quick questions.
We are trying to develop a Load Balance solution that take advantage of ECMP with BGP, so there is a BGP process running on our LB node, and we'd like to use DPDK to improve packet processing performance.
The questions is, if DPDK bind to a interface, can it still sending/receiving BGP packets or I need a separate interface dedicated for BGP? In the later case, can the BGP process still aware of the DPDK bond port's network and announce that network to uplink router?


Any comment/advice is appreciated.


Thanks in advance.

Re: [dpdk-users] Question regarding packet availability

[dave seddon]

G'day,

BGP peers can advertise routes with a next-hop of a 3rd party neighbor.
This is often used at IX peering peering points across a Ethernet switch
with a route-reflector (RR).  The peers all advertise routes to the RR, and
then the RR send the routes to all the other peers with the next hop not of
the RR, but of the 3rd party neighbor.

Using this, you should be able to use a different NIC on your host machine,
or different machine all together, to run Bird/Quagga BGP to advertise
multiple routes with the next hop IP of our DPDK process(es) using a
different NICs.  This way you won't need to (re)implement a BGP solution in
DPDK.

Info about 3rd party neighbors here with pictures, and it's obviously also
covered in detail within the BGP RFCs:
http://blog.ine.com/2010/09/02/understanding-third-party-next-hop/

You should think carefully about the health checking, and could also
consider that your BGP process could adjust the bandwidth to the different
next hop IPs taking advantage of Link Bandwidth Extended communities which
you can advertise with Bird and both Juniper and Cisco support from an ECMP
perspective:
http://bird.network.cz/pipermail/bird-users/2014-December/009456.html

Hope this helps, as your project sounds interesting.

Kind regards,
Dave

On Thu, Jul 28, 2016 at 3:00 AM, yingzhi <kaitoy@qq.com> wrote:

> Hi All,
>
>
> I'm new to DPDK and would like to ask some quick questions.
> We are trying to develop a Load Balance solution that take advantage of
> ECMP with BGP, so there is a BGP process running on our LB node, and we'd
> like to use DPDK to improve packet processing performance.
> The questions is, if DPDK bind to a interface, can it still
> sending/receiving BGP packets or I need a separate interface dedicated for
> BGP? In the later case, can the BGP process still aware of the DPDK bond
> port's network and announce that network to uplink router?
>
>
> Any comment/advice is appreciated.
>
>
> Thanks in advance.




-- 
Regards,
Dave Seddon
+1 415 857 5102

Re: [dpdk-users] Question regarding packet availability

[Александр Киселев]

Hi.

You can use KNI interfaces to redirect the control plane traffic whether
it's a bgp or any other routing protocol traffic to the KNI while
forwarding data plane traffic using dpdk. It will allow your linux routing
daemon to receive route updates without having a dedicated physical
interface. After that you should find a way to redistribute the received
routes back to your dpdk forwarding engine. To do that you can use linux
netlink interface or quagga's FPM interface. The bird also has a API to
export routes, but I am not shure.

четверг, 28 июля 2016 г. пользователь yingzhi написал:

> Hi All,
>
>
> I'm new to DPDK and would like to ask some quick questions.
> We are trying to develop a Load Balance solution that take advantage of
> ECMP with BGP, so there is a BGP process running on our LB node, and we'd
> like to use DPDK to improve packet processing performance.
> The questions is, if DPDK bind to a interface, can it still
> sending/receiving BGP packets or I need a separate interface dedicated for
> BGP? In the later case, can the BGP process still aware of the DPDK bond
> port's network and announce that network to uplink router?
>
>
> Any comment/advice is appreciated.
>
>
> Thanks in advance.



-- 
--
Kiselev Alexander