Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

[Prabhjot Singh Sethi]

Thanks Neale for your time. as a followup i will try following.

- setting MAC address on Physical interface 
- following up with expected configuration on firewall to rule out
strict requirements on source MAC.

Regards,
Prabhjot

- Original Message -
From:
 "Neale Ranns (nranns)" <nra...@cisco.com>

To:
"Prabhjot Singh Sethi" <prabh...@techtrueup.com>
Cc:
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Omer Majeed"
<omer.maj...@rwth-aachen.de>
Sent:
Mon, 4 Dec 2017 12:14:54 +
Subject:
Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

  

Hi Prabhjot,

  

If there is only one link between VPP A and B, regardless of the
number of .1q sub-interfaces, the forward and reverse direction
packets *SHOULD* have the same MAC addresses.

  

You mention ECMP. Is the reverse direction traffic arriving on the
same interface from which it was sent? 

Perhaps you could show a packet trace for the forward and reverse
direction.

  

Regards,

neale

      

  

    

FROM:  Prabhjot Singh Sethi <prabh...@techtrueup.com>
DATE: Monday, 4 December 2017 at 12:53
TO: "Neale Ranns (nranns)" <nra...@cisco.com>,
"prabh...@techtrueup.com" <prabh...@techtrueup.com>
CC: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Omer Majeed
<omer.maj...@rwth-aachen.de>
SUBJECT: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

  

Hi Neale,

 we have the traffic working however the packets looks like 

source 1.1.1.3 (02:00:00:00:00:01) dest 2.2.2.3 (02:00:00:00:00:02)
 however for reverse traffic
 source 2.2.2.3 (02:fe:c9:7a:70:00) dest 1.1.1.3 (02:00:00:00:00:01)

  

use of BVI for this purpose is ruled out as this use case also need
to handle ECMP route with multiple VLAN interfaces

  

Packet  Egressed by VPP needs to be going though some third party
firewall VM eventually, so at this point we are unable to rule out
 strict requirement on source MAC.

 so essentially we were looking at option to set MAC on VLAN
interfaces while correlating it to linux counterpart.

  

so my expectation is there should be a way to have uniformity in
source and dest MAC for forward and reverse traffic

 Regards,
 Prabhjot

 - Original Message -

FROM:

"Neale Ranns (nranns)" <nra...@cisco.com>

   

TO:

"prabh...@techtrueup.com" <prabh...@techtrueup.com>

CC:

"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Omer Majeed"
<omer.maj...@rwth-aachen.de>

SENT:

Sat, 2 Dec 2017 08:00:06 +

SUBJECT:

Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

 Hi Prabhjot,

 Your explanation of what you want I think I understand; it’s the
ability to set the src,dst MAC address of a packet as it egresses of
VLAN interface. Where in this case a vlan interface is a 802.1Q
interface and not a BVI*.
 But I don’t understand why you want this. You say “we are not
looking for any additional datapath lookup based on MAC”, in other
words, the RX side does not care what the src,dst MAC addresses are,
so why is it important what the TX side sets? Is it for the benefit of
intervening switches? If so I still don’t understand why  ☹

 What is the issue you are trying to address by setting different
src,dst MAC addresses? Perhaps there are existing means to achieve
this already.

 Regards,
 neale

 *In some vendor’s documentation ‘VLAN’ interfaces, also known
as BVI, SVI or IRB (depending on your preferred vendor, platform or
decade) is what VPP terms an BVI. This is an L3 port attached to a
bridge-domain.

 -Original Message-
 From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
 Date: Friday, 1 December 2017 at 18:37
 To: "Neale Ranns (nranns)" <nra...@cisco.com>
 Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Omer Majeed
<omer.maj...@rwth-aachen.de>
 Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

 hi Neale,
 we are not looking for any additional datapath lookup based on MAC
here.
 this is related to one of the feature that we are trying to translate

 to VPP. where we need to handle and generate traffic with configure 
 destination and source MAC. we have tried multiple options and were 
 able to handle incoming traffic, but we were having issues sending 
 traffic with specific source MAC particularly with ECMP routes.

 so i only see two ways either we support configurable MAC address on 
 vlan interface
 or have some ability to configure which source MAC to use in the
route 
 configuration

 please let me know if you want to understand the feature in detail.
