[ovs-discuss] about

[qintao (F)]

Dear all ,

 we create a bridge "br1" with the type of netdev .And the version of the 
ovs is 2.5.0. Then we run the command "ovs-vsctl set int br1 lldp:enable=true " 
to make the interface br1 enable the function lldp.After that ,we delete the 
bridge br1 ,we found the the process "ovs-vswitchd" has been lost.
"

[cid:image001.png@01D2B8F3.98B68D70]
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Controller connection port

[蘇于倫]

Got it. I'll try it.

Ethan

Ben Pfaff  於 2017年4月19日 週三 上午2:08寫道：

> I guess that if you know these kinds of specific properties of your
> network, then perhaps you should disable in-band control and add your
> own control flows.
>
> On Tue, Apr 18, 2017 at 05:31:37PM +, 蘇于倫 wrote:
> > Thanks, Ben!
> >
> > In case of the last email content is hidden, I re-send the question again
> > here:
> >
> > If I set the action of in-band hidden flows to be output: OFPP_PORT_X
> with
> > X being the port number: 1, 2 or 3, etc,
> > which are defined in openflow-1.0.h. Does it make sense to direct all
> > in-band packet through the specified port X ?
> >
> > Ethan
> >
> > 蘇于倫  於 2017年4月19日 週三 上午1:02寫道：
> >
> > > Thanks Ben!
> > >
> > > Besides, if I set the action of in-band hidden flows to be
> > > output:OFPP_PORT_X
> > > with X is port number, 1, 2, 3, etc, which are defined in
> openflow-1.0.h,
> > > could it make sense to direct all control plane packets through the
> > > specific port X ?
> > >
> > > Ethan
> > >
> > > Ben Pfaff  於 2017年4月19日 週三 上午12:55寫道：
> > >
> > >> It's the MAC learning table.
> > >>
> > >> On Wed, Apr 19, 2017 at 12:00:22AM +0800, 蘇于倫 wrote:
> > >> > Hi Ben,
> > >> >
> > >> > I'd like to know what info does  ovs-appctl fdb/show 
> provide?
> > >> >
> > >> > Ethan
> > >> >
> > >> > 2017年4月18日 23:42，"Ben Pfaff" 寫道：
> > >> >
> > >> > > Maybe you want to look at the in-band control flow rules via
> > >> > > "bridge/dump-flows".  See ovs-vswitchd(8).
> > >> > >
> > >> > > On Tue, Apr 18, 2017 at 03:34:24PM +, 蘇于倫 wrote:
> > >> > > > Hi Ben,
> > >> > > >
> > >> > > > 1: eth0  addr:00:0c:29:15:f5:f6
> > >> > > > 2: eth1 addr:00:0c:29:15:f5:00
> > >> > > >
> > >> > > > Ethan
> > >> > > >
> > >> > > > Ben Pfaff  於 2017年4月18日 週二 下午11:28寫道：
> > >> > > >
> > >> > > > > On Tue, Apr 18, 2017 at 03:21:23PM +, 蘇于倫 wrote:
> > >> > > > > > I'd like to know if we can see which ports the OVS is using
> to
> > >> > > connect to
> > >> > > > > > controller in "in-band" mode?
> > >> > > > >
> > >> > > > > Whatever ports you configured?
> > >> > > > >
> > >> > >
> > >>
> > >
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Controller connection port

[蘇于倫]

Thanks, Ben!

In case of the last email content is hidden, I re-send the question again
here:

If I set the action of in-band hidden flows to be output: OFPP_PORT_X with
X being the port number: 1, 2 or 3, etc,
which are defined in openflow-1.0.h. Does it make sense to direct all
in-band packet through the specified port X ?

Ethan

蘇于倫  於 2017年4月19日 週三 上午1:02寫道：

