[sfc-dev] Service Chain Last Hop

Reinaldo Penno rapenno at gmail.com
Fri Aug 28 06:21:32 UTC 2015


I tried that based on a patch from Brady but it did not work.  But there is
always a possibility that something was wrong.

From:  "Xiao Liang (xiaolia)" <xiaolia at cisco.com>
Date:  Thursday, August 27, 2015 at 10:33 PM
To:  "Zhou, Danny" <danny.zhou at intel.com>, Reinaldo Penno
<rapenno at gmail.com>
Cc:  "sfc-dev at lists.opendaylight.org" <sfc-dev at lists.opendaylight.org>
Subject:  RE: [sfc-dev] Service Chain Last Hop

Hi,
 
At the last hop SFF, can we just direct the original L3 packet (whose outer
header has been removed by VTEP) to LOCAL port?
 
Thanks
 

From: sfc-dev-bounces at lists.opendaylight.org
[mailto:sfc-dev-bounces at lists.opendaylight.org] On Behalf Of Zhou, Danny
Sent: Friday, August 28, 2015 12:12
To: Reinaldo Penno
Cc: sfc-dev at lists.opendaylight.org
Subject: Re: [sfc-dev] Service Chain Last Hop
 
Hi Reinaldo, I added inline comments with [DZ]
 

From: Reinaldo Penno [mailto:rapenno at gmail.com]
Sent: Thursday, August 27, 2015 11:44 PM
To: Zhou, Danny
Cc: sfc-dev at lists.opendaylight.org
Subject: Re: [sfc-dev] Service Chain Last Hop
 

HI Danny, 

 

I still think there is a disconnect about what is going on.  Let me try a
different way.

 

 

Without SFC you have a client A and Server B that communicate with each
other.

 

 

Client A (10.0.0.2) --------> Server B (10.0.0.100)

 

 

Now you put a SFC in the middle

 

                          SF (Firewall)

                               |

Client A ---> classifier ---> SFF ---> Server B

                    |--- NSH ‹|

 

 

- After SFF gets a packet from the Firewall it checks that it is the end of
the path and does the following:

 

1 ­ Removes NSH and any other outer encapsulation(VXLAN, Ethernet, etc).

     At this point SFF has the original IP packet that A sent to B

2 ­ SFF then releases this original packet to the kernel

3 ­ kernel forwards this original packet to Server B as it would any other
packet. 

 

 

Premise:

 

- SPID is 1, SI is 255, which means SI = 254 when SFF last receives it.

- Encapsulation is VXLAN-GPE

 

Questions:

 

Can this be achieved with a single physical ethernet interface?  If more
than one is needed than it would tremendously complicate unit testing.

What would be the OF rules look like?
 
[DZ]: No need to add an additional physical Ethernet interface.  Just
forward the original packet out via eth1 (in the diagram below) device on
the SFF no matter the eth1 is driven by kernel driver or DPDK PMD in user
space, assuming the network middle boxes (e.g. router or switches) have been
configured correctly to forward the original packet to the Server B.  The
tricky on the VxLAN-GPE-NSH port on br-eth1 bridge of the SFF is it needs
rule to
1)     re-encapsulate the decapsulated tunneling packets if they come from
physical port eth1,  and then forward the re-encapsulated packets with NSH
header to SF (e.g. Firewall).

2)     do not re-encapsulate the tunneling packets if they come from vport
connecting to the SF and NSI = 0, so the original packets can be forwarded
to the eth1 directly.

Please noted, the behavior of VTEP port on the bridge is that it
automatically decapsulates the turning packets on the bridge.
 

  I¹m assuming we can not put individual rules for each possible client
(there might be millions), so we need some sort of wildcard

 

 

Thanks,

 

 

From: "Zhou, Danny" <danny.zhou at intel.com>
Date: Thursday, August 27, 2015 at 6:07 AM
To: "Zhou, Danny" <danny.zhou at intel.com>, Reinaldo Penno <rapenno at gmail.com>
Cc: "sfc-dev at lists.opendaylight.org" <sfc-dev at lists.opendaylight.org>
Subject: RE: [sfc-dev] Service Chain Last Hop

 

