Could you please consider avoiding putting the diffs without the context next time?

In D22877#511064, @neel_neelc.org wrote:

Nevermind, I think I'll skip the tests if this can be committed anyways.

UPDATE: Maybe I'll try writing tests.

UPDATE 2: Actually, I'll skip it.

The problem is that my interface name may not be yours when plugging into ipfw. There may be inactive NICs, or NICs that are LAN-only. And I can't assume a fixed IP address either.

Yes, that's a common problem for these kind of tests. The typical solution used is (a) - using virtual interfaces such as epair /w VNET and (b) - using IPv4 documentation prefixes. This makes it easy to setup & teardown a testing environment.

I'll commit this change, however I highly encourage you on trying to write the tests for this. I did a bunch of similar tests yesterday: D23316.

For instance, my desktop uses Realtek NICs while my home server has Broadcom. You may have Intel or Atheros NICs.

So I'll skip writing tests.

That's a bad one to write as a comment! :-)

This change got reviewed and committed in D23047 and D23075.
Closing.

Sure, will do.

Thank you!

Also, do you think it would be possible to write some auto-test with atf-sh, testing this functionality?

It may be possible, but I don't think it's too trivial. You will have to emulate clients. Those can be done with Jails, or loopback interfaces.

Testing from Jails may be a slight bit harder, as you would have to create and tear down the Jails, and loopback interfaces mean the client needs to be directed to use the loopback NAT instead of the default NIC.

In fact, we already have most of the heavy-lifting done, with vnet wrappers & epair.
netinet6/exthdr.sh can be a good example.
I spent 30 minutes today to add an IPv4 redirect test here: D23075.

Fix forgotten variable declaration in expire_callout().

Add redirect test for IPv4.
Add a bit more wording on host/network redirects.

Committed as r309257.

Dropping this revision in favour of a larger upcoming change.

Update review to address comments.

LGTM. Thank you for submitting the patch!

Add forgotten tests.

Update the diff to reflect the committed pre-requisites.

In D23047#506342, @bz wrote:

Thank you so much for splitting this out. It really helps a lot! спасибо большой!

Thank you for reviewing this!

I assume this will not be MFCed due to KPI change?

Well, actually I thought of MFC'ing the version which would keep dom_rtattach() and other functions the same, while filling in rib_family and rib_fibnum directly in the vnet_route_init() after call to the dom_rtattach().
Do you have any concerns about this?

In D22988#505110, @melifaro wrote:

In D22988#504244, @bz wrote:

In D22988#504235, @melifaro wrote:

Just to be sure we're on the same page and I understand it correctly:
(a) - review1 means adding rib_fibnum, rib_family, rib_vnet to struct rib_head, along with changes in dom_rtattach(), rt_table_init() and so on, while
(b) - review2 is the same review w/o these changes, right?

da!

Raised D23047 for the former.

Raised D23075 for the latter. However, diffs w/o context are a bit harder to review.

Wrong commit was used to generate this revision.

Use internal __containerof() macro.

In D22988#504244, @bz wrote:

In D22988#504235, @melifaro wrote:

Just to be sure we're on the same page and I understand it correctly:
(a) - review1 means adding rib_fibnum, rib_family, rib_vnet to struct rib_head, along with changes in dom_rtattach(), rt_table_init() and so on, while
(b) - review2 is the same review w/o these changes, right?

da!

Raised D23047 for the former.

It would make the change history much more clear and also make it easier to review things.

Sure. Would be happy to do it.

PS: I am happy some of the FIB KPI gets cleaned up again, i.e. in6_rtredirect() going away. I hated adding them based on the IPv4 model when I did the initial IPv6 FIB work.

More changes will come soon :-)

:-)

Remove forgotten fields from rib_head.

In D22988#504231, @bz wrote:

I have a very annoying question: how much extra work would it be to split this up into: (a) adding rib_fibnum, rib_family and rib_vnet fields and changing the KPI for them by adding them to the current calls and then (b) adding the new functionality (and changing the support function logic beyond just passing the extra fields around)?

Just to be sure we're on the same page and I understand it correctly:
(a) - review1 means adding rib_fibnum, rib_family, rib_vnet to struct rib_head, along with changes in dom_rtattach(), rt_table_init() and so on, while
(b) - review2 is the same review w/o these changes, right?

In D22988#503966, @lutz_donnerhacke.de wrote:

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?

Normally the admin can not know all implementation details on each sysctl setting. So unless the setting was not modified by hand, the system is expected to choose the "best" path for the workload. Traversing the large routing table every 10 minutes causes a performance glitch which is very hard to find.

Add python code to generate IPv6 redirect.

Remove unrelevant changes, add forgotten license header.

Missing rtedirect.py is here. Phabricator refuses to add python files to the diff due to the lack of pep8 binary installed on phabric server..

Add ND redirect test, fix panic in redirect handling code.

Add tests for route expiration.

Add forgotten route_temporal.c

Not required anymore.

Any chance you have some dtrace / kgdb scripts verifying refcounting that can be added to the test suite?

In D22865#500605, @ae wrote:

However, someone in the mail list recently complained that we have not a method for route expiring, probably we can rework this code to implement such feature.

Yes, proper route expiration in AF-independent way is on my todo list.
Not sure if there are any reusable pieces in the current code..

Add forgotten kern_jail to the diff.

Update tests descriptions.

Update default mac address.