> Thanks Ben!
>
> Besides, if I set the action of in-band hidden flows to be
> output:OFPP_PORT_X
> with X is port number, 1, 2, 3, etc, which are defined in openflow-1.0.h,
> could it make sense to direct all control plane packets through the
> specific port X ?
>
> Ethan
>
> Ben Pfaff  於 2017年4月19日 週三 上午12:55寫道：
>
>> It's the MAC learning table.
>>
>> On Wed, Apr 19, 2017 at 12:00:22AM +0800, 蘇于倫 wrote:
>> > Hi Ben,
>> >
>> > I'd like to know what info does  ovs-appctl fdb/show  provide?
>> >
>> > Ethan
>> >
>> > 2017年4月18日 23:42，"Ben Pfaff" 寫道：
>> >
>> > > Maybe you want to look at the in-band control flow rules via
>> > > "bridge/dump-flows".  See ovs-vswitchd(8).
>> > >
>> > > On Tue, Apr 18, 2017 at 03:34:24PM +, 蘇于倫 wrote:
>> > > > Hi Ben,
>> > > >
>> > > > 1: eth0  addr:00:0c:29:15:f5:f6
>> > > > 2: eth1 addr:00:0c:29:15:f5:00
>> > > >
>> > > > Ethan
>> > > >
>> > > > Ben Pfaff  於 2017年4月18日 週二 下午11:28寫道：
>> > > >
>> > > > > On Tue, Apr 18, 2017 at 03:21:23PM +, 蘇于倫 wrote:
>> > > > > > I'd like to know if we can see which ports the OVS is using to
>> > > connect to
>> > > > > > controller in "in-band" mode?
>> > > > >
>> > > > > Whatever ports you configured?
>> > > > >
>> > >
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Controller connection port

[Ben Pfaff]

One way, which may not be satisfactory, is to use "ovs-appctl
ofproto/trace" to simulate a packet from the switch to the controller.

On Tue, Apr 18, 2017 at 03:39:24PM +, 蘇于倫 wrote:
> Hi Farooq,
> 
> Thanks for the comments.
> 
> I use the command a lot. However, what I want to get is which ports the OVS
> is using for hidden flow packet.
> The actions of default hidden flows are NORMAL (ports) which do not provide
> this info.
> 
> If I got any misunderstanding, please kindly comment!
> 
> Thanks
> Ethan
> 
> Farooq Basha  於 2017年4月18日 週二 下午11:33寫道：
> 
> > Please check the ovs hidden flows (Which are programmed by controller in
> > in-band mode) using ovs-appctl bridge/dump-flows  command.It
> > should have the openflow flows with high priority (>65535) with tcp port
> > 6653 and also it has port info through which packets should sent/receive.
> >
> > On Tue, Apr 18, 2017 at 8:51 PM, 蘇于倫 
> > wrote:
> >
> >> Hi everyone,
> >>
> >> I'd like to know if we can see which ports the OVS is using to connect to
> >> controller in "in-band" mode?
> >>
> >> I  use ovs-appctl fdb/show , and get the following table
> >>
> >>  port  VLAN  MACAge
> >> 2 0  00:0c:29:30:04:484
> >> 1 0  00:0c:29:c2:d1:420
> >> 1 0  00:0c:29:15:f5:00 0
> >>
> >> Does it provide in-band control channel connection port info?
> >>
> >>
> >> Regards,
> >> Ethan
> >>
> >> ___
> >> discuss mailing list
> >> disc...@openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >>
> >>
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] match ethertype when packet with multiple vlan tags

[Ben Pfaff]

On Tue, Apr 18, 2017 at 10:29:50AM -0400, Eric Garver wrote:
> On Tue, Apr 18, 2017 at 12:17:17PM +0800, Dickens Yeh wrote:
> > Thanks for your response.
> > I know that if I have to match multiple vlan tags, it have to pop the outer
> > vlan.
> > But I think my question are not the matching vlan tags in multiple vlan, my
> > question is matching the first vlan tag and the correct ethertype that
> > OpenFlow Spec defined ( the ethertype after all vlan tags ), not the case
> > that match multiple vlan tags in a single flow entry.
> > 
> > For example, that packet header like
> > 0012 8100 00d0 8060 0010800060400010012c0a
> > 80202c0a80302
> > In the view of ethernet, the ethertype should be 8100, that's not a problem.
> > In the view of openflow spec match, the ethertype should be 0806 ( ARP ),
> > the ethertype match after vlan tags
> > In the view of OVS match, the etherype is 0806, the result is matching with
> > spec.
> > 
> > Then, if the packet header like
> > 0012 88a8 00c0 8100 00d0 8060
> > 0010800060400010012c0a80202c0a80302
> > In the view of ethernet, the ethertype should be 88a8, the same result with
> > one vlan tag.
> > In the view of openflow spec match, the ethertype should be 0806 ( ARP )
> > In the view of OVS match, the ethertype is 8100, not 0806.
> 
> This is true if vlan-limit == 1, which is the default.
> If vlan-limit > 1, then dl_type would be 0x0806. As I indicated earlier,
> vlan-limit is new with 802.1ad support.
> 
> > I think the result is strange, but I don't know that it's an issue or
> > something else.
> 
> Strange or not, it's this way because OVS used to only support a single
> VLAN tag. It didn't know how to keep looking for the "true" Ethertype.

