Is there an argument against just using cloud-init for the AMI?

An AMI updated by hand was submitted to Amazon for testing.

The proposed "maximum-paths" looks to set the maximum number of paths for equal cost routing and not limit the long AS path that causes the noted log entry. I used the following in a production network to work around the issue:

1. set protocols bgp 262766 maximum-paths ebgp 75

i still confuse how to patch it, please explain more. thanks

No, I got the patch for this patch, how should I proceed? I have some sessions with this problem.

Works in nightly built but now Netflow is broken in the nightly build :(

@UnicronNL or better add this to installer part

@dmbaturin now as we have bugzilla back, can you check this one ?

@dmbaturin can we update keepalived to fresh version in 1.1.x
or should we drop mark this as wontfix in 1.1.x?

Certainly not fixed in 1.1.x - but I'll see what I can do with it. 1.2 has such completely different handling that I couldn't even guess what it does. I'll have to work out a lab to reproduce it. Might get to it at the weekend.

@c-po wondering if this something that was fixed by you previously?

Got no follow up,
closing this

Here is patch:
diff --git a/bgpd/bgp_aspath.c b/bgpd/bgp_aspath.c

Comment by @beamerblvd on 2016-01-24:

We will not address this in 1.1.x
please retest on 1.2. and reopen ticket or create new one

I will advise to try latest rolling release from here
dev.packages.vyos.net/iso/current/amd64/

I see your point, but generally, you want to use uRPF by receiving a BGP feed with prefixes to block, with a specific next hop, so you need to statically route this nexthop to blackhole, so all the prefixes are blackholed and uRPF can kick in.

As most of network internals inferred from Linux kernel, there is no direct way to achieve what you want.
You messing two different things as uRPF and recursive lookup. First works fine, second impossible.

Does that mean uRPF is useless in VyOS, or is there a workaround I failed to find ?

@dponzone check this thread, https://superuser.com/questions/1229275/linux-static-recursive-routes-not-supported
it will not work in a way you willing to have

The version and the relevant lines of configuration are at the beginning.
Am I missing something ?

No version
No config
You have some task to accomplish and it not works as you need.

I am sorry, this is bug, I hardly see why it should be a support question.

new one, not sure if you can edit T403

Do you want me to add it to T403 or make a new ticket?

Can you submit bug report please

This patch should also be included in 1.2.x, as i have seem similar behaviour with nightly builds.

l# dpkg -l | grep snmpd
ii snmpd 5.7.2+vyos1+helium2 SNMP (Simple Network Management Protocol) agents

Please check with latest night build
Not likely that we will spend time on this in 1.1. x series

dpkg -l | grep snmpd and it says 5.7.2+vyos1+helium2 Which is what is already on /tmp/khagen/snmp .. I downloaded the packages and installed them but same issue with timeouts and high load on the system. 82599EB

I can verify that it now also boots on OVH.net VPS.

In T17#5090, @audreez wrote:

can someone tell me how to properly apply this patch? thank you!

@UnicronNL @syncer Using the latest beta ISO I can happily report everything seems to install + boot just fine!

@UnicronNL applied changes in both 1.1.x and 1.2.x

Maybe this is the reason why we also can't boot a VyOS instance on VPSs rentet from OVH.net

@UnicronNL please add this when you have time

Ok I will submit a feature request.

There is no plans to use this packages in VyOS
This will not be fixed in 1.1.x

No such plans,
but you may want to submit this as feature request to 1.2.x project instead
If you can also add references for this limitations and any additional info
this will helps a lot

@syncer thanks!.

@hiroyuki-sato maybe 1.2 is not affected with that issue,
i will check with @dmbaturin

@syncer Sorry late reply.

this will be not addressed in 1.1.x

Invalid configuration

@UnicronNL can this be added with impact?

Should we investigate this on 1.2 or drop this?

There was no interest on this, closing as invalid

No additional information was provided

@jhendryUK is this also affects 1.2.x ?

Looks simple, moving to backlog for 1.1.8

Marking this as invalid
info provided not sufficient