crossbow discuss - Apr 2009 - b111: add-flow fails for some attributes

Hi,

Below command works ok on b105 but it fails on b111 on x86
# flowadm show-flow
FLOW        LINK        IPADDR                         PROTO  PORT    DSFLD
icmp        aggr1       --                             icmp   --      --

# flowadm add-flow -t -l aggr1 -a transport=tcp,local_port=22 local_ssh
flowadm: add flow failed: flow(s) with incompatible attributes exists


ps. any plans on implementing again remote_port? Any info why it was backed-out?

-- 
Robert Milkowski
http://milek.blogspot.com
-- 
This message posted from opensolaris.org

Hi, Robert:

On Mon, 20 Apr 2009, Robert Milkowski wrote:
> Hi,
>
> Below command works ok on b105 but it fails on b111 on x86
> # flowadm show-flow
> FLOW        LINK        IPADDR                         PROTO  PORT    DSFLD
> icmp        aggr1       --                             icmp   --      --
>
> # flowadm add-flow -t -l aggr1 -a transport=tcp,local_port=22 local_ssh
> flowadm: add flow failed: flow(s) with incompatible attributes exists
that looks like a bug, seems like if we have any protocol based flow,
a more specific flow (even on another transport) fails. I''ll confirm
this
and submit a bug if needed.

>
>
> ps. any plans on implementing again remote_port? Any info why it was
backed-out?
we will plan to include remote_port as an RFE.  Flows were simplified
before integrating in nevada with the intent of developing it as
we get more info. on how they will be used.

thanks,

-venu

>
> -- 
> Robert Milkowski
> http://milek.blogspot.com
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>

after playing a little bit with truss and dtrace I can see that it fails while
doing ioctl with EOPNOTSUPP which in turn will be translated into
DLADM_STATUS_FLOW_INCOMPATIBLE
(http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdladm/common/libdladm.c#dladm_errno2status).

ioctl fails in mac_flow_add()
Adn the only place it fails with above errno is:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/mac_flow.c#249
[...]
    262 	mask = flent->fe_flow_desc.fd_mask;
    263 	if ((mask & ft->ft_mask) == 0 || (mask & ~ft->ft_mask) !=
0)
    264 		return (EOPNOTSUPP);
[...]

It seems like b111 is before revision 9073:a5a4bb23741e has been integrated.


Now I don''t have a time now to investigate what these masks are about
but perhaps it will be helpful to nail down the bug (unless it is already
fixed).

-- 
Robert Milkowski
http://milek.blogspot.com
-- 
This message posted from opensolaris.org

after playing a little bit with truss and dtrace I can see that it fails while
doing ioctl with EOPNOTSUPP which in turn will be translated into
DLADM_STATUS_FLOW_INCOMPATIBLE
(http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdladm/common/libdladm.c#dladm_errno2status).

ioctl fails in mac_flow_add()
Adn the only place it fails with above errno is:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/mac_flow.c#249
[...]
    262 	mask = flent->fe_flow_desc.fd_mask;
    263 	if ((mask & ft->ft_mask) == 0 || (mask & ~ft->ft_mask) !=
0)
    264 		return (EOPNOTSUPP);
[...]

It seems like b111 is before revision 9073:a5a4bb23741e has been integrated.


Now I don''t have a time now to investigate what these masks are about
but perhaps it will be helpful to nail down the bug (unless it is already
fixed).

-- 
Robert Milkowski
http://milek.blogspot.com
-- 
This message posted from opensolaris.org

after playing a little bit with truss and dtrace I can see that it fails while
doing ioctl with EOPNOTSUPP which in turn will be translated into
DLADM_STATUS_FLOW_INCOMPATIBLE
(http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdladm/common/libdladm.c#dladm_errno2status).

ioctl fails in mac_flow_add()
Adn the only place it fails with above errno is:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/mac_flow.c#249
[...]
    262 	mask = flent->fe_flow_desc.fd_mask;
    263 	if ((mask & ft->ft_mask) == 0 || (mask & ~ft->ft_mask) !=
0)
    264 		return (EOPNOTSUPP);
[...]

It seems like b111 is before revision 9073:a5a4bb23741e has been integrated.


Now I don''t have a time now to investigate what these masks are about
but perhaps it will be helpful to nail down the bug (unless it is already
fixed).

-- 
Robert Milkowski
http://milek.blogspot.com
-- 
This message posted from opensolaris.org

Just a clarification (from an off-line follow on between Venu and Eric), 
this is what the flowadm(1m) stipulates:

     The following five types of combinations of  attributes  are
     supported:

       local_ip[/prefixlen]=address
       remote_ip[/prefixlen]=address
       transport={tcp|udp|sctp|icmp|icmpv6}
       transport={tcp|udp|sctp},local_port=port
       dsfield=val[:dsfield_mask]

     On  a  given  link,  the  combinations  above  are  mutually
     exclusive.  An attempt to create flows of different combina-
     tions will fail.

The presence of the icmp-based flow is the reason of the failure.
In this phase of Crossbow, this is working as designed.

Thanks,

    Kais.


On 04/20/09 10:44, venugopal iyer wrote:
>
> Hi, Robert:
>
> On Mon, 20 Apr 2009, Robert Milkowski wrote:
>
>> Hi,
>>
>> Below command works ok on b105 but it fails on b111 on x86
>> # flowadm show-flow
>> FLOW        LINK        IPADDR                         PROTO  PORT    
>> DSFLD
>> icmp        aggr1       --                             icmp   --     
--
>>
>> # flowadm add-flow -t -l aggr1 -a transport=tcp,local_port=22 local_ssh
>> flowadm: add flow failed: flow(s) with incompatible attributes exists
>
> that looks like a bug, seems like if we have any protocol based flow,
> a more specific flow (even on another transport) fails. I''ll
confirm this
> and submit a bug if needed.
>
>
>>
>>
>> ps. any plans on implementing again remote_port? Any info why it was 
>> backed-out?
>
> we will plan to include remote_port as an RFE.  Flows were simplified
> before integrating in nevada with the intent of developing it as
> we get more info. on how they will be used.
>
> thanks,
>
> -venu
>
>
>>
>> -- 
>> Robert Milkowski
>> http://milek.blogspot.com
>> --

Ahhh..... after removing icmp flow it works and I can''t add icmp flow
now as expected.

However that''s very limiting... for example I can''t mix
remote_ip with local_ip and local_port (and hopefully remote_port in a future).

In my example I would like to give icmp traffic and access to local ssh and
snmpd a priority, then get usage reports when the servers connects to remote
servers  over a specified port (remote_port, currently not implemented). I
can''t do it right now.

Are you planning on making it much more flexible?


-- 
Robert Milkowski
http://milek.blogspot.com
-- 
This message posted from opensolaris.org

On 04/21/09 03:49, Robert Milkowski wrote:
> Ahhh..... after removing icmp flow it works and I can''t add icmp
flow now as expected.
>
> However that''s very limiting... for example I can''t mix
remote_ip with local_ip and local_port (and hopefully remote_port in a future).
>
> In my example I would like to give icmp traffic and access to local ssh and
snmpd a priority, then get usage reports when the servers connects to remote
servers  over a specified port (remote_port, currently not implemented). I
can''t do it right now.
>
> Are you planning on making it much more flexible?
>   
yes we are. The next phase will include a much richer set of flow 
attributes and combination thereof.


Kais.
>
>