As a side node perfomance is gained from collapsing

ipfw -q add 100 divert natd ip from any to any in via wan0
ipfw -q add 1000 divert natd ip from any to any out via wan0

to

ipfw -q add 100 divert natd ip from any to any via wan0

In D23450#518558, @neel_neelc.org wrote:

Thanks for your feedback.

I'm thinking about switching the NAT port range to something like 2000-2999 instead of 2000 3000 for consistency with the rest of IPFW. Would this be okay?

I'm still not satisfied with the "upper bound", which is inconsistent between "config port range" and "matching port range" in the ipfw rule set. It does not allow to specify the highest port (but this is a minor issue).

@eugen_grosbein.net are your concerns handled?

Thank you. Somebody need to land this.

Checking for enabled dynamicrouting services.

Is there any framework for obtaining the PROVIDE of enabled services?

Rebase to r357716

Can you please mark all the comments as "Done", which are solved. Only the author of the patch can do this.

I wonder how it is possible to configure the whole range 65000 to 65535 as usable ports,

In D23586#517583, @eugen_grosbein.net wrote:

We already have "nat tablearg" feature for this task:

You do not have to follow my comments.
I just express my feelings, which may be wrong or misleading.
If your idea is different, please feel free to refuse the advice.

In D23586#517583, @eugen_grosbein.net wrote:

We already have "nat tablearg" feature for this task:

single rule

ipfw add nat tablearg ip from any to 'table(1)'

for each $k and $i

ipfw table 1 add 192.168.$k.$i $k

Have you tried measuring performance of such configuration? It uses RADIX tree instead of linear seach.

In D23450#516086, @lutz_donnerhacke.de wrote:

In D23450#515858, @neel_neelc.org wrote:

Also, may I please have your patch for NAT table lookup? It would work very well for this.

Yep, I'v to adapt it to CURRECT, the structure of accessing the "nat" component in ipfw was changed (which make it much easier to apply a different access scheme)

In D23450#515858, @neel_neelc.org wrote:

Thanks for clarifying. I'm still new to FreeBSD TCP/IP stack development.

In D23450#515797, @neel_neelc.org wrote:

In D23450#515778, @lutz_donnerhacke.de wrote:

Correct me, if I'm wrong, but how are packets dealiased if more than one instance is defined using this patch?

Packets are aliased and dealiased as they would without this patch, as this patch only impacts the selection of ports if port_alias is selected.

Correct me, if I'm wrong, but how are packets dealiased if more than one instance is defined using this patch?

In D23450#515678, @lutz_donnerhacke.de wrote:

I'd prefer an approach to limit the port range per source IP (e.g. "port_range 300" as an option to reserve 300 ports for this IP) and log this assignment. This allows to keep the NAT setup simple, while reducing the amount of logging for NAT.

To bring this up, you need a bunch of ipfw rules (one per customer) where you know the (internal) IP of the customer beforehand.

I wondered why there is no change in the man page necessary, but it was already mentioned.
I wondered why somebody would mention an option in the man page, but the code only covers the "read and show" part.
So this patch is to enable the functionality as described in the man page, correct?

There are no interactions with the other open review.

Please let me verify, that this change does not break D21968.

Of course, the change is straight forward, but can we please have some words in the man page explaining how the names of the flags match the correspondent names in libalias.

In D23091#506416, @markj wrote:

So this provides some basic validation, but it is not clear what assumptions libalias makes on input packets. Do we also need to verify the IP header checksum? For fragments, do we need to duplicate some of the validation implemented by ip_reass()?

In D23153#508180, @glebius wrote:

Sorry, that's my failure. The patch is wrong though. We should run all netgraph in epoch.

Sorry, I'm lost. What is the purpose of this flag?

Because setting a MAC is still possible, the older scripts will not fail with this patch.

I'd prefer an accept from somebody more involved.

The structure of the whole function bugs me.
I'd expect a large switch(ip->ip_v) with thee cases: v4, v6 and default.
In each of the cases, I'd expect a

In D23091#507505, @eugen_grosbein.net wrote:

If there is no known case leading to a panic, we should not scare users with manual. It's still bad wording IMO. If there is known vector that may lead to panic, another checks should be added to make sure panic does not happen.

Leave the man page untouched.

In D23091#507455, @eugen_grosbein.net wrote:

In D23091#507447, @lutz_donnerhacke.de wrote:

Add an explanation to the man page.

I don't think we should make a habit documenting kernel panics in NEGRAPH code. Such bugs must be fixed, not documented.

Add an explanation to the man page.

Fixed spacing style.

Checking available space before accessing it.

Run indent(1) on the source files.
Reduced comments from the boilerplate.
Changed hard coded ethertypes by global definitions introduced by D21846.

The diff https://reviews.freebsd.org/D21961?vs=63102&id=66348#toc does only contain two small lines.

Changed back to a self contained handing of the old ABI calls.
Thank you @bz for the idea to check for errors.

Allow common calls to the old ABI to fall though to the new one.
Fix generic error handling (go out on error).

The old ABI is different from the new one.
Fall through to the new ABI was an early (but wrong idea)

If going this way, I'd be more thinking of having an rc.d script that would verify
the presence of an enabled routing daemon and rely on that to disable redirects.

Is it possible to default the "redirect" settings to an "automatic mode" where redirects are disabled if a certain, hardcoded size of the routing table is crossed?

Thank you.

In D22733#497656, @kp wrote:

In D22733#497518, @lutz_donnerhacke.de wrote:

Reporting an "error too many tables" is useful for adding a new table.
It's wrong for deleting and misleading for obtaining statistics.

Good point. I'll see if I can improve the error message.

What happens, if the number is reduced below the number of currently existing tables?

Reporting an "error too many tables" is useful for adding a new table.
It's wrong for deleting and misleading for obtaining statistics.

In D20468#496199, @kevans wrote:

Speaking of locking, don't we need any in if_vether?

Likely, but I had failed to get anyone else to look at this and promptly lost interest because this isn't an area I work in often.

It look like duplicate work compared to ng_eiface and ng_bridge.
What are the benefits of this interface over the ng ones?

In D22447#495146, @bz wrote:

Thanks a lot for the feedback. let me know what you think about the suggestion to move the basic functionality into llatbl?

Okay

Okay from me.
Now you need to find some of the senior developers to approve and commit it.

I just tried to avoid extra work (updating of each llentry), that can be done in case when interface has tens or hundreds of addresses.

If copying the LL addr is happening every time a parent interface is added (bcopy) , why not schedule the update too unconditionally?
It will only happen on changing the parent interface anyway.