[sfc-dev] Service Chain Last Hop

Reinaldo Penno rapenno at gmail.com
Thu Aug 27 18:11:10 UTC 2015


If you are using GBP+SFC, GBP would decap as this extra hop

The sff_client can also do that.

From:  Ricardo Noriega De Soto <ricardo.noriega.de.soto at ericsson.com>
Date:  Thursday, August 27, 2015 at 9:54 AM
To:  Reinaldo Penno <rapenno at gmail.com>
Cc:  "Zhou, Danny" <danny.zhou at intel.com>, "sfc-dev at lists.opendaylight.org"
<sfc-dev at lists.opendaylight.org>
Subject:  Re: [sfc-dev] Service Chain Last Hop

Thanks for your answers!! Just one more...

Which component would decap the traffic as this extra-hop? The SFC agent
configured somehow?

Enviado desde mi iPhone

El 27/8/2015, a las 18:49, Reinaldo Penno <rapenno at gmail.com> escribió:

> Inline with [RP]
> 
> From: Ricardo Noriega De Soto <ricardo.noriega.de.soto at ericsson.com>
> Date: Thursday, August 27, 2015 at 9:14 AM
> To: Reinaldo Penno <rapenno at gmail.com>, "Zhou, Danny" <danny.zhou at intel.com>
> Cc: "sfc-dev at lists.opendaylight.org" <sfc-dev at lists.opendaylight.org>
> Subject: Re: [sfc-dev] Service Chain Last Hop
> 
> Hi Reinaldo,
> 
> I fully agree with you. This scenario makes a lot of sense to me.
> 
> - Does this mean that SFC is not fully operative with NSH/VxLAN-GPE
> encapsulation??
> 
> [RP] It means AFAIK OVS (with a single interface) can not decap the NSH packet
> and send a plain IP packet out. Some people say it can, but I have not seen it
> . With multiple interface and bridges (Openstack style) I know it can be done
> but then it defeats the purpose of keeping it simple.
> 
> 
> I guess not since the SFF is not capable of decap the traffic, am I wrong?
> 
> [RP] The work around for that is to add context headers and have an ³extra
> hop² . This extra hop is the one that actually decaps the NSH packet.
> 
> 
> - By kernel, you mean the system where the OVS that will act as SFF is
> running, right?
> 
> [RP] Yes. 
> 
> 
> BR
> Ricky
> 
> On 08/27/2015 05:43 PM, Reinaldo Penno wrote:
>> 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?
>>   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" < <mailto:danny.zhou at intel.com> danny.zhou at intel.com>
>> Date: Thursday, August 27, 2015 at 6:07 AM
>> To: "Zhou, Danny" < <mailto:danny.zhou at intel.com> danny.zhou at intel.com>,
>> Reinaldo Penno <rapenno at gmail.com>
>> Cc: " <mailto:sfc-dev at lists.opendaylight.org> 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: <mailto:sfc-dev-bounces at lists.opendaylight.org>
>> 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> mailto:rapenno at gmail.com]
>> Sent: Thursday, August 27, 2015 12:06 PM
>> To: Zhou, Danny
>> Cc: Ricardo Noriega De Soto;  <mailto:sfc-dev at lists.opendaylight.org>
>> 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 < <mailto:danny.zhou at intel.com>
>> 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> mailto:rapenno at gmail.com]
>>> Sent: Thursday, August 27, 2015 11:32 AM
>>> To: Zhou, Danny
>>> Cc: Ricardo Noriega De Soto;  <mailto:sfc-dev at lists.opendaylight.org>
>>> 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: <mailto:sfc-dev-bounces at lists.opendaylight.org>
>>>> 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:  <mailto:sfc-dev at lists.opendaylight.org> 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 < <mailto:rapenno at gmail.com>
>>>>> rapenno at gmail.com> escribió:
>>>>>  
>>>>> 
>>>>> For the benefit of the list since lots of folks interested.
>>>>> 
>>>>>  
>>>>> 
>>>>> From: Reinaldo Penno < <mailto:rapenno at gmail.com> rapenno at gmail.com>
>>>>> Date: Wednesday, August 26, 2015 at 11:36 AM
>>>>> To: João Silva < <mailto:silvajp9 at gmail.com> silvajp9 at gmail.com>
>>>>> Subject: Re: [sfc-dev] Service Chain Last Hop
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>> From: João Silva < <mailto:silvajp9 at gmail.com> silvajp9 at gmail.com>
>>>>> Date: Wednesday, August 26, 2015 at 11:32 AM
>>>>> To: Reinaldo Penno < <mailto:rapenno at gmail.com> 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 <
>>>>> <mailto:rapenno at gmail.com> 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 < <mailto:silvajp9 at gmail.com> silvajp9 at gmail.com>
>>>>> Date: Wednesday, August 26, 2015 at 11:16 AM
>>>>> To: Reinaldo Penno < <mailto:rapenno at gmail.com> 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 <
>>>>> <mailto:rapenno at gmail.com> 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 < <mailto:silvajp9 at gmail.com> silvajp9 at gmail.com>
>>>>> Date: Wednesday, August 26, 2015 at 10:49 AM
>>>>> To: Reinaldo Penno < <mailto:rapenno at gmail.com> rapenno at gmail.com>
>>>>> Cc: Ricardo Noriega De Soto <
>>>>> <mailto:ricardo.noriega.de.soto at ericsson.com>
>>>>> ricardo.noriega.de.soto at ericsson.com>, "
>>>>> <mailto:sfc-dev at lists.opendaylight.org> sfc-dev at lists.opendaylight.org" <
>>>>> <mailto: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
>>>>> <mailto:E..... at .@.J...2> 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 <
>>>>> <mailto:rapenno at gmail.com> rapenno at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> Are you sending the packet with the context headers filled?
>>>>> 
>>>>>  
>>>>> 
>>>>> From: João Silva < <mailto:silvajp9 at gmail.com> silvajp9 at gmail.com>
>>>>> Date: Wednesday, August 26, 2015 at 9:19 AM
>>>>> To: Ricardo Noriega De Soto <
>>>>> <mailto:ricardo.noriega.de.soto at ericsson.com>
>>>>> ricardo.noriega.de.soto at ericsson.com>
>>>>> Cc: Reinaldo Penno < <mailto:rapenno at gmail.com> rapenno at gmail.com>, "
>>>>> <mailto:sfc-dev at lists.opendaylight.org> sfc-dev at lists.opendaylight.org" <
>>>>> <mailto: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
>>>>  
>> 
>>  
>> _______________________________________________
>> sfc-dev mailing list
>> sfc-dev at lists.opendaylight.orghttps://lists.opendaylight.org/mailman/listinfo
>> /sfc-dev
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150827/3c992082/attachment-0001.html>


More information about the sfc-dev mailing list