IPV6 Neighbor Solicitation Not answered !?? => No IPV6 :(

johnpoz

@louis2 not saying in general your lacp/lagg isn't working - but take that out of the equation for the testing.

In your sniff where you show client doing Neighbor Solicitation - how did you sniff that exactly. Was that traffic correctly tagged?

louis2

@johnpoz

John,
I have been wondering long ago how to show vlan tags in wireshark. Still no idea :(

However it seems impossible that there is a problem with the vlan taggings, since the whole network is build with additional to the core switches small netgear managed switches connected via trunks.

Never the less, thinking about how to remove the laggs out of the equation, to keep it simple I could only imagine one thing.

shutting down one of the two sides from each lagg

That is what I did, and that did not change the situation.

louis2

@louis2

One other thing what I could do tomorrow, should not change any thing!, but you never know!
Is connecting the test NAS via a long cable directly to the 10G core switch (that is the place where it is intended to go in the future).

That will remove the inter-core switch link, the 1G-switch and the "room switches" out of the equation. It is just vlan of course, but since we are looking into strange things .... I could try

However if, that it is something for tomorrow

louis2

@louis2

By the way ...... IPV4 and IPV6 are both based on the same VLAN's and LAGGs and .... ipV4 is no problem

johnpoz

@louis2 said in IPV6 Neighbor Solicitation Not answered !?? => No IPV6 :(:

VLAN's and LAGGs and .... ipV4 is no problem

IPv4 doesn't use multicast to find its neighbors.. There are differences between how ipv4 and ipv6 works.. So such things are not always proof that something is working for both.

But I find it hard to believe its something wrong in pfsense in such a way that it would be common to just not answer a solicitation.. Or there would be lots of posts complaining its not working, and none of your IPv6 network would work, etc.

There is a piece of the puzzle missing that is for sure.. Kind of hard to solve a puzzle with pieces missing.

louis2

@johnpoz

I took an "extreme test measure" and placed an additional UTP-card in the router and defined two new vlans on that interface.

At the side of the TrueNAS server I used a spare UTP-connection to define the same two vlans.

I did connect them via a long UTP-cable ...... and I must admit a see different behavoir. It might be, ..... not sure because of "situation" holding times in the network, .... that the communication works this way.

Assuming that this temporarily setup really works (lets hope) it leaves two questions:

what is wrong with my network setup !?
why does it not work with FreeBSD/Linux but does work with windows !?

The first question is probably most interesting.

something wrong with the laggs ??
or the inter switch communication ??
or something else ??

johnpoz

@louis2 said in IPV6 Neighbor Solicitation Not answered !?? => No IPV6 :(:

why does it not work with FreeBSD/Linux but does work with windows !?

Your saying it works with a windows VM running on your truenas, but not bsd/linux vm? Is this windows box on the same vlan ad the bsd/linux vms?

Still missing puzzle pieces - LAGs can be tricky sometimes, it is possible for example to have a flood port in the lag, where broadcast and multicast use this specific port, etc.

At min that is a variable we are unsure of.. Your test of using a different path this not lagg for sure could be helpful in finding the missing puzzle pieces.

louis2

@johnpoz

No, I did not say it works with a windows VM(!) , I only mend to say that I did not notice ipv6 issues in relation with the TrueNAS core (FreebSD) and TrueNas scale (debian).

ping -6 www.google.com from my windows pc or windows server is simply working. The traffic is different the OS is different and their traffic is different and they are not vlan aware.

Of cause the traffic towards e.g. this windows machines is transported via the same vlans, swithes and laggs ..

BAD NEWS

I just detected that also with the direct connection, I still have the same issue. I do not know why it worked for a short time. I expect due to the fact that there has been a guery starting from the pfsense side first

Derelict

@louis2 It's pretty unlikely this is something in pfSense. Most of this functionality is handled by FreeBSD underneath. I also think it's pretty unlikely that basic IPv6 functionality is broken in FreeBSD.

I suggest you simplify your configuration as much as possible and be sure that a directly-connected laptop or something does not get the proper response. Preferably something that can packet capture, along with the IPv6 router port on pfSense.

Opening a bug report on the redmine should include steps to duplicate in as simple an environment as possible removing as many other potential causes as is feasible.

louis2

@derelict

At this moment in time I simply do not know why it is not working.

It could be a pfSense problem (or underlying FreeBSD) or
It could be a TrueNas problem in relation to vlans problem or
I make some may be stupid error
?

In first instants, I did verdict TrueNas-core (FeeBsd) most, however after installing TrueNas-scale (Debian), I was thinking more in the direction of pfSense. @johnpoz did raise the idea that it was perhaps the network in between.

To throw the network out of the equation, I did create a two vlan trunk via a direct UTP-cable between pfSense and TrueNas

That did not solve then problem.

At the TrueNas side I use fixed addresses, and at the pfSense side I started with NO pfsense and no RA. Since that did not work, I also experimented with DHCP and RA settings on the pfSense side.
Nothing helped, at this moment I have DHCP ON and RA router only (for what ever reason it is not working ...)

I can and will do a test tomorrow replacing TrueNas with windows, however that is not the same situation.

Apart from that test, there are a couple of less attractive options:

looking into detailed specs and compare them with the traces
build an other router
build a system more or less compatible with the truenas situation
waiting for TrueNas ^13^ and/or pfSense ^13^

Sleeping a couple of nights hoping for a brilliant Idea / some "a ha"

It might be that I choose for the latter

louis2

@louis2

I just did a small test. I did connect a small managed switch at the end of the UTP-cable which converted the tagged vlans towards untagged UTP-ports.
That way I could connect a normal windows PC.

As expected ..... that worked ..... in fact a test I had done before in a variant via the network switches. I did make some captures.

Those captures are probably not much different from captures I can make on the normal PC-vlan,

In fact this test does not prove much more than:

that there is no problem when using windows
that TrueNAS configured with jails and vlans does behave at least different, not unlikely but not jet proven! wrong.
Can be a principal truenas "middle-ware" problem and be a configuration issue. It least it occurs in both the FreeBSD and the Debian version.
(note that I was looking into the problem with a very experienced truenas user, who did not understand the problem as well).

So it seems to be that I have to deep dive into the bits and bytes ......

Where ...... it would have been so nice ....... if it had just worked

Derelict

@louis2 TrueNAS and jail VLAN networking is confusing to me. I never figured it out and just bridge my jails to the main network. Not that there isn't a way or that it somehow can be made to work. I just got tired of messing with it and punted. That was a couple years ago and I never revisited it.

Seems you have proven it's not pfSense though.