we 
 can setup a short call for th

Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

[Prabhjot Singh Sethi]

Hi Neale,

we have the traffic working however the packets looks like 

source 1.1.1.3 (02:00:00:00:00:01) dest 2.2.2.3 (02:00:00:00:00:02)
however for reverse traffic
source 2.2.2.3 (02:fe:c9:7a:70:00) dest 1.1.1.3 (02:00:00:00:00:01)

use of BVI for this purpose is ruled out as this use case also need to
handle ECMP route with multiple VLAN interfaces

Packet  Egressed by VPP needs to be going though some third party
firewall VM eventually, so at this point we are unable to rule out
strict requirement on source MAC.

so essentially we were looking at option to set MAC on VLAN interfaces
while correlating it to linux counterpart.

so my expectation is there should be a way to have uniformity in
source and dest MAC for forward and reverse traffic

Regards,
Prabhjot

- Original Message -
From: "Neale Ranns (nranns)" 
To:"prabh...@techtrueup.com" 
Cc:"vpp-dev@lists.fd.io" , "Omer Majeed"

Sent:Sat, 2 Dec 2017 08:00:06 +
Subject:Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

 Hi Prabhjot,

 Your explanation of what you want I think I understand; it’s the
ability to set the src,dst MAC address of a packet as it egresses of
VLAN interface. Where in this case a vlan interface is a 802.1Q
interface and not a BVI*.
 But I don’t understand why you want this. You say “we are not
looking for any additional datapath lookup based on MAC”, in other
words, the RX side does not care what the src,dst MAC addresses are,
so why is it important what the TX side sets? Is it for the benefit of
intervening switches? If so I still don’t understand why ☹

 What is the issue you are trying to address by setting different
src,dst MAC addresses? Perhaps there are existing means to achieve
this already.

 Regards,
 neale

 *In some vendor’s documentation ‘VLAN’ interfaces, also known
as BVI, SVI or IRB (depending on your preferred vendor, platform or
decade) is what VPP terms an BVI. This is an L3 port attached to a
bridge-domain.

 -Original Message-
 From: "prabh...@techtrueup.com" 
 Date: Friday, 1 December 2017 at 18:37
 To: "Neale Ranns (nranns)" 
 Cc: "vpp-dev@lists.fd.io" , Omer Majeed

 Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

 hi Neale,
 we are not looking for any additional datapath lookup based on MAC
here.
 this is related to one of the feature that we are trying to translate

 to VPP. where we need to handle and generate traffic with configure 
 destination and source MAC. we have tried multiple options and were 
 able to handle incoming traffic, but we were having issues sending 
 traffic with specific source MAC particularly with ECMP routes.

 so i only see two ways either we support configurable MAC address on 
 vlan interface
 or have some ability to configure which source MAC to use in the
route 
 configuration

 please let me know if you want to understand the feature in detail.
we 
 can setup a short call for the same.

 Regards,
 Prabhjot

 Quoting "Neale Ranns (nranns)" :

 > Hi Prabhjot,
 >
 > I would say it is possible, but one would need to place the NIC in 
 > promiscuous mode for an L3 interface, do maybe do MAC to interface 
 > matching in the data-plane which would cost many cycles. Or an rx 
 > would you still want to match to input interface based only on the 
 > VLAN Tag.
 >
 > I confess I don’t understand why you want such a feature, when
the 
 > VLAN tag identifies the sub-interface. Perhaps you could help me 
 > understand.
 >
 > Thanks,
 > neale
 >
 > -Original Message-
 > From: "prabh...@techtrueup.com" 
 > Date: Friday, 1 December 2017 at 13:30
 > To: Omer Majeed 
 > Cc: "vpp-dev@lists.fd.io" , "Neale Ranns 
 > (nranns)" 
 > Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan
interface
 >
 > hi Neale,
 > we are expecting to be able to handle different MAC addresses for
 > VLAN interfaces. This feature seems to be not available in VPP as
of
 > now.
 >
 > we also tried looking for possible work around, which were dead