For a typical setup in diagram below where SFF(NSH-aware OvS) connects to
Classifier(NSH-aware OvS) via VxLAN-GPE-NSH tunnel, the OVSDB commandline
for the Classifier to setup VTEP is:
# ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 type=vxlan
options:remote_ip=192.168.1.2 options:dst_port=4790 options:out_nsi=flow
options:out_nsp=flow options:in_nsi=flow options:in_nsp=flow
/* Note: UDP destination port set to 4790 means this is a VxLAN-GPE-NSH VTEP
rather than a regular VxLAN VTEP */
 
And the flow commandline is
# ovs-ofctl add-flow br-int ³in_port=2, nw_src =10.0.0.3 actions=output:1³
/* Note: Port1 on br-int connects to eth2 and Port2 connects to vxlan0 which
is a VxLAN-GPE-NSH port. So when the classifier receives a tunneling packet
from the SFF, the vxlan0 VTEP strips off VxLAN-GPE and NSH header then
transmit a plain packet out via eth2 if its source IP is 10.0.0.3 */
 
SFC should generate equivalent Openflow messages via sfcofl2 and use OVSDB
SB plugin to creates VTEP port on both classifier and SFF.
 
 

From:sfc-dev-bounces at lists.opendaylight.org
[mailto:sfc-dev-bounces at lists.opendaylight.org] On Behalf Of Zhou, Danny
Sent: Thursday, August 27, 2015 12:17 PM
To: Reinaldo Penno
Cc: sfc-dev at lists.opendaylight.org
Subject: Re: [sfc-dev] Service Chain Last Hop
 
Unlike encapsulation which needs sfcofl2 to control VTEP what to fill the
L2/L3 as well as NSH headers, decapsulation is default behavior of OVS VTEP
which is controlled by OVSDB only, not by Openflow/sfcofl2. The NSH-aware
VTEP is smart enough to strip VxLAN-GPE-NSH header if it detects it is
VxLAN-GPE header, otherwise it removes VxLAN header only. Let me dig into it
and come back with detailed solution.
 

From: Reinaldo Penno [mailto:rapenno at gmail.com]
Sent: Thursday, August 27, 2015 12:06 PM
To: Zhou, Danny
Cc: Ricardo Noriega De Soto; sfc-dev at lists.opendaylight.org
Subject: Re: [sfc-dev] Service Chain Last Hop
 

Right but the OF rules installed by sfcofl2 do not have this capability.
Keith mentioned a patch but modulus testing and merging this possible patch
the OVS solution has this limitation. Do you have idea on how to approach
this problem?


