Hi all,

Hi @babak and @c-po, have you tested snmp ipv6 bgp instance???
Please let me know any news about that.

Yep, let's get this feature back into VyOS !

I think we all will benefit from pluggable auth system,
all that remote system login sources (radius, tacacs+, active directory) must be easy (relatively) add if that required.

Thanks for your feedback. Maybe I should clarify the feature request a bit:

Thanks for this feature request. I'm not to happy having a cloud provider install some SSH keys onto my system. If you have to manage many VyOS machines, why not use Ansible?

Possibly http://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html#apt-pinning will do the trick. I will start a test build...

@beamerblvd While slightly tangential, I would like to point out that regardless of your opinion of "traditional" NAT, (single external IP, multiple internal IP) NPTv6 makes a LOT of sense for anyone that wants to host services like DNS or web (even just internally) but is on an ISP that doesn't offer static prefixes. It has no issues that I'm aware of past the slight complication of configuration for a network admin, everything good about IPv6 still works with it. (Like the privacy extensions)

@carl.byington It works for incoming response packets, but nothing on the outside can initiate connections as far as I'm aware. Hence, my webserver would be inaccessible.

@c-po Hi, don't cheer up too early, I was not able to tst it all together since VyOS 1.2.x would not build due to server problems for the past week. Certain test steps on Ubuntu LTS 16.04 on a PC-Engines apu3b4 board using a Compex WLE600VX card indicated several possible pitfalls like reg domain switching. And then, as you already indicated, there are some old packages to be replaced in Debian Jessie. Major testing and some developing still needs to be done before we can celebrate a "recipe" for our cake. That is where I hope for your help and offer mine, too :-)

So, one thing to note: Comcast doesn't give you a /64 at the very beginning (I didn't understand this fully at the time this was originally reported/discussed). It gives you a /128 (one address). You can then ask for a prefix of any size from a /64 to a /60, and it will give it to you. If you don't ask at all, it won't give you anything. If you ask for a prefix, but without a prefix length, it will give you a /64. (I'm not refuting anything said here; just making sure everyone understands how these are assigned.)

I don't have a setup to test this, but it seems that if it works at all for outgoing connections, it should also work for incoming connections. Suppose you have been assigned external::1111/64 as your ipv6 address, and you have an internal network running on internal::/64, with nptv6 converting from internal::/64 to external::/64. Now a machine on internal::1234 will appear to be external::1234, and your router will send the outgoing packets to the external gateway. But when the response packets come back, the ISP will need to do neighbor discovery to find your external::1234. If that works at all, it should also work for incoming connections.

@alainlamar thank you very much for providing such detailed information e.g. what is required inside the kernel configuration. This seems to be not a big deal to enable those.

I could reproduce the bug. This doesn't appear to be an easy fix though.

@carl.byington Works great for outgoing connections, but isn't sufficient for hosting services behind a VyOS router from what I understand, as it needs to request the prefix over DHCPv6-PD for my gateway to know to route incoming packets to it.

I've done pkg-release in that package to include the latest commits into debian changelog and update the package version (helium4 now).

Does "set nat nptv6" not work for you? You can configure your inside interface with a private /64 block, then prefix translate that to the /64 obtained set nat nptv6 rule 10 inside-prefix

@UnicronNL Just to make sure, the package included in helium now is also patched?

It seems this is a bug in FRR 3.0
https://github.com/FRRouting/frr/issues/509

I think it make sense to do subtask per some particular issue.
It will be easier to track
as @dmbaturin suggested, there will be a lot of work on cli

I am also unable to redistribute static into OSPF if metric is defined.

@afics @syncer done, will be in the next nightly build

@dmbaturin , why you reverted?

I'd also really like to have this back as I am heavily using it.

This did the trick. Just build a fresh ISO:

I have upgraded my "parallel" universe. It look like redistribute static does not work.

https://github.com/vyos/vyos-build/commit/e5259ccb17e93e110d1dcdeb98f4dc1b9d1df192
This seems to have done the trick thanks.

@UnicronNL maybe this will fix this issue:

I've upgraded from 1.1.7 to this alpha version.

Antti made some quick tests see diagram

I believe StrongSwan does support some version of the functionality. strongSwan ipsec.conf
It looks like fqdn is resolved everytime the conf file is checked. See Below

Our nightly builds ships wpasupplicant 2.3-1+deb8u4, according to https://www.debian.org/security/2017/dsa-3999 it's fixed in 2.3-1+deb8u5.

I just ran a test on http://dev.packages.vyos.net/tmp/vyos-1.2.0-alpha-frr-test.iso
OSPF now works as intended in this particular setup. The ABR now sends LS Update type 3 into core.

@syncer https://github.com/vyos/vyatta-cfg/pull/9

Using a self build ISO: VyOS 999.201710291829 I can confirm this.

@c-po is something that you can add?

will be not added in 1.1.8, instead in 1.2 it should be fine,
please test latest builds

implemented 11/2016, merged 04/2017
https://github.com/vyos/vyatta-cfg-system/commit/4a03838ea877a3a867b283ba85956795e769d563

Looks like fixed as no further reports provided

no feedback

think we need modify installer and ask on install ?

@UnicronNL think we need to implement this

no feedback for long time

no feedback

i think that not a case now

no feedback

Yes, marking as solved

no additional feedback, no additional reports on issue

This regression is fixed. @syncer should we resolve it?

Hi, it seems that is added and we can close this?

False positive as a previous command was failing.

Isn't it the scenario for which all those people in debian have used package manager for decades? Isn't it better to just update one package in installed system?

Fixed in https://github.com/vyos/vyatta-cfg-system/pull/65