ends
 > as of now. Please let us know if we agree to this as something that
 > can be done for VPP, we can work on this and contribute if useful.
 >
 > please share your inputs
 >
 > Regards,
 > Prabhjot
 >
 > Quoting Omer Majeed :
 >
 > > Hi Neale,
 > >
 > > Thanks for the reply.
 > > A physical interface could have multiple Vlan interfaces and I 
 > want traffic
 > > originating from Vlan interface to have user defined Mac address
rather
 > > than parent's Mac address.
 > >
 > > In Linux we have this privilege to associate Mac addresses to
Vlan
 > > interfaces using ifconfig.
 > > In Linux, we use vconfig to create Vlan interface and then we
could
 > > leverage ifconfig to configure our 

Re: [vpp-dev] vhost-user stable implementation?: VPP native or DPDK

[Prabhjot Singh Sethi]

sure, thanks i will give it a try
Regards,
Prabhjot

- Original Message -
From:
 "Steven Luong (sluong)" <slu...@cisco.com>

To:
"Prabhjot Singh Sethi" <prabh...@techtrueup.com>, "Saxena Nitin"
<nitin.sax...@cavium.com>, "Guo Ruijing" <ruijing@intel.com>,
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Cc:

Sent:
Tue, 17 Oct 2017 15:10:27 +
Subject:
Re: [vpp-dev] vhost-user stable implementation?: VPP native or DPDK

Prabhjot,

  

To use the dpdk vhost-user, you have to specify each virtual
interface in the startup.conf file, something like this.

  

dpdk {

  no-pci

  file-prefix virtio_user_

  vdev virtio_user0,path=/tmp/sock0,mac=52:54:00:00:04:01

}

  

You would see VirtioUser instead of VirtualEthernet in the show
interface output. VirtualEthernet is displayed if you are using vpp
native vhost-user.

DBGvpp# sh int

sh int

  Name  
Idx   State  Counter 
Count 

VirtioUser0/0/0   1
up
   

local0   
0    down  

DBGvpp#

  

The problem with using dpdk vhost-user is static binding. Every
virtual interface has to be specified in startup.conf prior to
bringing up VPP. If you add another interface in the startup.conf
file, you have to restart VPP.

If you do want to try it out for fun, I remember I need to allocate
1G hugepages instead of 2M hugepages in order to get dpdk vhost-user
or dpdk virtio driver up. I don’t remember the former or the latter
really requires 1G hugepages. It took me a while to figure that part
out.

  

Steven

   

FROM: Prabhjot Singh Sethi <prabh...@techtrueup.com>
DATE: Tuesday, October 17, 2017 at 3:50 AM
TO: Saxena Nitin <nitin.sax...@cavium.com>, "Steven Luong (sluong)"
<slu...@cisco.com>, Guo Ruijing <ruijing@intel.com>,
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
SUBJECT: Re: [vpp-dev] vhost-user stable implementation?: VPP native
or DPDK

  

Hi Steven,

we are also looking at using dpdk based virtualethernet interface, so
looking back at this thread i was wondering what is the problem with
dpdk based solution.

  

1. you mentioned dpdk based interface can be created via vdev in dpdk
clause of startup file, can you share some example there. only thing i
have seen as an example so far is associating a bond interface with
physical slave interfaces, is it possible to create one for VM ?

2. can you please share a link to the patch submitted for dpdk
virtio-user

 Regards,
 Prabhjot 

FROM: Steven Luong (sluong) <slu...@cisco.com>
SENT: Monday, September 11, 2017 7:46 PM
TO: Guo, Ruijing; Saxena, Nitin; vpp-dev@lists.fd.io
SUBJECT: Re: [vpp-dev] vhost-user stable implementation?: VPP native
or DPDK

 

If you create the VIrtualEthernet interface via the CLI or binary
API, it always uses VPP native. If you create the virtual interface
via vdev in the dpdk clause in the startup file, it uses dpdk’s
vhost-user.

 

The problem is in DPDK virtio-user that they don’t comply with
virtio1.0 spec. I submitted a patch for them. I don’t think they
took it yet.

 

Steven

 

FROM: <vpp-dev-boun...@lists.fd.io> on behalf of "Guo, Ruijing"
<ruijing@intel.com>
DATE: Sunday, September 10, 2017 at 5:36 PM
TO: "Saxena, Nitin" <nitin.sax...@cavium.com>, "vpp-dev@lists.fd.io"
<vpp-dev@lists.fd.io>
SUBJECT: Re: [vpp-dev] vhost-user stable implementation?: VPP native
or DPDK

 

 

Just for your reference:

I am using vpp 17.07. The default one is vpp native. But it cannot
work with virtio-user. So I change to vhost-user in dpdk.

 

 

FROM: vpp-dev-boun...@lists.fd.io
[mailto:vpp-dev-boun...@lists.fd.io] ON BEHALF OF Saxena, Nitin
SENT: Monday, September 11, 2017 1:22 AM
TO: vpp-dev@lists.fd.io
SUBJECT: [vpp-dev] vhost-user stable implementation?: VPP native or
DPDK

 

Hi All

 

I went through following video regarding vhost-user.

 

https://www.youtube.com/watch?v=z-ZRof2hDP0
 [1]

 

The question is in this video it has been told by default VPP
implementation of vhost-user being used and not the dpdk one. Since
this video is 1 yr old and I am using vpp version 1704. Can
anyone please comment which vhost-user code is by default enabled in
vpp1704 - is it dpdk one or VPP native? I can see in
vpp-master/RELEASE.md that DPDK vhost was deprecated in vpp1609? Is it
fixed now?

 

Thanks,

Nitin



Links:
--
[1] https://www.youtube.com/watch?v=z-ZRof2hDP0

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vhost-user stable implementation?: VPP native or DPDK

[Prabhjot Singh Sethi]

Hi Steven,

we are also looking at using dpdk based virtualethernet interface, so
looking back at this thread i was wondering what is the problem with
dpdk based solution.

1. you mentioned dpdk based interface can be created via vdev in dpdk
clause of startup file, can you share some example there. only thing i
have seen as an example so far is associating a bond interface with
physical slave interfaces, is it possible to create one for VM ?
2. can you please share a link to the patch submitted for dpdk
virtio-user

Regards,
PrabhjotFROM: Steven Luong (sluong) 
SENT: Monday, September 11, 2017 7:46 PM
TO: Guo, Ruijing; Saxena, Nitin; vpp-dev@lists.fd.io
SUBJECT: Re: [vpp-dev] vhost-user stable implementation?: VPP native
or DPDK
  

 If you create the VIrtualEthernet interface via the CLI or binary
API, it always uses VPP native. If you create the virtual interface
via vdev in the dpdk clause in the startup file, it uses dpdk’s
vhost-user.

  

 The problem is in DPDK virtio-user that they don’t comply with
virtio1.0 spec. I submitted a patch for them. I don’t think they
took it yet.

  

 Steven

  

 FROM:  on behalf of "Guo, Ruijing"

DATE: Sunday, September 10, 2017 at 5:36 PM
TO: "Saxena, Nitin" , "vpp-dev@lists.fd.io"

SUBJECT: Re: [vpp-dev] vhost-user stable implementation?: VPP native
or DPDK

   

  

 Just for your reference:

 I am using vpp 17.07. The default one is vpp native. But it cannot
work with virtio-user. So I change to vhost-user in dpdk.

  

  

 FROM: vpp-dev-boun...@lists.fd.io
[mailto:vpp-dev-boun...@lists.fd.io] ON BEHALF OF Saxena, Nitin
SENT: Monday, September 11, 2017 1:22 AM
TO: vpp-dev@lists.fd.io
SUBJECT: [vpp-dev] vhost-user stable implementation?: VPP native or
DPDK

     

 Hi All

  

 I went through following video regarding vhost-user.

  

 https://www.youtube.com/watch?v=z-ZRof2hDP0 [1]

  

 The question is in this video it has been told by default VPP
implementation of vhost-user being used and not the dpdk one. Since
this video is 1 yr old and I am using vpp version 1704. Can
anyone please comment which vhost-user code is by default enabled in
vpp1704 - is it dpdk one or VPP native? I can see in
vpp-master/RELEASE.md that DPDK vhost was deprecated in vpp1609? Is it
fixed now?

  

 Thanks,

 Nitin

 

Links:
--
[1] https://www.youtube.com/watch?v=z-ZRof2hDP0

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vlan sub interfaces

[Prabhjot Singh Sethi]

ok, i wasn't aware that vlan sub interface support is advertised from
1710 release.

