[sfc-dev] Service Chain Last Hop

Ricardo Noriega De Soto ricardo.noriega.de.soto at ericsson.com
Thu Aug 27 16:14:32 UTC 2015


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?? I guess not since the SFF is not capable of decap the traffic, am I wrong?

- By kernel, you mean the system where the OVS that will act as SFF is running, right?

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<mailto: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<mailto:danny.zhou at intel.com>>, Reinaldo Penno <rapenno at gmail.com<mailto:rapenno at gmail.com>>
Cc: "<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<mailto: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.

[cid:image001.png at 01D0E10A.18EB9800]

From: <mailto:sfc-dev-bounces at lists.opendaylight.org> sfc-dev-bounces at lists.opendaylight.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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> [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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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: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>" <<mailto:sfc-dev at lists.opendaylight.org>sfc-dev at lists.opendaylight.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:ricardo.noriega.de.soto at ericsson.com>>
Cc: Reinaldo Penno <<mailto:rapenno at gmail.com>rapenno at gmail.com<mailto:rapenno at gmail.com>>, "<mailto:sfc-dev at lists.opendaylight.org>sfc-dev at lists.opendaylight.org<mailto:sfc-dev at lists.opendaylight.org>" <<mailto:sfc-dev at lists.opendaylight.org>sfc-dev at lists.opendaylight.org<mailto: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<mailto:sfc-dev at lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev




_______________________________________________
sfc-dev mailing list
sfc-dev at lists.opendaylight.org<mailto: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/98524ddc/attachment-0001.html>


More information about the sfc-dev mailing list