[sfc-dev] FW: Service Chain Last Hop

Reinaldo Penno rapenno at gmail.com
Wed Aug 26 18:38:43 UTC 2015


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
>> 
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150826/782532b6/attachment.html>


More information about the sfc-dev mailing list