Hello again,

Fujita, I decided to use OVS with Mininet on my own to test behavior related to 
my issue.
Unfortunately, it didn't explained anything - I tried with OpenFlow 1.{2,3}. 
Below I is 
the scenario along with the results. Note, I utilized ryu-vm as my testbed.

1. I started Mininet: sudo mn --switch ovsk,protocols=OpenFlow13 --controller 
remote
2. Then configured OVS to use OF13: sudo ovs-vsctl set bridge s1 
protocols=OpenFlow13
3. Then ryu: ryu-manager ryu/ryu/app/simple_switch_13.py --verbose
4. The Open Flow Channel opens.
5. Then I set up appropriate flows: 
sudo ovs-ofctl -O Openflow13 add-flow s1 dl_vlan=50,actions=controller
5. Then I send VLAN-tagged packet to through the Mininet:
h1 sudo tcpreplay -i h1-eth0 ping_vlan_50.pcap
6. I verify that the packet matched on the flow:
sudo ovs-ofctl -O OpenFlow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=281.497s, table=0, n_packets=2, n_bytes=204, 
priority=100,dl_vlan=50 actions=CONTROLLER:65535
 cookie=0x0, duration=374.26s, table=0, n_packets=0, n_bytes=0, 
priority=0 actions=CONTROLLER:65535
7. Then I look at the Wireshark using OF13 dissector and it turns out the 
there's only
OFPXMT_OFB_IN_PORT field in the match.

It's the same for OF 1.2. Am I missing something or just OVS doesn't send 
complete match
in the packet_in message? 

If anyone knows why things are like that, please let me know.

Regards,

Szymon 

----- Oryginalna wiadomość -----
> Od: "Szymon Mentel" <[email protected]>
> Do: "FUJITA Tomonori" <[email protected]>
> DW: [email protected]
> Wysłane: wtorek, 8 lipiec 2014 14:43:11
> Temat: Re: [Ryu-devel] OXM_OF_VLAN_VID and ofp_packet_in message
> 
> OK, Thanks. The fact the other switches set the bit makes me less sure that
> LINC is compliant.
> 
> Could you point me to the specification's chapter indicating that switch
> should include a match
> sent by the controller? Before I decided to ask someone a tried to understand
> the spec and
> I feel that I've missed something.
> 
> Regards,
> 
> ----- Oryginalna wiadomość -----
> > Od: "FUJITA Tomonori" <[email protected]>
> > Do: "szymon mentel" <[email protected]>
> > DW: [email protected]
> > Wysłane: poniedziałek, 7 lipiec 2014 15:34:35
> > Temat: Re: [Ryu-devel] OXM_OF_VLAN_VID and ofp_packet_in message
> > 
> > Hello,
> > 
> > On Mon, 7 Jul 2014 08:35:28 +0200 (CEST)
> > Szymon Mentel <[email protected]> wrote:
> > 
> > > I'm a developer of an OpenFlow switch LINC [1]. Recently I've came across
> > > an issue from one of our users on VLAN_VID match field [2]. He suggests
> > > that LINC behaves incorrectly while not setting the 13th bit in the value
> > > of the match field that is sent in a packet_in message to the controller.
> > > In that case LINC would have to set the value to 0x1**** (where **** is
> > > the VLAN ID) when a VLAN tag is matched.
> > > 
> > > On the other hand,  I believe that LINC is compliant with the spec. If a
> > > switch sends packet_in with a match on VLAN it's obvious that the VLAN
> > > tag
> > > was indeed present in the packet and this information doesn't have to be
> > > carried in an additional bit. If the VLAN is not present the match field
> > > for VLAN is simply omitted in the packet_in.
> > > 
> > > What is your opinion on this topic?
> > 
> > I guess that match should have 0x1**** in a PacketIn message because a
> > PacketIn message is supposed to include a match that a controller
> > sent. A controller is supposed to send a FlowMod with a match field
> > with 0x1****. IIRC, OVS works in such way.
> > 
>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to