Hello,
this should be created as question, not as task
closing as invalid

@jeffbearer how about policy routing and telling Linux that traffic should only use local 169.254/16 source address if its destination is also on 169.254?

Linux is going to source traffic for an arbitrary service to the outgoing interface of the selected route. I don't know what facilities might be available to plumb into vyos the notion of binding specific services to a specific interface, (I'd suggest a loopback/dummy interface) and route internally. But the problem is that you wouldn't want this for every service, ie vpn etc. and this is where it gets hairy.

I'm not an expert but my understanding of the definition of 169.254/16 is that it's a "link local" address and shouldn't be used for "real traffic", e.g. AWS uses it to pass EC2 metadata through 169.254.169.254, or see https://tools.ietf.org/html/rfc3927 for how this network is defined.
So I think that the solution should more in the direction of somehow telling VyOS to prefer the local interface address over the 169.254 address.

I was curious about this so I added the 169.254 addresses of my vyos bgp link to my vpc route tables and security groups but I still could not get the traffic to pass. I'm guessing AWS is not allowing traffic from the BGP interface to route. Ideally you would want a way to source all traffic from a dummy interface. IMO

Reference for why and examples of how to add kernel flags.
http://people.binf.ku.dk/~hanne/b2evolution/blogs/index.php/2015/03/04/ixgbe-failed-to-load-because

Got it, I'm pretty sure that solution exist, Just need to spend more time on this.

Thanks but I can't use GRE or OVPN since the other side is AWS virtual gateway (more specifically, I use it as a Virtual CloudHub connecting offices and multiple VPC's).

I personally observed mixed reports regarding VTI in general, so just guessing that this should be polished still.
Expecting to see this on 1.2.x releases
Anyway, you can try GRE or even OVPN if it's possible

With "other" operation system it's impossible to add VMXNET3 interface(seems there are filters)
so Debian 6 solve this perfectly

I made a thing that'll generate for you the development VM I'm currently using: https://github.com/giandvd/vyos-dev-vm

Marking as solved, since it merged

marking this as solved, since it merged
@giandvd you can put something like resolve T98 and phabricator will pick it up

confirmed, works just fine of free esxi

I installed 1.2.0beta1 ... it shows the same problem.

We use vmxnet3 adapters

It's still the same on the latest beta.

@rpiola, i would like to recommend to test latest beta too, so we can investigate further with fix if it still persists
Thanks!

@higebu after tests it seems that better to use Debian 6 as OS for appliance.
Since for Other it locks some things in vsphere interface(and in vcloud director too)

What we need for certain, other than git and build-essential, assuming the base system is minimal install:

I've tested IPsec + Ip6Ip6, everything works flawlessly for two weeks now. I suggest, we remove the check.

First tests haven't shown obvious problems, everything seem's to work. I'll do some more testing.

@dmbaturin can you take a look and merge this patch ?

I already have a working patch for my own setup, I attached it:

Hello,
clustering feature is abandoned, and it's on system only for compatibility reasons
@dmbaturin can explain more about that situation.
Meanwhile we recommend use VRRP instead of clustering

Hello,
we considering a possibility to add DNS recursor,
however, for now, there is no ETA for that functionality.

@dmbaturin this should be not hard to implement, correct?

Looks like this simple patch is ready for production. Backing idea - quagga has route-map to filter routes, going to be installed from ospf into kernel table, but we had no way to install it in vyos config. This patch creates 'router ospf route-map NAME' vyos configuration command, which maps into 'ip protocol ospf route-map NAME' quagga configuration mode command. The development was discussed under Q26.

Do we even use this package?

@EwaldvanGeffen real setup now inactive, i will try to recreate similar setup

recap from irc: one fix would be to negate the vpn-subnet in the source part of your dnat rule.

Sorry, I just didn't see, the feature was there :O

Hello,
@afics what do you want to do?
Like a pointing some domain to exact nameservers? somedomain.local for active directory pointed to domain controllers?
If so, forwarder already can do that

@syncer OK, but consider that form and substance are not necessarily antithetical.

@mickvav nice concept and I like it.
I though that new logo will be adopted for 2.0
personally, for me it makes sense

First one is a nightmare...

Just a little bit of suggestion:

@dmbaturin your previous comment was unprofessional :)

I'm waiting for someone to say the word "unprofessional". ;)

Sure, but I don´t believe that we getting users via FB solely
Also, you are free to propose alternative vision, no problems with that
So all ideas are welcome

Yes, but VyOS is a serious matter and the first visual impact, it is important for those who do not know what it is.
Everyone would think of a toy or anything reliable :)

Guys, it's just FB cover, nothing more :)

Omg... Please, no anime... :)

Sorry. I don't like. For me is too infantile.

If this will be included, someone has to make deep testing of quagga vrf-related patchset. Looks like it's described here: http://permalink.gmane.org/gmane.network.quagga.devel/11770 but I'm not sure, whether it's included in upstream quagga or not.

I move this to wishlist, need to dig deeper about this particular cases with OVH/Online.net/Hetzner
they use this type of IP allocation and provision

@EwaldvanGeffen just wondering what will be the best option in terms of difficulty of implementation

I will look into it. I think it is feasible to add to 1.x, but we have to think about the cli. We have to treat the default VRF in a way, so it doesn't come in the way of users who don't want/need to use VRFs.

Some time ago @dmbaturin told me that it's pretty difficult to implement in 1.x
Just wondering if this should be added only to 2.x

@syncer https://github.com/higebu/vyos-build/releases/tag/1.2.0-higebu6