even though merge to 1707 was a preference, we are ok either way.
we can use it as a patch for now, till we move to 1710 builds

Regards,
Prabhjot

- Original Message -
From: "Luke Chris" <chris_l...@comcast.com>
To:"prabh...@techtrueup.com" <prabh...@techtrueup.com>, "Neale Ranns
(nranns)" <nra...@cisco.com>
Cc:"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Sent:Fri, 29 Sep 2017 16:01:41 +
Subject:RE: [vpp-dev] vlan sub interfaces

 Eeh, we haven't previously advertised support for VLAN tags on
af_packet before; I could believe it was a missing feature, but I have
a harder time accepting it was a bug.

 I'm not strongly against the merge (though I do have a preference for
strongly encouraging people to keep up with releases at this time),
but I do want us to be clear about the disposition of this change.

 Chris.

 > -Original Message-
 > From: vpp-dev-boun...@lists.fd.io
[mailto:vpp-dev-boun...@lists.fd.io] On
 > Behalf Of prabh...@techtrueup.com
 > Sent: Friday, September 29, 2017 11:43
 > To: Neale Ranns (nranns) <nra...@cisco.com>
 > Cc: vpp-dev@lists.fd.io
 > Subject: Re: [vpp-dev] vlan sub interfaces
 > 
 > well looking at the change it definitely suggests to be a bug fix.
 > 
 > we are currently using 1707 builds, and dont have plan to move to
newer
 > release right now, so would prefer a merge to 1707.
 > 
 > Regards,
 > Prabhjot
 > 
 > Quoting "Neale Ranns (nranns)"
 > <nra...@cisco.com>:
 > 
 > > With my release manager hat on …
 > > Do we consider support for VLAN tags on an AF packet interface a
bug
 > > fix (to be back ported) or a new feature (available from 17.10
 > > onwards)?
 > >
 > > /neale
 > >
 > > -Original Message-
 > > From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
 > > Date: Thursday, 28 September 2017 at 13:07
 > > To: "Dave Barach (dbarach)" <dbar...@cisco.com>
 > > Cc: "Neale Ranns (nranns)" <nra...@cisco.com>, "John Lo (loj)"
 > > <l...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>,
Akshaya
 > > Nadahalli <aksh...@rtbrick.com>
 > > Subject: Re: [vpp-dev] vlan sub interfaces
 > >
 > > yes i verified it on stable/1707 itself.
 > >
 > > Regards,
 > > Prabhjot
 > >
 > > Quoting "Dave Barach (dbarach)" <dbar...@cisco.com>:
 > >
 > > > See https://gerrit.fd.io/r/#/c/8590. The patch cherry-picked
easily
 > > > to stable/1707.
 > > >
 > > > Assuming that the cherry-pick patch validates - and that it
solves
 > > > your problem - it will be up to Neale [as the 17.07 release
manager]
 > > > whether to merge it or not.
 > > >
 > > > Please let us know whether the cherry-pick patch works for you.
 > > >
 > > > Thanks… Dave
 > > >
 > > > From: vpp-dev-boun...@lists.fd.io
 > > > [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Prabhjot
Singh Sethi
 > > > Sent: Thursday, September 28, 2017 3:27 PM
 > > > To: Akshaya Nadahalli <aksh...@rtbrick.com>; Prabhjot Singh
Sethi
 > > > <prabh...@techtrueup.com>; vpp-dev@lists.fd.io; John Lo (loj)
 > > > <l...@cisco.com>
 > > > Subject: Re: [vpp-dev] vlan sub interfaces
 > > >
 > > > yes it works perfectly fine with this patch.
 > > > i hope this will be pushed to 17.07 branch as well.
 > > >
 > > > Thanks for the help :)
 > > >
 > > > Regards,
 > > > Prabhjot
 > > >
 > > > - Original Message -
 > > > From:
 > > > "Akshaya Nadahalli"
 > <aksh...@rtbrick.com<mailto:aksh...@rtbrick.com>>
 > > >
 > > > To:
 > > > "Prabhjot Singh Sethi"
 > > > <prabh...@techtrueup.com<mailto:prabh...@techtrueup.com>>,
 > > > <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>, "John Lo"
 > > > <l...@cisco.com<mailto:l...@cisco.com>>
 > > > Cc:
 > > >
 > > > Sent:
 > > > Thu, 28 Sep 2017 19:18:50 +0530
 > > > Subject:
 > > > Re: [vpp-dev] vlan sub interfaces
 > > >
 > > >
 > > > Hi Prabhjot,
 > > >
 > > >
 > > >
 > > > Can you pls try with below patch and see if it helps:
 > > >
 > > > https://gerrit.fd.io/r/#/c/8435/
 > > >
 > > >
 > > >
 > > > Regards,
 > &