It's also a security risk if OVS skips over VLAN tags and indicates the
innermost Ethertype, because it means that the controller has no way to
tell that it's forwarding a packet with additional VLANs that might have
arbitrary semantics to the receivers.  On the other hand, with a VLAN
Ethertype when the maximum number of VLANs is surpassed, the controller
can detect and drop such packets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Controller connection port

[蘇于倫]

Hi Farooq,

Thanks for the comments.

I use the command a lot. However, what I want to get is which ports the OVS
is using for hidden flow packet.
The actions of default hidden flows are NORMAL (ports) which do not provide
this info.

If I got any misunderstanding, please kindly comment!

Thanks
Ethan

Farooq Basha  於 2017年4月18日 週二 下午11:33寫道：

> Please check the ovs hidden flows (Which are programmed by controller in
> in-band mode) using ovs-appctl bridge/dump-flows  command.It
> should have the openflow flows with high priority (>65535) with tcp port
> 6653 and also it has port info through which packets should sent/receive.
>
> On Tue, Apr 18, 2017 at 8:51 PM, 蘇于倫 
> wrote:
>
>> Hi everyone,
>>
>> I'd like to know if we can see which ports the OVS is using to connect to
>> controller in "in-band" mode?
>>
>> I  use ovs-appctl fdb/show , and get the following table
>>
>>  port  VLAN  MACAge
>> 2 0  00:0c:29:30:04:484
>> 1 0  00:0c:29:c2:d1:420
>> 1 0  00:0c:29:15:f5:00 0
>>
>> Does it provide in-band control channel connection port info?
>>
>>
>> Regards,
>> Ethan
>>
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS Controller connection port

[蘇于倫]

Hi everyone,

I'd like to know if we can see which ports the OVS is using to connect to
controller in "in-band" mode?

I  use ovs-appctl fdb/show , and get the following table

 port  VLAN  MACAge
2 0  00:0c:29:30:04:484
1 0  00:0c:29:c2:d1:420
1 0  00:0c:29:15:f5:00 0

Does it provide in-band control channel connection port info?


Regards,
Ethan
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] match ethertype when packet with multiple vlan tags

[Eric Garver]

On Tue, Apr 18, 2017 at 12:22:56PM +0800, Dickens Yeh wrote:
> Yes, I use the master branch and set with vlan-limit=0.
> The line 362 says "e.g. a packet with more 802.1q headers will match
> Ethernet type 0x8100."

This applies if the number of VLAN tags exceeds the value of vlan-limit.
For example, vlan-limit == 2 and the frame has 3 VLAN tags then the
dl_type will be 0x8100 because OVS can only look at the first two tags.
Anything after that is considered payload.

> Is that means OVS will keep match 0x8100 that not the defined from OpenFlow
> spec or maybe will be fixed with maybe next version?

I'm not sure I understand what you're asking here. Hopefully my comment
above helps.

> 
> best wishes,
> Dickens Yeh
> 
> 
> 2017-04-17 22:51 GMT+08:00 Eric Garver :
> 
> > On Mon, Apr 17, 2017 at 01:26:37PM +0800, Dickens Yeh wrote:
> > > Hello,
> > > I have a problem with matching ethertype when the packet with vlan tags.
> > > My testing environment is Ubuntu 16 in vmware fusion, mininet 2.2.2rc1,
> > > openvswitch 2.7.90
> > >
> > > With these cases:
> > > case 1: packet with vlan=100,ethertype=arp
> > > case 2: packet with vlan=2000,vlan=100,ethertype=arp
> > >
> > > The result of cases:
> > > case 1 can be matched by vlan=100 and ethertype=arp fields in a flow
> > entry
> > > case 2 can be matched only by vlan=2000 and ethertype=0x8100 fields in a
> > > flow entry
> > >
> > > But I read some informations from OpenFlow Spec 1.1, that says about
> > "match
> > > ethertype after all vlan tags".
> > > Is the resulf of case 2 should be matched vlan=2000 and ethertype=arp?
> >
> > Until very recently openvswitch only supported a single VLAN tag.
> > Current master branch has support for 802.1ad/QinQ and can match the ARP
> > EtherType as you wish in case 2 above.
> >
> > To use it you'll have to build from master and set vlan-limit=2 or
> > vlan-limit=0.
> > See https://github.com/openvswitch/ovs/blob/master/
> > vswitchd/vswitch.xml#L362
> >
> > >
> > >
> > > Thanks for your reply.
> > >
> > > best wishes,
> > > Dickens Yeh
> >
> > > ___
> > > discuss mailing list
> > > disc...@openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
> >

> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] prioritizing latency-sensitive traffic

[O Mahony, Billy]

Hi Ben, Darrell,

It sounds like the general feeling is that any kind of tc pre-processing is not 
worth it and the existing egress queing/QoS facilities should suffice. 

Thanks for your comments.

/Billy



> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Thursday, April 13, 2017 7:47 PM
> To: O Mahony, Billy 
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] prioritizing latency-sensitive traffic
> 
> I don't know how much more OVS can contribute to this than it already does.
> By the time that OVS has classified a packet to the extent that is necessary 
> to
> determine that it should be handled with a high priority, OVS has already
> done most of the work that it does on a packet.  
[[BO'M]] I'm investigating how I could go about classifying packets before the 
main 
The work to transmit the
> packet is not part of OVS's job, it is the job of the driver, and at most OVS 
> can
> mark the packet with a priority or a queue.  OVS can already do that.  So the
> usual answer is that it's a matter of configuring QoS in the driver to do what
> the user wants.
> 
> On Mon, Apr 10, 2017 at 09:30:12AM +, O Mahony, Billy wrote:
> > Hi Everybody,
> >
> > I just wanted to reflag this discussion below about possible methods of
> how to prioritize certain types of traffic handled by OVS.
> >
> > By prioritize I mean either or both of:
> > a) 'priority' packets are sent to their destination port faster than
> > other packets
> > b) in an overloaded situation the switch drops non-prioritized packets
> rather than prioritized packets.
> >
> > Also just to be clear I am discussing kernel ovs here. Also I'm looking at
> doing this without writing new code - ie is it possible and if so how is it
> configured using existing OVS.
> >
> > Thanks again,
> > Billy.
> >
> > > -Original Message-
> > > From: ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-
> > > boun...@openvswitch.org] On Behalf Of O Mahony, Billy
> > > Sent: Friday, November 25, 2016 5:04 PM
> > > To: ovs-discuss@openvswitch.org
> > > Subject: [ovs-discuss] prioritizing latency-sensitive traffic
> > >
> > > Hi,
> > >
> > > I have been performing tests investigating latency profiles of
> > > low-bandwidth time-sensitive traffic when the system is busy with
> 'normal' traffic.
> > > Unsurprisingly the latency-sensitive traffic is affected by the
> > > normal traffic and has basically the same latency profile as the normal
> traffic.
> > >
> > > I would like to be able to perform prioritization of traffic as some
> > > protocols such as PTP would benefit greatly from having it's packets 'jump
> the queue'.
> > >
> > > From skimming the documentation it looks that ingress QoS offers
> > > only policing (rate-limiting). Is this actually the case or maybe
> > > I'm not looking in the right place?
> > >
> > > But if so, I am looking at some alternatives:
> > >
> > > a) create two separate egress ports and have PTP listen on one port,
> > > everything else listen on the other port and use normal forwarding
> > > rules to send PTP traffic incoming from eth0 to it's own port. Something
> like:
> > >
> > >  other apps  ptp_daemon
> > >   +   +
> > >   +   +
> > >if_norm if_ptp
> > >++
> > >||
> > >||
> > >   ++++
> > >   |  |
> > >   |ovs   |
> > >   |  |
> > >   +-++
> > > |
> > > +
> > >   eth0
> > >
> > > b) create prioritized queues on a port and use match and actions
> > > such as
> > > set_queue(queue) and enqueue(port, queue) on ingress traffic to
> > > forward the PTP traffic to the higher priority queue. However I
> > > think queue priority for this case only relates to which queue get
> > > to consume the bandwidth of the port first and not about changing
> > > the order in which the packets egress the port.
> > >
> > > c) Or perhaps I can re-use tc PRIO or CBQ qdiscs by passing all
> > > traffic to tc first before ovs?
> > >
> > >  other apps
> > >   |
> > >   |
> > >if_norm
> > >+
> > >|
> > >|
> > >   +--+
> > >   |  |
> > >   |ovs   |
> > >   |  |
> > >   +-++
> > > |
> > > |
> > > tc - if_ptp  ptp_daemon
> > > +
> > >   eth0
> > >
> > > Any thoughts, ideas or clarifications most welcome.
> > >
> > > Thanks,
> > > Billy.
> > >
> > > ___
> > > discuss mailing list
> > > disc...@openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss