[ovs-discuss] a GRE-Tunnel problem on the OVS and openflow enabled switch

Justin Pettit jpettit at nicira.com
Wed Jun 27 03:19:08 UTC 2012

On Jun 26, 2012, at 10:25 PM, Weifeng Zhang wrote:

> I DO notice that OVS uses kernel route to forward the packets. But generally
> the host OS will only maintain host route and default route. On a server
> which OVS is embedded, it may be enough.
> But we are implementing a independent switch device with ASIC chip, which
> supports OVS stack and openflow, maybe we need some static LPM route to
> forward the encapsulated tunnel packet. Do you think so?

Yes, it certainly seems reasonable to support more complicated routing configuration.  Of course, it will depend on how your customers are planning to deploy your device.

> By the way, on the reverse direction, the de-capsulated packet will be
> forwarded by openflow flow entries, right?

It depends on how the system is configured.  In some deployments I've seen, the interface that is carrying the GRE traffic isn't attached to OVS.  In this case, the host OS is just directly receiving the packets, which are handed off to OVS for GRE processing.  If the interface carrying the GRE traffic *is* attached to OVS, then OVS will need to be setup to send traffic to the host OS (which will eventually hand it back to OVS for the actual GRE processing).  Keep in mind that for being a GRE endpoint, it's necessary to support other services for the bound IP address like ARP.


More information about the discuss mailing list