In Q122, @aopdal wrote:

With prefix delegation you have a static prefix on your inside, but the "wan" interface on the router is using DHCP.

With prefix delegation you have a static prefix on your inside, but the "wan" interface on the router is using DHCP.

In Q122, @aopdal wrote:

Are your addresses managed from Comcast using prefix delegation?

Without routing you probably can't get it to work. Are your addresses managed from Comcast using prefix delegation?

In Q122, @aopdal wrote:

@beamerblvd have you added routes for your vif 100,200 and 900 in your "COMCAST BUSINESS IP GATEWAY"?

@beamerblvd have you added routes for your vif 100,200 and 900 in your "COMCAST BUSINESS IP GATEWAY"?

So the attempts with /56 and /60 were part of my hundreds of different combinations/attempts to get this to work. I have one /56 assigned to me (2603:xxxx:xxxx:8700::/56) with one gateway assigned to me (2603:xxxx:xxxx:8700:7454:7dff:feb1:d391). Skipping the WAN for just a second because I believe(d) it to need different configuration, I expected to be able to break that /56 up into /64s and use them like so:

I am willing to give some advice but it's an issue to understand your infrastructure based on a very fuzzy set of details.
The basic rule of thumb that I can think of is that you cannot assign ip addresses with the same or overlapping prefix on two interfaces and route between them.
I do not know if the VyOS kernel supports IPV6 NAT feature but this should be a very last resort for specific scenarios.
If you need some examples on how IPv6 prefixes are being used you can try to peek at some IPv6 brokers such as Hurricane Electric.
They give you a very specific IPv6 address and prefix for the WAN side with a specific default route,
Then they give you a different prefix to assign the internal network which is behind the main gateway.
Is your setup different then what HE offers?

Perhaps you could make a drawing of what you try to get working? With proper interface naming etc. eth0 - wan, eth1 - dmz, eth2 - lan or whatever you are using. It makes it easier to understand what you try to do. And for the interfaces why do you want to use the /60?

In Q122, @aopdal wrote:

Maybe this is relevant? https://phabricator.vyos.net/T421

Maybe this is relevant? https://phabricator.vyos.net/T421

So, I ended up handling my IPv4 addresses using 1:1 NAT. It works, and I don't love it, but I think it's the best it's going to get with Comcast's clunky static IP infrastructure. But I'm having no luck with IPv6, and could really use some help with someone who understand's static IPv6 and VyOS a little better. I have a static IPv6 prefix, and I need to statically assign some of those to public-facing servers behind my firewall/router, but it's like pulling teeth from a rhinoceros.

I've found memory leak bug in Cstore perl binding (perlxs).
This binding is a part of vyatta-cfg.

That is fine, maybe with exception for some nasty vulnerabilities, however we also not disappear
just handy to have someone dedicated to wireless (almost separate world)
Thank you!

@syncer thanks for the offer :)

@c-po i think this was fixed by @dmbaturin
marking as solved, if not, reopen

@alainlamar by any chance you want to be maintainer of wireless subsystem ? :)
It looks like you both have knowledge and real life use case and that make it whole easier

I am seeing similar messages in 1.1.8.

The downloads.vyos.io is now using mandatory HTTPS. On the dev.packages.vyos.net, HTTPS is optional. To declare this closed, we need someone to independently verify that ISO build works with HTTPS for them.

@c-po thanks for pointing me to the interface definitions!

@alainlamar nice work digging!

I found an example file in vyatta-lldp:

I found an example XML tag config file in vyatta-lldp:

I'm using ntop-ng + nprobe.

@syncer tools added to base image. This would be perfect for a vyos-1x op mode command. Unfortunately I was not able to build a working template with the relax-ng templates (lack of xml/relax-ng) knowledge. @dmbaturin maybe you can help?

@squeeby which sflow collector do you use? Is there one you can recommend?

Rewrote the scripts using vyos-1x and Python. This is now functioning on my routers.

Working again

I like the way it works now, but honestly as long as I can get to both the CLI and the OS shell somehow (with a command), I don't really care which is the default.

Merged into vyatta-netflow package and will be included in tonights build.

Looks good!

Ok, next try: https://www.mybll.net/vyatta-netflow_ver02_all.deb

This appears to operate as expected.

Could you alter the file manually to get a working state and pass it to me by e.g. pasting it here or a https://pastebin.com/ link? Then I could regenerate a package for testing. This would help me a lot as I do not have any flow collector.

So by reverting, the file /opt/vyatta/sbin/vyatta-netflow.pl contains:

328 sub acct_add_nflog_target {
329     my ($intf) = @_;
330
331     my ($table_chain) = acct_get_table_chain();
332     while (my ($chain, $table) = each(%$table_chain)) {
333         my $cmd = "iptables -t $table -I $chain 1 -i $intf -j NFLOG" ." --nflog-group 2";
334         if (defined $nflog_range) {
335             $cmd .= " --nflog-range $nflog_range";
336         }
337         if (defined $nflog_threshold) {
338             $cmd .= " --nflog-threshold $nflog_threshold";
339         }
340         my $ret = system($cmd);
341         if ($ret >> 8) {
342             die "Error: [$cmd] failed - $?\n";
343         }
344     }
345 }

You can revert by switching back to the official VyOS package.

Do you know how I can restore the previous version so I can see if it was this package that changed it?

Strange. I only changed /opt/vyatta/sbin/vyatta-netflow.pl to your recommendation.

I applied your patch but now iptables has reverted to using the ULOG target instead of NFLOG:

squeeb@gw1# commit
[ system flow-accounting interface eth2 ]
iptables: No chain/target/match by that name.
Error: [iptables -t raw -I VYATTA_CT_PREROUTING_HOOK 1 -i eth2 -j ULOG --ulog-nlgroup 2 --ulog-cprange 64 --ulog-qthreshold 10] failed - 256

@squeeby do you mind verifying the following package containing your fix:

Changing the following lines to the excerpt below in /opt/vyatta/sbin/vyatta-netflow.pl seems to work: