Yes, I think so.
I'll give it a try and modify the span node.
Christophe
PS: I have modified the l2patch feature to also support the connection on the
tx side, if anyone is interested, I can submit it.
Here is the journey of a packet sent with scapy on the vlan 442, getting
flooded on the 1st bd, sent to the other bd, and
Sent back with the appropriate vlan (443)
00:19:55:173391: dpdk-input
GigabitEthernet8/0/0 rx queue 0
buffer 0x5727: current data 0, length 60, free-list 0, totlen-nifb 0, trace
0x60
PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0xfd721fc0
packet_type 0x0
ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 442
request, type ethernet/IP4, address size 6/4
78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0
00:19:55:173394: ethernet-input
ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 442
00:19:55:173398: l2-input
l2-input: sw_if_index 2 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
00:19:55:173400: l2-input-vtr
l2-input-vtr: sw_if_index 2 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00 data
08 06 00 01 08 00 06 04 00 01 78 24
00:19:55:173401: l2-flood
l2-flood: sw_if_index 2 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00 bd_index 1
00:19:55:173403: l2-output
l2-output: sw_if_index 4 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
00:19:55:173404: l2-patch
L2_PATCH: rx 2 tx 5
00:19:55:173405: loop1-output
loop1
ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40
request, type ethernet/IP4, address size 6/4
78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0
00:19:55:173410: ethernet-input
ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40
00:19:55:173411: l2-input
l2-input: sw_if_index 5 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
00:19:55:173413: l2-flood
l2-flood: sw_if_index 5 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00 bd_index 2
00:19:55:173414: l2-output
l2-output: sw_if_index 3 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
00:19:55:173415: GigabitEthernet8/0/0-output
GigabitEthernet8/0/0.443
ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 443
request, type ethernet/IP4, address size 6/4
78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0
00:19:55:173416: GigabitEthernet8/0/0-tx
GigabitEthernet8/0/0 tx queue 1
buffer 0x5727: current data 0, length 60, free-list 0, totlen-nifb 0, trace
0x60
ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 443
request, type ethernet/IP4, address size 6/4
78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0
> -----Original Message-----
> From: Damjan Marion [mailto:dmarion.li...@gmail.com]
> Sent: vendredi 25 novembre 2016 14:12
> To: Christophe FONTAINE <christophe.fonta...@qosmos.com>
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] How to transfer packets between 2 bridge domains ?
>
>
> Is this something which can be solved simply by telling to span node to have
> multiple destination interfaces?
>
> > On 24 Nov 2016, at 20:22, Christophe FONTAINE
> <christophe.fonta...@qosmos.com> wrote:
> >
> > Hi,
> >
> > I’m working on Tap as a Service feature for OpenStack [1], and I hope I just
> don’t know how to configure VPP to transfer packets between 2 bridge
> domains.
> > The global setup follows the blueprint [2], but basically, here is what I
> > have
> :
> >
> > VhostUser0/0/1
> > |
> > span
> > |
> > loop0 loop1
> > | |
> > [BD-A] === [BD-B]--VhostUser0/0/2
> > |
> > Gigabit/0/0/1.3901
> >
> > Booth bridge domains are configured to flood the traffic.
> > This 2 bridge domain setup is required to be able to have the traffic from1
> spanned interface (named tap-flow) copied to multiple destination (named
> tap-service), as well as multiple tap-flows to a single tap-service.
> >
> > The problem I have is that I can't use 2 loopback interfaces with a cross
> connect because the xconnect feature:
> > - is tied to the device-input feature mask: when incoming packets are
> > flooded by the bridge, the packets are sent to interface-out, and to
> > not go thru the rx path
> > - as it is tied to the device-input feature mask, we can't have xconnect AND
> bridge features enabled at the same time.
> > Same problem with the l2patch.
> >
> > I tried different things, such as using the input and output classifiers to
> redirect packets to the appropriate interface-out (eg: loop2-tx )nodes, using
> the same vhost user socket as client and server to loopback the traffic from 2
> bridge domains, using 2 sub-interfaces from a loopback interface to transfer
> the packets from 1 bd to the other, but I think I'm missing something
> important !
> > The only way I got this working was by using an external veth pair, each end
> connected to 1 bd... not a real solution for me.
> >
> > I thought I could write an 'xconnect-tx node' to be able to transfer the
> packets (this node would be like the output classifier ), but I wanted first
> to
> know whether this is the only solution.
> >
> > Many thanks !
> > Christophe
> >
> > [1] https://github.com/christophefontaine/tap-as-a-service
> > [2]
> > https://wiki.openstack.org/wiki/Blueprint-networking-vpp-taas#Possible
> > _implementations This message and any attachments (the "message") are
> > confidential, intended solely for the addressees. If you are not the
> intended recipient, please notify the sender immediately by e-mail and
> delete this message from your system. In this case, you are not authorized to
> use, copy this message and/or disclose the content to any other person. E-
> mails are susceptible to alteration. Neither Qosmos nor any of its
> subsidiaries
> or affiliates shall be liable for the message if altered, changed or
> falsified.
> >
> > Ce message et toutes ses pièces jointes (ci-après le "message")sont
> confidentiels et établis à l'intention exclusive de ses destinataires. Si vous
> avez reçu ce message par erreur, merci d’en informer immédiatement son
> émetteur par courrier électronique et d’effacer ce message de votre
> système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce
> message et/ou en divulguer le contenu à un tiers. Tout message
> électronique est susceptible d'altération. Qosmos et ses filiales déclinent
> toute responsabilité au titre de ce message s'il a été altéré, déformé ou
> falsifié.
> > _______________________________________________
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
This message and any attachments (the "message") are confidential, intended
solely for the addressees. If you are not the intended recipient, please notify
the sender immediately by e-mail and delete this message from your system. In
this case, you are not authorized to use, copy this message and/or disclose the
content to any other person. E-mails are susceptible to alteration. Neither
Qosmos nor any of its subsidiaries or affiliates shall be liable for the
message if altered, changed or falsified.
Ce message et toutes ses pièces jointes (ci-après le "message")sont
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous
avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur
par courrier électronique et d’effacer ce message de votre système. Dans cette
hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en
divulguer le contenu à un tiers. Tout message électronique est susceptible
d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de
ce message s'il a été altéré, déformé ou falsifié.
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
