Your issue was caused by the generic permit (no match clause) attached to rule 20 of the default-import route-map. Route-maps usually act like ACL's and stop processing after the first match.
In Cisco-land you can use the continue keyword to continue evaluating the route-map instead of exiting at the first match. I wasn't able to find VyOS documentation ...
You configured a next-hop which isn't directly connected. A next-hop needs to be directly connected to be valid, so you should set the next-hop to a router which can be reached directly, at this moment your router does not know how to reach 10.121.191.254.
If the providers can filter their updates for you, then that's fewer prefixes to be sent over your links, and fewer for you to process.
A common technique is for providers to send you their AS and directly connected customer AS's, in addition to a default route. For AS's that are farther away, it may not matter which provider you use to get there.
If you are specifically looking to speed convergence or lower CPU usage, then asking your providers if they offer a customers+peers+default route option would be the simple solution.
If your full-table convergence time/CPU load is acceptable, configuring an as-path-list to limit the number of prefixes you use by AS-Path count provides you more flexibility ...
A router know the network in which it has an interface connected, so it doesn't need a route for those.
It need a route to reach remote networks. So you must tell to:
router-1 where are the networks 10.10.20.0/24 and 10.10.30.0/24
router-2 where are the networks 10.10.10.0/24 and 10.10.30.0/24
router-3 where are the networks 10.10.10.0/24 and 10.10.20.0/24
VyOs is linux-based, and like Squid, use iptables, so yes you can have exactly the same result.
You can log the traffic using a "log" statement in a firewall rule.
Basically if you accept all traffic then this will do the job:
set firewall name log-all rule 1 action permit
set firewall name log-all rule 1 log enable
set interfaces ethernet eth0 ...
As VyOS is inside aws it will always have nat from your device to internet. Then you must allow udp port 4500 because all IPsec connection will happen on udp 4500 when the device is behind a nat.
For this connection you need protocols 50, 51 (ah and esp) and udp 500 and 4500.
That’s why it worked when you opened everything. How is it going? The VyOS is ...
Following up to myself, we discovered that the AWS security policy had an effect here.
When we were seeing the weird "disconnect after 10 minutes" issue, the security policy was set to only allow inbound UDP on port 500 (whitelisted to the peer).
We changed the policy to allow all inbound traffic (on all ports) from the peer and the problem seems to have ...
It would be a NAT destination rule like
Nat destination rule 70
inbound interface eth0 *change the interface by yours*
I never test a destination rule that translate to another IP in the same network but it should work.
I wonder what lead you to such a ...
I would suggest you to accept a full BGP feed from your providers since one day or another you might need to access a route which is a /24 prefix and announced by only one of your neighbours.
If you just need to insure you have a full visibility of the 400k routes of the Internet here is a personal receipe I would try to reduce your router convergence time.