Re: [vpp-dev] vlan sub interfaces

[Prabhjot Singh Sethi]

yes it works perfectly fine with this patch.i hope this will be pushed
to 17.07 branch as well.

Thanks for the help :)

Regards,
Prabhjot

- Original Message -
From:
 "Akshaya Nadahalli" <aksh...@rtbrick.com>

To:
"Prabhjot Singh Sethi" <prabh...@techtrueup.com>,
<vpp-dev@lists.fd.io>, "John Lo" <l...@cisco.com>
Cc:

Sent:
Thu, 28 Sep 2017 19:18:50 +0530
Subject:
Re: [vpp-dev] vlan sub interfaces

Hi Prabhjot, 

Can you pls try with below patch and see if it helps: 

https://gerrit.fd.io/r/#/c/8435/ [1] 

Regards, 

    Akshaya N

On Thursday 28 September 2017 03:45 PM, Prabhjot Singh Sethi wrote:

 trying again with more appropriate subject 

 Can some one please help if i am missing any thing over here ?

 As mentioned earlier, i have interface host-eth10 and sub interface
host-eth10.10 (create sub host-eth10 10)

  host-eth10 is associated to bridge domain 2 and sub interface is
associated to bridge domain 3
 when VPP receives tagged packet with vlan 10 it still associates it
to bd 2 and not bd 3

 Note: if i don't associate any bd with base interface it just drops
the packet with some error.

 Regards,
 Prabhjot

___
 vpp-dev mailing list
vpp-dev@lists.fd.io [2]
https://lists.fd.io/mailman/listinfo/vpp-dev [3]  
-- 
 Regards,
 Akshaya N



Links:
--
[1] https://gerrit.fd.io/r/#/c/8435/
[2] mailto:vpp-dev@lists.fd.io
[3] 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

[vpp-dev] vlan sub interfaces

[Prabhjot Singh Sethi]

trying again with more appropriate subject

Can some one please help if i am missing any thing over here ?

As mentioned earlier, i have interface host-eth10 and sub interface
host-eth10.10 (create sub host-eth10 10)

host-eth10 is associated to bridge domain 2 and sub interface is
associated to bridge domain 3
when VPP receives tagged packet with vlan 10 it still associates it to
bd 2 and not bd 3

Note: if i don't associate any bd with base interface it just drops
the packet with some error.

Regards,
Prabhjot


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Trunk ports with VPP

[Prabhjot Singh Sethi]

the better configuration that suits my case for adding vlan tag while
egressing packet on sub interfaces is to use "pop 1" tag-rewrite.

However it is still a mystery why there is an issue with ingress of
vlan tagged packet, even though the packet is tagged with appropriate
vlan it stays on the main interface and is not supplied to sub
interface.

Can someone please help if there is something not supported here?

i am using VPP 17.07 with ubuntu 14.04
and using host interfaces for testing as of now

Regards,
Prabhjot

- Original Message -
From:
 "Prabhjot Singh Sethi" <prabh...@techtrueup.com>

To:
"John Lo (loj)" <l...@cisco.com>, "Prabhjot Singh Sethi"
<prabh...@techtrueup.com>, <vpp-dev@lists.fd.io>
Cc:

Sent:
Tue, 26 Sep 2017 20:01:03 +0530
Subject:
RE: [vpp-dev] Trunk ports with VPP

 Thanks for pointing it out, somehow intuitively i thought it is an
egress property of sub interface to attach vlan tag.

with the correct config to access ports in the bridge domain fix the
egress with a vlan tag on the trunk port.
however now while receiving the tagged packet on trunk port i see
correct tag, but it somehow is not associating it to correct bridge
domain.

