So I’m now using option:key=1 and 2 instead of key=flow. I’m attempting to tag 1 -> 2 with VNID 2, and 2 -> 1 with VNID 1.
*** Setting VXLAN 1 -> 2 ovs-vsctl set bridge s1 protocols=OpenFlow13 ovs-vsctl add-port s1 vx1 -- set interface vx1 type=vxlan option:remote_ip=localhost option:key=1 ofport_request=11 ovs-ofctl add-flow s1 -O Openflow13 'in_port=1,actions=set_field:2->tun_id,output:11' ovs-ofctl add-flow s1 -O Openflow13 'in_port=11,tun_id=1,actions=output:1' *** Setting VXLAN 2 -> 1 ovs-vsctl set bridge s2 protocols=OpenFlow13 ovs-vsctl add-port s2 vx2 -- set interface vx2 type=vxlan option:remote_ip=localhost option:key=2 ofport_request=22 ovs-ofctl add-flow s2 -O Openflow13 'in_port=1,actions=set_field:1->tun_id,output:22' ovs-ofctl add-flow s2 -O Openflow13 'in_port=22,tun_id=2,actions=output:1’ I’m ping from the host connected to 1, we can ARP broadcasts are leaving OVS, though not making it back: $ ovs-ofctl -O Openflow13 dump-flows s1 OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=157.935s, table=0, n_packets=0, n_bytes=0, tun_id=0x1,in_port=11 actions=output:1 cookie=0x0, duration=157.939s, table=0, n_packets=10, n_bytes=684, in_port=1 actions=set_field:0x2->tun_id,output:11 $ ovs-ofctl -O Openflow13 dump-flows s2 OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=160.003s, table=0, n_packets=0, n_bytes=0, tun_id=0x2,in_port=22 actions=output:1 cookie=0x0, duration=160.007s, table=0, n_packets=0, n_bytes=0, in_port=1 actions=set_field:0x1->tun_id,output:22 (Note, this also occurs when using my reflector/debugging UDP server, which forces the packets to leave the VM and re-enter) On Wed, Sep 24, 2014 at 4:50 PM, Jaime Pillora <ja...@lumanetworks.com> wrote: > 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 > -- *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
