Sorry, I should have clarified, 172.16.4.1 is a dummy UDP server reflecting packets back to the sender (since localhost wasn’t working). Indeed VXLAN packets are arriving on the dummy server, though they’re not being accepted back by OVS. I was hoping to specify the VNID in flows as it much more dynamic, though I’ll try with static VNIDs and report back.
On Wed, Sep 24, 2014 at 4:43 PM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Sep 24, 2014 at 11:07:06AM +1000, Jaime Pillora wrote: > > #switch 1 > > sh ovs-vsctl add-port s1 vx1 -- set interface vx1 type=vxlan > > option:remote_ip=172.16.4.1 option:key=flow ofport_request=11 > > sh ovs-ofctl add-flow s1 'in_port=11,tun_id=2,actions=output:1' > > sh ovs-ofctl add-flow s1 > 'in_port=1,actions=set_field:1->tun_id,output:11' > > > > #switch 2 > > sh ovs-vsctl add-port s2 vx2 -- set interface vx2 type=vxlan > > option:remote_ip=172.16.4.1 option:key=flow ofport_request=22 > > sh ovs-ofctl add-flow s2 'in_port=22,tun_id=1,actions=output:1' > > sh ovs-ofctl add-flow s2 > 'in_port=1,actions=set_field:2->tun_id,output:22’ > > > > I was hoping that packets incoming to OVS would match against the VXLAN > > port flows, however it seems as if OVS always chooses the first VXLAN > port > > for all VXLAN packets > > Both of these ports have the same configuration (same remote IP and > key), so they conflict and only one of them can be configured. They are > actually acting on packets with different tunnel IDs, so you could > configure one of them with option:key=1 and the other one with > option:key=2. > -- *Jaime Pillora |* Chief Software Architect web: lumanetworks.com email: ja...@lumanetworks.com mobile: +61 (0) 422 171 218
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