so i have interface host-eth10 and sub interface host-eth10.10
host-eth10 is associated to bridge domain 2 and sub interface is
associated to bridge domain 3
when VPP receives tagged packet with vlan 10 it still associates it to
bd 2 and not bd 3

if i don't associate any bd with base interface it just drops the
packet with some error.

Also somewhere we expect to use translate vlan tags to different
external tags which need not be same as the one tag for bridge domain,
please let us know if it is a supported config.
set interface l2 tag-rewrite GigabitEthernet2/0/0.10 translate 1-1
dot1q 10

Regards,
Prabhjot

- Original Message -----
From:
 "John Lo (loj)" <l...@cisco.com>

To:
"Prabhjot Singh Sethi" <prabh...@techtrueup.com>,
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Cc:

Sent:
Mon, 25 Sep 2017 20:38:11 +
Subject:
RE: [vpp-dev] Trunk ports with VPP

The access port config from the example doc is aa follows:

create vhost socket /tmp/sock2.sock server

set interface state VirtualEthernet0/0/2 up

set interface l2 bridge VirtualEthernet0/0/2 200

set interface l2 tag-rewrite VirtualEthernet0/0/2 push dot1q 200

  

Note the tag-rewrite config on access port to push the VLAN tag on
the packet. Did you do this on the access ports?

  

Regards,

John

        

FROM: vpp-dev-boun...@lists.fd.io
[mailto:vpp-dev-boun...@lists.fd.io] ON BEHALF OF Prabhjot Singh Sethi
SENT: Monday, September 25, 2017 2:11 PM
TO: vpp-dev@lists.fd.io
SUBJECT: [vpp-dev] Trunk ports with VPP

  

Hi,

    i am trying to achieve trunck ports with VPP using following
documentation


https://wiki.fd.io/view/VPP/Interconnecting_vRouters_with_VPP#Create_TRUNK_ports
[1]

only difference is that i am trying this with host interfaces
connected to netns instance.

  

However packet egressing on this trunk port remains untagged
irrespective of which sub-interface it came from.

  

i am i missing something over here ?

  

Regards,
 Prabhjot



Links:
--
[1]
https://wiki.fd.io/view/VPP/Interconnecting_vRouters_with_VPP#Create_TRUNK_ports

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Trunk ports with VPP

[Prabhjot Singh Sethi]

Hi,
    i am trying to achieve trunck ports with VPP using following
documentation
https://wiki.fd.io/view/VPP/Interconnecting_vRouters_with_VPP#Create_TRUNK_ports
only difference is that i am trying this with host interfaces
connected to netns instance.

However packet egressing on this trunk port remains untagged
irrespective of which sub-interface it came from.

i am i missing something over here ?

Regards,
Prabhjot

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issue forwarding TCP packets

[Prabhjot Singh Sethi]

Hi Florin,

For now we can proceed with a requirement to disable offload on VMs.
but still keeping performance in view i think VPP should have option
similar to linux bridge to be able to do forwarding without correct
checksums, while offloading is enable the real checksum calculations
should be done only when the packet is egressing out of the server to
other compute nodes or gateway.

i think we can leave the topic open for now, and it can be considered
later for performance improvements for TCP

Regards,
Prabhjot

- Original Message -
From:
 "Florin Coras" <fcoras.li...@gmail.com>

To:
"Prabhjot Singh Sethi" <prabh...@techtrueup.com>.
Cc:
<vpp-dev@lists.fd.io>
Sent:
Tue, 29 Aug 2017 11:13:14 -0700
Subject:
Re: [vpp-dev] Issue forwarding TCP packets

 Hi Prabhjot, 

 In your setup, VPP just switches packets from one interface to the
other, irrespective of their L4 checksum. That is, it does not read
nor update them. Therefore, since the source Linux interface does not
provide correct checksums, the destination rejects all packets. 

 As you’ve noted lower, although the packets are ultimately
delivered to the app, even with the Linux bridge, the checksum is not
correctly computed when offloading is on. I suspect the reason for
this is an underlying optimization in the Linux kernel whereby local
interfaces can exchange L4 packets without the use of checksums. In
fact, the approach makes sense because packets never leave the kernel
between the sndmsg() and recvmsg() calls so there’s no need to
protect data integrity. However, this condition does not hold anymore
when vpp does the switching, so the checksums must be computed before
the packets leave the kernel (hence the need for checksum offload
disabling). 

 Hope this helps, 
 Florin 

 > On Aug 28, 2017, at 11:46 PM, prabh...@techtrueup.com wrote:
 > 
 > Thanks Florin,
 > it works with offload disabled, earlier when i tried changing