On Aug 26, 2015, at 8:38 PM, Zhou, Danny <danny.zhou at intel.com> wrote:
> 
> Thanks Reinaldo. For that case, technically the NSH-aware OVS can be
> configured to remove the VxLAN-GPE-NSH header and send original L2 frame out,
> no matter the OvS acts as classifier or SFF.
> 
> From: Reinaldo Penno [mailto:rapenno at gmail.com]
> Sent: Thursday, August 27, 2015 11:32 AM
> To: Zhou, Danny
> Cc: Ricardo Noriega De Soto; sfc-dev at lists.opendaylight.org
> Subject: Re: [sfc-dev] Service Chain Last Hop
>  
> 
> Danny,
> 
>  
> 
> I think the question is about the last SFF, no more SF or anything else.
> Currently it can not decap VXLAN packet and send a plain IP packet out.
> Therefore we make the OVS send the packet an 'extra hop' that can actually
> decap the packet.
> 
> Thanks
> 
> 
> On Aug 26, 2015, at 8:23 PM, Zhou, Danny <danny.zhou at intel.com> wrote:
>> 
>> NSH-aware OvS DOES decapsulate VxLAN-GPE-NSH tunneling packets. The trick
>> part is that once decapsulation is done the VxLAN-GPE header is removed, in
>> order for SFF to steer traffics to NSH-aware SF with NSH header, you have to
>> add a transport before the NSH header otherwise the MAC layer in SF will drop
>> them due to no L2 header. So OvS could 1) re-encapsulate the NSH + Original
>> L2 frame with the VxLAN-GPE header (which is how patched OvS works today) or
>> 2) add a Ethernet header before the NSH + Original L2 frame.
>>  
>> 
>> From:sfc-dev-bounces at lists.opendaylight.org
>> [mailto:sfc-dev-bounces at lists.opendaylight.org] On Behalf Of Ricardo Noriega
>> De Soto
>> Sent: Thursday, August 27, 2015 6:03 AM
>> To: Reinaldo Penno
>> Cc: sfc-dev at lists.opendaylight.org
>> Subject: Re: [sfc-dev] Service Chain Last Hop
>>  
>> 
>> Please, I¹d appreciate if you answer these questions:
>> 
>>  
>> 
>> - Is the patched OVS NSH-aware capable of decapsulating traffic?
>> 
>>  
>> 
>> - Regarding this:
>> 
>>  
>>> 
>>> ctx1 is the dstset in this header for the final hop?
>>> 
>>>  
>>> 
>>> [RP] Correct. If you set this IPaddress to the machine where the sff_client
>>> is running it will get the packet back and print it out.
>>  
>> 
>> What if we want to get rid of the sff_client? Which would be the best way of
>> doing that?
>> 
>>  
>> 
>> I see the sff_client as a testing tool, as Reinaldo mentioned, but nothing
>> more than that. It is very important to use real traffic and make an
>> infrastructure to encap/decap it transparently.
>> 
>>  
>>  
>>> 
>>> El 26/8/2015, a las 20:38, Reinaldo Penno <rapenno at gmail.com> escribió:
>>>  
>>> 
>>> For the benefit of the list since lots of folks interested.
>>> 
>>>  
>>> 
>>> From: Reinaldo Penno <rapenno at gmail.com>
>>> Date: Wednesday, August 26, 2015 at 11:36 AM
>>> To: João Silva <silvajp9 at gmail.com>
>>> Subject: Re: [sfc-dev] Service Chain Last Hop
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: João Silva <silvajp9 at gmail.com>
>>> Date: Wednesday, August 26, 2015 at 11:32 AM
>>> To: Reinaldo Penno <rapenno at gmail.com>
>>> Subject: Re: [sfc-dev] Service Chain Last Hop
>>> 
>>>  
>>> 
>>> Please, clear something for me: the outer header is the the VxLANGPE right?
>>> 
>>>  
>>> 
>>> [RP] Yes.
>>> 
>>>  
>>> 
>>>  
>>> ctx1 is the dstset in this header for the final hop?
>>> 
>>>  
>>> 
>>> [RP] Correct. If you set this IPaddress to the machine where the sff_client
>>> is running it will get the packet back and print it out.
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Wed, Aug 26, 2015 at 7:25 PM, Reinaldo Penno <rapenno at gmail.com> wrote:
>>> 
>>> 
>>> No, the context header determines the the destination that will be used in
>>> the outer IP header.  It is something to overcome the inability of OVS to
>>> decap and send a plain IP packet out.
>>> 
>>>  
>>> 
>>> From: João Silva <silvajp9 at gmail.com>
>>> Date: Wednesday, August 26, 2015 at 11:16 AM
>>> To: Reinaldo Penno <rapenno at gmail.com>
>>> 
>>> 
>>> Subject: Re: [sfc-dev] Service Chain Last Hop
>>> 
>>>  
>>> 
>>> That works fine. But what is sent to --ctx1 is the encapsulated packet, is
>>> it not?
>>> 
>>>  
>>> 
>>> On Wed, Aug 26, 2015 at 7:01 PM, Reinaldo Penno <rapenno at gmail.com> wrote:
>>> 
>>> 
>>> Please use the NSH client (sff_client) and send packets with context headers
>>> filled.
>>> 
>>>  
>>> 
>>> In general the way I test these things is the following: I test with the
>>> sff_client and agent and if it works I start complicating and/or
>>> substituting pieces.
>>> 
>>>  
>>> 
>>> In SFC 102 I show how you send a packet with context header filled. Noticed
>>> the "--ctx1 192.168.1.7"
>>> 
>>>  
>>> 
>>> "REPENNO-M-L9FE:sfc repenno$ python3.4 sff_client.py --remote-sff-ip
>>> 192.168.1.27 --local-port 6633 --remote-sff-port 6633 --sfp-id 3 --sfp-index
>>> 255 --encapsulate vxlan-nsh-ethernet-legacy --inner-src-ip 192.168.0.1
>>> --inner-dest-ip 192.168.1.13 --inner-src-port 10000 --inner-dest-port 20000
>>> --ctx1 192.168.1.7²
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: João Silva <silvajp9 at gmail.com>
>>> Date: Wednesday, August 26, 2015 at 10:49 AM
>>> To: Reinaldo Penno <rapenno at gmail.com>
>>> Cc: Ricardo Noriega De Soto <ricardo.noriega.de.soto at ericsson.com>,
>>> "sfc-dev at lists.opendaylight.org" <sfc-dev at lists.opendaylight.org>
>>> 
>>> 
>>> Subject: Re: [sfc-dev] Service Chain Last Hop
>>> 
>>>  
>>> 
>>> The SFF is configured with 'flow' for every nshc. The classification/encap
>>> is done by the classifier, which sets the nshc to 0.
>>> 
>>> 
>>>     0x0000:  4500 009e 0aed 4000 4011 4a0a c0a8 3206  E..... at .@.J...2.
>>>     0x0010:  c0a8 3201 bc8f 19e9 008a e5f3 0800 0000  ..2.............
>>>     0x0020:  ffff ff00 0006 0103 0000 03ff 0000 0000  ................
>>>     0x0030:  0000 0000 0000 0000 0000 0000 3c15 c2c9  ............<...
>>>     0x0040:  4fbc 0800 27b6 b058 0800 4500 0054 47a4  O...'..X..E..TG.
>>>     0x0050:  4000 4001 0daf c0a8 3202 c0a8 3203 0800  @. at .....2...2...
>>>     0x0060:  94b2 27ef 0370 3ffb dd55 0000 0000 56ca  ..'..p?..U....V.
>>>     0x0070:  0500 0000 0000 1011 1213 1415 1617 1819  ................
>>>     0x0080:  1a1b 1c1d 1e1f 2021 2223 2425 2627 2829  .......!"#$%&'()
>>>     0x0090:  2a2b 2c2d 2e2f 3031 3233 3435 3637       *+,-./01234567
>>> 
>>>  
>>> 
>>> On Wed, Aug 26, 2015 at 5:38 PM, Reinaldo Penno <rapenno at gmail.com> wrote:
>>> 
>>> 
>>> Are you sending the packet with the context headers filled?
>>> 
>>>  
>>> 
>>> From: João Silva <silvajp9 at gmail.com>
>>> Date: Wednesday, August 26, 2015 at 9:19 AM
>>> To: Ricardo Noriega De Soto <ricardo.noriega.de.soto at ericsson.com>
>>> Cc: Reinaldo Penno <rapenno at gmail.com>, "sfc-dev at lists.opendaylight.org"
>>> <sfc-dev at lists.opendaylight.org>
>>> Subject: Re: [sfc-dev] Service Chain Last Hop
>>> 
>>>  
>>> 
>>> That last rule 'throws' back the packet received from the last service
>>> function to the port where it was received from (IN_PORT). The packet is
>>> sent as received (including VXLANGPE + NSH encap) except for the nshc1 which
>>> is set to 0. 
>>> Now when the last sf receives this 're-sent' packet it just ignores it
>>> because the mac_dst is the SFF, and the packet dies here never reaching its
>>> final destination.
>>> Maybe the nshc1 = 0 is a flag for the python sff agent to decap and forward
>>> the packet. But on the OVS I would expect the last rule to either:
>>> ?        pop the headers and forward
>>> ?        or forward to the classifier
>>> 
>>> To comply with what is being discussed here as the correct behavior for the
>>> last hop. 
>>> 
>>> Is this rule a bug, the last hop for the ovs sff is not yet implemented or a
>>> config problem?
>>> Can someone shed some light on this?
>>> 
>>> Best regards,
>>> 
>>> João
>>>  
>>>  
>>>  
>>> _______________________________________________
>>> sfc-dev mailing list
>>> sfc-dev at lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
>>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150827/d2917c20/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 10202 bytes
Desc: not available
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150827/d2917c20/attachment-0001.png>


More information about the sfc-dev mailing list