Re: ipfw named objejcts, table values and syntax change
19.08.2014 21:36, Alexander V. Chernikov пишет: On 19.08.2014 20:06, Dmitry Selivanov wrote: 19.08.2014 17:50, Alexander V. Chernikov пишет: On 15.08.2014 19:20, Alexander V. Chernikov wrote: On 15.08.2014 18:19, Dmitry Selivanov wrote: 15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require
Re: ipfw named objejcts, table values and syntax change
On 15.08.2014 19:20, Alexander V. Chernikov wrote: On 15.08.2014 18:19, Dmitry Selivanov wrote: 15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require additional pointers for each subsystem (and some additional management), (2) will definitely upset embedded guys
Re: ipfw named objejcts, table values and syntax change
On 19.08.2014 20:06, Dmitry Selivanov wrote: 19.08.2014 17:50, Alexander V. Chernikov пишет: On 15.08.2014 19:20, Alexander V. Chernikov wrote: On 15.08.2014 18:19, Dmitry Selivanov wrote: 15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require additional
Re: ipfw named objejcts, table values and syntax change
On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require additional pointers for each subsystem (and some additional management), (2) will definitely upset embedded guys and (3) is worse in terms of performance With this in mind, i think we should follow a similar approach for objects stored in tables, hence if an u32 value
Re: ipfw named objejcts, table values and syntax change
15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require additional pointers for each subsystem (and some additional management), (2) will definitely upset embedded guys and (3) is worse in terms of performance With this in mind, i think we should follow a similar approach for objects stored in tables,
Re: ipfw named objejcts, table values and syntax change
On 15.08.2014 18:19, Dmitry Selivanov wrote: 15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require additional pointers for each subsystem (and some additional management), (2) will definitely upset embedded guys and (3) is worse in terms of performance With this in
Re: ipfw named objejcts, table values and syntax change
04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require additional pointers for each subsystem (and some additional management), (2) will definitely upset embedded guys and (3) is worse in terms of performance With this in mind, i think we should follow a similar approach for objects stored in tables, hence if an u32 value was available in the past, it must be available also in
Re: ipfw named objejcts, table values and syntax change
On 02.08.2014 12:33, Alexander V. Chernikov wrote:
On 02.08.2014 10:33, Luigi Rizzo wrote:
On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov
melif...@freebsd.org mailto:melif...@freebsd.org wrote:
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw add allow ip from table(tl1) to any
ipfw add allow ip from any lookup dst-ip tb1
ipfw table if1 create type iface
ipfw add skipto tablearg ip from any to any via table(if1)
or even this:
ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80
ipfw add allow ip from any to any flow table(fl1)
all these changes fully preserve backward compatibility.
(actually tables needs now to be created before use and their type needs
to match with opcode used, but new ipfw(8) performs auto-creation
for cidr tables).
There is another thing I'm going to change and I'm not sure I can keep
the same compatibility level.
Table values, from one point of view, can be classified to the following
types:
- skipto argument
- fwd argument (*)
- link to another object (nat, pipe, queue)
- plain u32 (not bound to any object)
(divert/tee,netgraph,tag/utag,limit)
There are the following reasons why I think it is necessary to implement
explicit table values typing (like tables):
- Implementing fwd tablearg for IPv6 hosts requires indirection table
- Converting nat/pipe instance ids to names renders values unusable
- retiring old hack with storing saved pointer of found object/rule
inside rule w/o proper locking
- making faster skipto
i don't buy the idea that you need typed arguments
for all the cases above. Maybe the case that
may make sense is the fwd argument (and in the future
something else).
We already discussed, i think, the fact that now it
is legal to have references to non existing things
(skipto, pipes etc.) implemented as u32.
Removing that would break configurations.
It depends on actual implementation. This can be preserved by
auto-creating necessary objects in kernel and/or in userspace, so
we can (and should) avoid breaking in this particular way.
Can you please explain your vision on values another time?
As far as I understand, you're not against it in general, but the
details matter:
* IP address can be one of the types (it won't break much, and we can
simply skip that one for MFC)
* what about typing for nat/pipes ? we're not going to convert their ids
to names? (or maybe you can suggest other non-disruptive way?)
* everything else is type u32
Efficiency is not affected, even for skipto,
It depends on workload. While binary search is fast in terms of cpu, it
is may be not so fast in terms of memory (since each of the rule is
allocated by separate malloc() (and that is another thing which is worth
discussing)).
and while i agree that unprotected writes to the pointers
in rules should not happen, these pointers are changed
infrequently so a global read-mostly lock should be
sufficient to protect all changes to the rules.
cheers
luigi
So, as the result, table will have lookup key type (already done),
value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
additional restrictions (like inability to add non-existing nat instance
id).
This change will break (at least) scenarios where people are
using one table for both nat/pipe instances (and keep nat ids in sync
with pipe ones). For example:
ipfw table 1 add 10.0.10.0/24 http://10.0.10.0/24 110
ipfw table 1 add 10.0.20.0/24 http://10.0.20.0/24 120
ipfw add 100 nat tablearg from table(1) to any via vlanX in
..
ipfw add 500 pipe tablearg from table(1) to any via ix0 out
It looks like it is not so easy to bind values for given table to
different objects (or different tasks) (and lack of compatibility kills
hope for MFC).
Ideas?
___
freebsd-ipfw@freebsd.org mailto:freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to
freebsd-ipfw-unsubscr...@freebsd.org
mailto:freebsd-ipfw-unsubscr...@freebsd.org
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it mailto:ri...@iet.unipi.it .
Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
TEL +39-050-2211611 tel:%2B39-050-2211611 . via
Diotisalvi 2
Mobile +39-338-6809875 tel:%2B39-338-6809875 .
Re: ipfw named objejcts, table values and syntax change
On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. With this in mind, i think we should follow a similar approach for objects stored in tables, hence if an u32 value was available in the past, it must be available also in the new implementation. The issue with tables is that some convoluted configuration could use the same table to reference pipes _and_ rules _and_ perhaps other things represented as numbers (the former is not too strange, if i have a large configuration i might place sections at rules 12000, 13000, 14000... and
Re: ipfw named objejcts, table values and syntax change
On 04.08.2014 15:58, Luigi Rizzo wrote: On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote: On 02.08.2014 12:33, Alexander V. Chernikov wrote: On 02.08.2014 10:33, Luigi Rizzo wrote: On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov melif...@freebsd.org mailto:melif...@freebsd.org wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto ??i don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type u32 Correct, I am mostly concerned about the details, not on the general concept. To summarize the discussion Alexander and I had about converting identifiers from numbers to arbitrary strings (this is partly related to the values stored in tables, but I think we should have a coherent behaviour) 1. CURRENTLY ipfw uses numeric identifiers in a small range (16 bits or less) for rules, pipes, queues, tables, probably nat instances. 2. CURRENTLY, in all the above contexts, it is legal to reference a non existing object (rule, pipe, table names, etc.), and the kernel will do something reasonable, namely jump to the next rule, drop traffic for non existing pipes, and so on. 3. of course we want to preserve backward compatibility both for the ioctl interface, and for user configurations. 4. The in-kernel representation of identifiers is not visible to users, so we can use a numeric representation in the kernel for identifiers. Strings like 12345 are converted with atoi() or the like, whereas for other identifiers or numbers outside of the 2^16 range the kernel manages a translation table, allocating new numeric identifiers if a new string appears. This permits backward compatibility for old rulesets, and does not impact performance because the translation table is only used during rules additions or deletion. Yes. However this requires either holding either (1) 2 pointers (oldnew arrays), or (2) 65k+ index array, or (3) chained hash table. (1) would require additional pointers for each subsystem (and some additional management), (2) will definitely upset embedded guys and (3) is worse in terms of performance With this in mind, i think we should follow a similar approach for objects stored in tables, hence if an u32 value was available in the past, it must be available also in the new
Re: ipfw named objejcts, table values and syntax change
On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov
melif...@freebsd.org wrote:
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw add allow ip from table(tl1) to any
ipfw add allow ip from any lookup dst-ip tb1
ipfw table if1 create type iface
ipfw add skipto tablearg ip from any to any via table(if1)
or even this:
ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80
ipfw add allow ip from any to any flow table(fl1)
all these changes fully preserve backward compatibility.
(actually tables needs now to be created before use and their type needs
to match with opcode used, but new ipfw(8) performs auto-creation
for cidr tables).
There is another thing I'm going to change and I'm not sure I can keep
the same compatibility level.
Table values, from one point of view, can be classified to the following
types:
- skipto argument
- fwd argument (*)
- link to another object (nat, pipe, queue)
- plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit)
There are the following reasons why I think it is necessary to implement
explicit table values typing (like tables):
- Implementing fwd tablearg for IPv6 hosts requires indirection table
- Converting nat/pipe instance ids to names renders values unusable
- retiring old hack with storing saved pointer of found object/rule
inside rule w/o proper locking
- making faster skipto
i don't buy the idea that you need typed arguments
for all the cases above. Maybe the case that
may make sense is the fwd argument (and in the future
something else).
We already discussed, i think, the fact that now it
is legal to have references to non existing things
(skipto, pipes etc.) implemented as u32.
Removing that would break configurations.
Efficiency is not affected, even for skipto,
and while i agree that unprotected writes to the pointers
in rules should not happen, these pointers are changed
infrequently so a global read-mostly lock should be
sufficient to protect all changes to the rules.
cheers
luigi
So, as the result, table will have lookup key type (already done),
value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
additional restrictions (like inability to add non-existing nat instance
id).
This change will break (at least) scenarios where people are
using one table for both nat/pipe instances (and keep nat ids in sync
with pipe ones). For example:
ipfw table 1 add 10.0.10.0/24 110
ipfw table 1 add 10.0.20.0/24 120
ipfw add 100 nat tablearg from table(1) to any via vlanX in
..
ipfw add 500 pipe tablearg from table(1) to any via ix0 out
It looks like it is not so easy to bind values for given table to
different objects (or different tasks) (and lack of compatibility kills
hope for MFC).
Ideas?
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
TEL +39-050-2211611 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-+---
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: ipfw named objejcts, table values and syntax change
On 02.08.2014 10:33, Luigi Rizzo wrote:
On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov
melif...@freebsd.org mailto:melif...@freebsd.org wrote:
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw add allow ip from table(tl1) to any
ipfw add allow ip from any lookup dst-ip tb1
ipfw table if1 create type iface
ipfw add skipto tablearg ip from any to any via table(if1)
or even this:
ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80
ipfw add allow ip from any to any flow table(fl1)
all these changes fully preserve backward compatibility.
(actually tables needs now to be created before use and their type needs
to match with opcode used, but new ipfw(8) performs auto-creation
for cidr tables).
There is another thing I'm going to change and I'm not sure I can keep
the same compatibility level.
Table values, from one point of view, can be classified to the following
types:
- skipto argument
- fwd argument (*)
- link to another object (nat, pipe, queue)
- plain u32 (not bound to any object)
(divert/tee,netgraph,tag/utag,limit)
There are the following reasons why I think it is necessary to implement
explicit table values typing (like tables):
- Implementing fwd tablearg for IPv6 hosts requires indirection table
- Converting nat/pipe instance ids to names renders values unusable
- retiring old hack with storing saved pointer of found object/rule
inside rule w/o proper locking
- making faster skipto
i don't buy the idea that you need typed arguments
for all the cases above. Maybe the case that
may make sense is the fwd argument (and in the future
something else).
We already discussed, i think, the fact that now it
is legal to have references to non existing things
(skipto, pipes etc.) implemented as u32.
Removing that would break configurations.
It depends on actual implementation. This can be preserved by
auto-creating necessary objects in kernel and/or in userspace, so
we can (and should) avoid breaking in this particular way.
Efficiency is not affected, even for skipto,
It depends on workload. While binary search is fast in terms of cpu, it
is may be not so fast in terms of memory (since each of the rule is
allocated by separate malloc() (and that is another thing which is worth
discussing)).
and while i agree that unprotected writes to the pointers
in rules should not happen, these pointers are changed
infrequently so a global read-mostly lock should be
sufficient to protect all changes to the rules.
cheers
luigi
So, as the result, table will have lookup key type (already done),
value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
additional restrictions (like inability to add non-existing nat instance
id).
This change will break (at least) scenarios where people are
using one table for both nat/pipe instances (and keep nat ids in sync
with pipe ones). For example:
ipfw table 1 add 10.0.10.0/24 http://10.0.10.0/24 110
ipfw table 1 add 10.0.20.0/24 http://10.0.20.0/24 120
ipfw add 100 nat tablearg from table(1) to any via vlanX in
..
ipfw add 500 pipe tablearg from table(1) to any via ix0 out
It looks like it is not so easy to bind values for given table to
different objects (or different tasks) (and lack of compatibility kills
hope for MFC).
Ideas?
___
freebsd-ipfw@freebsd.org mailto:freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to
freebsd-ipfw-unsubscr...@freebsd.org
mailto:freebsd-ipfw-unsubscr...@freebsd.org
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it mailto:ri...@iet.unipi.it .
Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
TEL +39-050-2211611 tel:%2B39-050-2211611 . via
Diotisalvi 2
Mobile +39-338-6809875 tel:%2B39-338-6809875 . 56122
PISA (Italy)
-+---
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
ipfw named objejcts, table values and syntax change
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw add allow ip from table(tl1) to any
ipfw add allow ip from any lookup dst-ip tb1
ipfw table if1 create type iface
ipfw add skipto tablearg ip from any to any via table(if1)
or even this:
ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80
ipfw add allow ip from any to any flow table(fl1)
all these changes fully preserve backward compatibility.
(actually tables needs now to be created before use and their type needs
to match with opcode used, but new ipfw(8) performs auto-creation
for cidr tables).
There is another thing I'm going to change and I'm not sure I can keep
the same compatibility level.
Table values, from one point of view, can be classified to the following
types:
- skipto argument
- fwd argument (*)
- link to another object (nat, pipe, queue)
- plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit)
There are the following reasons why I think it is necessary to implement
explicit table values typing (like tables):
- Implementing fwd tablearg for IPv6 hosts requires indirection table
- Converting nat/pipe instance ids to names renders values unusable
- retiring old hack with storing saved pointer of found object/rule
inside rule w/o proper locking
- making faster skipto
So, as the result, table will have lookup key type (already done),
value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
additional restrictions (like inability to add non-existing nat instance
id).
This change will break (at least) scenarios where people are
using one table for both nat/pipe instances (and keep nat ids in sync
with pipe ones). For example:
ipfw table 1 add 10.0.10.0/24 110
ipfw table 1 add 10.0.20.0/24 120
ipfw add 100 nat tablearg from table(1) to any via vlanX in
..
ipfw add 500 pipe tablearg from table(1) to any via ix0 out
It looks like it is not so easy to bind values for given table to
different objects (or different tasks) (and lack of compatibility kills
hope for MFC).
Ideas?
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: ipfw named objejcts, table values and syntax change
On 8/2/14, 5:08 AM, Alexander V. Chernikov wrote:
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw add allow ip from table(tl1) to any
ipfw add allow ip from any lookup dst-ip tb1
ipfw table if1 create type iface
ipfw add skipto tablearg ip from any to any via table(if1)
or even this:
ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80
ipfw add allow ip from any to any flow table(fl1)
all these changes fully preserve backward compatibility.
(actually tables needs now to be created before use and their type needs
to match with opcode used, but new ipfw(8) performs auto-creation
for cidr tables).
There is another thing I'm going to change and I'm not sure I can keep
the same compatibility level.
Table values, from one point of view, can be classified to the following
types:
- skipto argument
- fwd argument (*)
- link to another object (nat, pipe, queue)
- plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit)
There are the following reasons why I think it is necessary to implement
explicit table values typing (like tables):
- Implementing fwd tablearg for IPv6 hosts requires indirection table
- Converting nat/pipe instance ids to names renders values unusable
- retiring old hack with storing saved pointer of found object/rule
inside rule w/o proper locking
- making faster skipto
So, as the result, table will have lookup key type (already done),
value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
additional restrictions (like inability to add non-existing nat instance
id).
This change will break (at least) scenarios where people are
using one table for both nat/pipe instances (and keep nat ids in sync
with pipe ones). For example:
ipfw table 1 add 10.0.10.0/24 110
ipfw table 1 add 10.0.20.0/24 120
ipfw add 100 nat tablearg from table(1) to any via vlanX in
..
ipfw add 500 pipe tablearg from table(1) to any via ix0 out
It looks like it is not so easy to bind values for given table to
different objects (or different tasks) (and lack of compatibility kills
hope for MFC).
I think this makes sense
I have myself been responsible for adding 'odd' usages to tables e.g.
fwd tablearg
and have thought myself that really we need to be able to specify
tables more specifically
so don't expect me to argue against this :-)
Ideas?
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