offload settings i missed doing it on one machine.
 > 
 > However my question is still about why VPP is unable to handle it,
is it a missing configuration or missing functionality in VPP?
 > 
 > i can ssh from one vm to another without turning off offload while
using linux bridge, and i don't see any change in the packet as well
after being forwarded. Though tcpdump complains about checksum, but
everything works fine.
 > 
 > packet ingressing into linux bridge from vm-1
 > 06:41:58.626869 02:53:71:ef:2f:2a > 02:91:fb:46:9e:43, ethertype
IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 6341, offset 0, flags
[DF], proto TCP (6), length 60)
 > 1.1.1.3.51912 > 1.1.1.4.22: Flags [S], cksum 0x0437 (incorrect ->
0xdeae), seq 2306393024, win 29200, options [mss 1460,sackOK,TS val
1825541 ecr 0,nop,wscale 7], length 0
 > 0x: 0291 fb46 9e43 0253 71ef 2f2a 0800 4500
 > 0x0010: 003c 18c5 4000 4006 1def 0101 0103 0101
 > 0x0020: 0104 cac8 0016 8978 c3c0   a002
 > 0x0030: 7210 0437  0204 05b4 0402 080a 001b
 > 0x0040: db05   0103 0307
 > 
 > packet egressing from linux bridge to vm-2
 > 06:41:58.627130 02:53:71:ef:2f:2a > 02:91:fb:46:9e:43, ethertype
IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 6341, offset 0, flags
[DF], proto TCP (6), length 60)
 > 1.1.1.3.51912 > 1.1.1.4.22: Flags [S], cksum 0x0437 (incorrect ->
0xdeae), seq 2306393024, win 29200, options [mss 1460,sackOK,TS val
1825541 ecr 0,nop,wscale 7], length 0
 > 0x: 0291 fb46 9e43 0253 71ef 2f2a 0800 4500
 > 0x0010: 003c 18c5 4000 4006 1def 0101 0103 0101
 > 0x0020: 0104 cac8 0016 8978 c3c0   a002
 > 0x0030: 7210 0437  0204 05b4 0402 080a 001b
 > 0x0040: db05   0103 0307
 > 
 > 
 > Regards,
 > Prabhjot
 > 
 > Quoting Florin Coras <fcoras.li...@gmail.com>:
 > 
 >> Hi Prabhjot,
 >> 
 >> From your description, I suspect it may be a linux tcp checksum
offload issue. Could you try disabling it for all interfaces with:
 >> 
 >> ethtool --offload  rx off tx off
 >> 
 >> Hope this helps,
 >> Florin
 >> 
 >>> On Aug 28, 2017, at 10:56 AM, Prabhjot Singh Sethi
<prabh...@techtrueup.com> wrote:
 >>> 
 >>> We have been trying to use VPP as a L2/L3 forwarding data path
between VMs.
 >>> 
 >>> where we have connected tap interfaces from VM to VPP using
"create host-interface name "
 >>> after adding both the interfaces to same bridge-domain (bd_id =
2), we are able to ping from
 >>> one VM to another (both in same subnet). However when we try to
do ssh we observe that all the
 >>> tcp packets are transmitted/forwarded by VPP to the other end but
they are dropped as
 >>> "bad segments received".
 >>> 
 >>> Can anyone help with what could be wrong here, are we missing any
other required config?
 >>

[vpp-dev] Regarding C API

[Prabhjot Singh Sethi]

We are looking forward to use C APIs to configure VPP and are looking
at https://wiki.fd.io/view/VPP/How_To_Use_The_C_API as a reference.

However following steps mentioned there, we do see a compilation
failure "failed to find library" for 
VPP_LIBS += -lvat_pliugin
where it looks like a typo so i have tried using "vat_plugin" as well
without any success.

can someone help with following
- is the name of the library correct
- where can i find this library

Regards,
Prabhjot

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev