BGP route re-distribution

Hello, I have VyOS connected to multiple tunnel endpoints. Each peer is advertising a route. Is it possible for VyOS to redistribute the bgp routes?

Peer1 -> VyOS (received-route:
Peer2 -> VyOS (received-route:
VyOS is on and advertising its network

I understand this can be done by using blackhole. But that makes the advertised route permanent.

If tunnel1 (Peer1 -> VyOS) goes down, I don’t want to be advertised to Peer2.


Why dont you use just OSPF? (Or please post some details about your “tunnels”)

Regarding BGP, you specify Null route on your advertising router so route exists in routing table, eg.

Conf Peer 1 → route → null
→ bgp network
Conf Peer 2 → route → null
→ bgp network
Vyos → route → null
→ bgp network

And then configure iBGP peers in full mesh (guessing all are in same AS), eg
Peer1 ↔ Peer2
Peer1 ↔ Vyos
Peer2 ↔ Vyos

and off you go.

However If you are using GRE@IPsec tunnels (or VTI), I reccomend using OSPF (just easier to configure)…

Can you post your BGP config?

show configuration | commands | grep ‘protocols bgp’

Billy, Carl, thanks for your response. For some reason, I did not get email notifications. Must have forgot to subscribe.

Billy, I cannot do OSPF, GRE etc. All of these are in Amazon VPC. One end of the tunnels are Amazon VPC VPN’s which I don’t have control over.

Carl, I am attaching my configurations along with a picture to make this clear.

From the attached configuration, you can see that each VyOS has 4 tunnels. 2 tunnels are used for each remote region. VyOS in the hub region advertises a broader subnet to all the spoke regions.

What I am trying to figure out is, if the BGP routes learned from one tunnel can be redistributed to other tunnels?


All your neighbors are in AS7224. If you learn a route on one tunnel, its bgp path (as seen on your vyos) will start with 65000 7224. If one of the other neighbors accepted that route, the path would then start with 7224 65000 7224.

I don’t think BGP will even try to redistribute such a route - as7224 is presumed to already know it.

Thanks Carl. Unfortunately that AS # (7224) is from Amazon side and I don’t have any control over it. So I guess, I am out of luck.

Is it possible to invoke custom scripts for the following states:

IPSEC tunnel down
IPSEC tunnel up


BGP route added
BGP route removed

If yes, I could write some scripts to add/remove blackhole routes

Can you do ebgp-multihop to a bgp router on the other end of the tunnel? If the tunnel is up you talk bgp and exchange routing prefixes. When the tunnel goes down, the announcements go away and the routes disappear.

Carl, if I configure multihop, what should the update-source be set to? Loopback?

Actually, those configuration files are for a old setup. I double checked, and it looks like the AS # are different for different regions.

neighbor X.Y.Z.49
    remote-as 7224
neighbor X.Y.Z.53
    remote-as 7224
neighbor X.Y.Z.1
    remote-as 7225
neighbor X.Y.Z.5
    remote-as 7225

Would it help, if the AS # are like above?


update-source should be set to the ip on your end of the tunnel, which is the same address that the far end should use for neighbor. The far end sets update-source to their end of the tunnel, which matches your neighbor address. I am confused about these tunnels. Are both ends of those tunnels terminating on your vyos devices?

Yes, in that case, your vyos should advertise into 7225 routes that it learns from 7224. Debug that with:

show ip bgp neighbor IP4ADDR advertised-routes
show ip bgp neighbor IP4ADDR received-routes

Yes, Amazon VPC VPN has two tunnels each. They use it for high availability on their side. If they need to take one tunnel down for maintenance etc.

Ah, some reading at and I think I see the problem. As I understand it, you have two amazon vpc clouds in different regions, and a customer gateway (vyos) with 4 tunnels, two into each vpc.

However, the internal addresses used inside each vpc (and routes to those networks given to you via bgp from amazon over the tunnels) are probably duplicated inside other folks amazon vpcs. Amazon almost surely won’t accept a route into 7224 that originated in 7225.

Are you trying to get machines inside vpc1 to talk to machines inside vpc2? Even if amazon did accept such routes from you, all the traffic between your machines in those two vpcs would flow thru your vyos - essentially you would be providing transit between those two vpcs. Is that actually what you are trying to achieve? Amazon might have some mechanism to provide connectivity between those two regions that would be more efficient than piping it all thru your vyos.

Cool. ebgp-multihop with update-source works. Thanks a lot Carl.

Sorry, did not see your post. Yes, I am trying to connect multiple Amazon regions using VyOS using a hub-spoke model.

Region1 -> HubRegion (VyOS) <- Region2 …

The problem I am trying to solve is out-bound traffic high availability. Amazon unfortunately does not provide a very efficient solution for cross connecting regions.

Hi vyos@pasam. I am runnning into same situation you faced. i know this is old threadh, but will appreciate if you can let me know how you solved this. basically, i’m connecting OR-vpc-1 and SG VPC and also using the “cloud-hub” like config, so that my on premises devices can talk to each other via AWS VPG. one vyos in OR-vpc-2 is connected to to both SG and OR-vpc-1 vpg. even the OR-vpc-1 vpg can learn the bgp routes from SG side, but SG side only learning one route (OR vpc-vpc-2 network, static route).

Any help will deeply appreciated.
you can mail me on