What is the best method for my BGP routers to share external BGP routes to my OSPF routers?

[tjh]

@L0crian

For everyone; do not use a static route for this. It’s the wrong tool for the job and can lead to the exact failure scenario that is trying to be solved.

The reason you want routing between the 2 BGP routes is to route around failures. A static route is a hard coded route that can never fail, even if all other ability to forward on that router has ceased.

I’m confused though. If I’ve got two routers, each with eBGP up to their upstream (learning a full table) and I have iBGP between them, the only time the static route will “win” is when both upstreams have failed.

I agree if your upstreams are sending you a default, that’s a better solution, but if they’re not, can you explain what’s wrong with a static discard? The only time it can win is a bad time anyway?

[L0crian]

@tjh

I agree if your upstreams are sending you a default, that’s a better solution, but if they’re not, can you explain what’s wrong with a static disgard? The only time it can win is a bad time anyway?

That’s actually the problem, it should never win. And winning in a failure scenario will make traffic worse.

Let’s look at the situation in the diagram posted earlier. There’s 2 routers, each with an upstream peering. Now you do a floating static to null on both routers. Here’s where the problem starts.

OSPF is picking up on any default in the RIB. When the BGP peering upstream goes down, then the default from BGP is withdrawn (if the upstream peer is not sending a default for some bizarre reason, then you can request it). That should be the end of it, and it will prefer the path through the secondary router, but that floating static remains (always), and the OSPF learned default is still propagated downstream, even though it’s not reflective of the actual forwarding path that router is capable of.

It could be made even worse if the BGP peering between the routers also fails, because now you’ve created a true blackhole for traffic. The static route will still advertise a default into OSPF, even though it’s truly isolated.

A default created with static routes, and one with default-information originate will actually look identical for the most part. The difference is when originating with a routing protocol instead of static routes, when the ability for the router to forward traffic upstream is stopped, then the default is also withdrawn, so it only is advertised when it has the ability to forward beyond that router.

This allows for the ability to route around any failure (up to the point everything fails), not just some failure.

This goes the same for redistributing a static summary instead of using aggregate address in BGP. Use the intelligent mechanism rather than the dumb one.

[tjh]

@L0crian

That should be the end of it, and it will prefer the path through the secondary router, but that floating static remains (always), and the OSPF learned default is still propagated downstream, even though it’s not reflective of the actual forwarding path that router is capable of.

But it is though. In my discussion, I’m saying you’ve got iBGP to your neighbour. Yes, you’re going to trombone traffic up to the router with the dead eBGP peer, but you still know the full route table via iBGP.

Personally I think relying on a default from your upstream, when they also send you a full table, is a bad design. They make a mistake a accidentally stop originating default to you and go offline. Way better to generate default yourself.

Now, if you have two eBGP neighbours and no iBGP between them, then I 200% agree a static 0.0.0.0/0 is a recipe for disaster, you will blackhole traffic as soon as one eBGP peer goes away.

[L0crian]

@tjh

@L0crian

That should be the end of it, and it will prefer the path through the secondary router, but that floating static remains (always), and the OSPF learned default is still propagated downstream, even though it’s not reflective of the actual forwarding path that router is capable of.

Personally I think relying on a default from your upstream, when they also send you a full table, is a bad design. They make a mistake a accidentally stop originating default to you and go offline. Way better to generate default yourself.

I think we’re missing each other. What you’re saying to do is a good idea. You should always have default route injection; the way you’re saying to do it is not ideal and potentially dangerous. Don’t use a static to null, which can lead to blackholes in certain failure scenarios as well as drops in traffic when reconvergence happens. Use a dynamic method like default-information originate. These mechanisms exist to solve this specific problem. These can be generated conditionally, so blackholes would be avoided. Both methods create a default to null locally, but only one can be withdrawn when a router is isolated (e.g. both the eBGP and iBGP peerings are down).

[North-Idaho-Tom-Jone]

L0crian ,

I tried the config you posted in a off-line clone set of VyOS BGP servers and it did not work. I suspect I was not doing things correctly.
Note: I did have to make a change from “rule 10” to “rule 90” because I already had a “rule 10” on one of my BGP servers.

So , I would like to ask , if I post a “show config command” ( without the additional config commands you ref to ) of both of my BGP servers , would you be able to look at the config and insert what you think it should look like.

Thank you for your time ( I love VyOS and suggest it to others often )

North Idaho Tom Jones

** BGP server 1 of 2 **
vrootadmin@VyOS-BGP-IPv4-LibertyLake--205-210-19-246:~$ show config command
set interfaces ethernet eth0 address '50.52.36.250/30'
set interfaces ethernet eth0 description 'eth0-BGP-LibertyLake-IPv4'
set interfaces ethernet eth1 address '205.210.19.246/28'
set interfaces ethernet eth1 address '2605:4e40:0:40c:205:210:19:246/64'
set interfaces ethernet eth1 description 'eth1-OSPF-Vlan21'

set interfaces loopback lo address '205.210.19.246/32'

set policy route-map PrePend-205-210-19-0 rule 10 action 'permit'
set policy route-map PrePend-205-210-19-0 rule 10 set as-path prepend '40033'

set protocols bgp address-family ipv4-unicast network 23.162.144.0/24
set protocols bgp address-family ipv4-unicast network 66.35.8.0/24
set protocols bgp address-family ipv4-unicast network 66.35.15.0/24
set protocols bgp address-family ipv4-unicast network 205.210.19.0/24 route-map 'PrePend-205-210-19-0'
set protocols bgp address-family ipv4-unicast network 207.32.193.0/24
set protocols bgp address-family ipv4-unicast network 207.32.194.0/24
set protocols bgp neighbor 50.52.36.249 address-family ipv4-unicast
set protocols bgp neighbor 50.52.36.249 remote-as '20055'
set protocols bgp system-as '40033'

set protocols ospf area 100 network '23.162.144.0/24'
set protocols ospf area 100 network '207.32.193.0/24'
set protocols ospf area 100 network '205.210.19.0/24'
set protocols ospf area 100 network '207.32.194.0/24'
set protocols ospf area 100 network '66.35.8.0/24'
set protocols ospf area 100 network '66.35.15.0/24'
set protocols ospf area 100 network '66.35.11.0/24'
set protocols ospf area 100 network '66.35.12.0/24'
set protocols ospf area 100 network '66.35.13.0/24'
set protocols ospf area 100 network '66.35.14.0/24'
set protocols ospf area 100 network '207.32.192.0/24'
set protocols ospf area 100 network '207.32.195.0/24'
set protocols ospf area 100 network '207.32.200.0/22'
set protocols ospf area 100 network '192.0.2.254/32'
set protocols ospf default-information originate always
set protocols ospf parameters router-id '205.210.19.246'
set protocols ospf redistribute connected
set protocols ospf redistribute static
set protocols ospfv3 area 200 range 2605:4e40::/32
set protocols ospfv3 area 200 range 2605:6340::/32
set protocols ospfv3 interface eth1 area '200'
set protocols ospfv3 parameters router-id '205.210.19.246'
set protocols ospfv3 redistribute connected
set protocols ospfv3 redistribute static

set protocols static route 0.0.0.0/0 next-hop 205.210.19.247 distance '10'
set protocols static route 23.162.144.96/30 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 23.162.144.96/30 next-hop 205.210.19.251
set protocols static route 23.162.144.196/32 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 23.162.144.196/32 next-hop 205.210.19.251
set protocols static route 23.162.144.222/32 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 23.162.144.222/32 next-hop 205.210.19.252
set protocols static route 66.35.15.192/26 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 66.35.15.192/26 next-hop 205.210.19.252
set protocols static route 205.210.19.8/30 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.8/30 next-hop 205.210.19.251
set protocols static route 205.210.19.68/30 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.68/30 next-hop 205.210.19.251
set protocols static route 205.210.19.182/32 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 205.210.19.182/32 next-hop 205.210.19.252
set protocols static route 205.210.19.183/32 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 205.210.19.183/32 next-hop 205.210.19.252
set protocols static route 205.210.19.208/29 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.208/29 next-hop 205.210.19.251
set protocols static route 205.210.19.216/29 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.216/29 next-hop 205.210.19.251
set protocols static route 205.210.19.232/29 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.232/29 next-hop 205.210.19.251
set protocols static route6 ::/0 next-hop 2605:4e40:0:40c:205:210:19:248 distance '1'
set protocols static route6 ::/0 next-hop 2605:4e40:0:40c:205:210:19:249 distance '2'

** BGP server 2 of 2 **
set interfaces ethernet eth0 address '50.52.36.246/30'
set interfaces ethernet eth0 description 'eth0-BGP-Plummer-IPv4'
set interfaces ethernet eth1 address '205.210.19.247/28'
set interfaces ethernet eth1 address '2605:4e40:0:40c:205:210:19:247/64'
set interfaces ethernet eth1 description 'eth1-OSPF-Vlan21'

set interfaces loopback lo address '205.210.19.247/32'

set protocols bgp address-family ipv4-unicast network 23.162.144.0/24
set protocols bgp address-family ipv4-unicast network 66.35.8.0/24
set protocols bgp address-family ipv4-unicast network 66.35.15.0/24
set protocols bgp address-family ipv4-unicast network 205.210.19.0/24
set protocols bgp address-family ipv4-unicast network 207.32.193.0/24
set protocols bgp address-family ipv4-unicast network 207.32.194.0/24
set protocols bgp neighbor 50.52.36.245 address-family ipv4-unicast
set protocols bgp neighbor 50.52.36.245 remote-as '20055'
set protocols bgp system-as '1052'

set protocols ospf area 100 network '23.162.144.0/24'
set protocols ospf area 100 network '207.32.193.0/24'
set protocols ospf area 100 network '205.210.19.0/24'
set protocols ospf area 100 network '207.32.194.0/24'
set protocols ospf area 100 network '66.35.8.0/24'
set protocols ospf area 100 network '66.35.15.0/24'
set protocols ospf area 100 network '66.35.11.0/24'
set protocols ospf area 100 network '66.35.12.0/24'
set protocols ospf area 100 network '66.35.13.0/24'
set protocols ospf area 100 network '66.35.14.0/24'
set protocols ospf area 100 network '207.32.192.0/24'
set protocols ospf area 100 network '207.32.195.0/24'
set protocols ospf area 100 network '207.32.200.0/22'
set protocols ospf area 100 network '192.0.2.254/32'
set protocols ospf default-information originate always
set protocols ospf parameters router-id '205.210.19.247'
set protocols ospf redistribute connected
set protocols ospf redistribute static
set protocols ospfv3 area 200 range 2605:4e40::/32
set protocols ospfv3 area 200 range 2605:6340::/32
set protocols ospfv3 interface eth1 area '200'
set protocols ospfv3 parameters router-id '205.210.19.247'
set protocols ospfv3 redistribute connected
set protocols ospfv3 redistribute static

set protocols static route 0.0.0.0/0 next-hop 205.210.19.246 distance '10'
set protocols static route 23.162.144.96/30 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 23.162.144.96/30 next-hop 205.210.19.251
set protocols static route 23.162.144.196/32 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 23.162.144.196/32 next-hop 205.210.19.251
set protocols static route 23.162.144.222/32 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 23.162.144.222/32 next-hop 205.210.19.252
set protocols static route 66.35.15.192/26 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 66.35.15.192/26 next-hop 205.210.19.252
set protocols static route 205.210.19.8/30 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.8/30 next-hop 205.210.19.251
set protocols static route 205.210.19.68/30 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.68/30 next-hop 205.210.19.251
set protocols static route 205.210.19.182/32 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 205.210.19.182/32 next-hop 205.210.19.252
set protocols static route 205.210.19.183/32 description 'Wireless-CHR-Sonar-CGN-Nat444-----205.210.19.252 Nat444 pool'
set protocols static route 205.210.19.183/32 next-hop 205.210.19.252
set protocols static route 205.210.19.208/29 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.208/29 next-hop 205.210.19.251
set protocols static route 205.210.19.216/29 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.216/29 next-hop 205.210.19.251
set protocols static route 205.210.19.232/29 description 'GPON-CHR-Sonar-CGN-Nat444-205.210.19.251'
set protocols static route 205.210.19.232/29 next-hop 205.210.19.251
set protocols static route6 ::/0 next-hop 2605:4e40:0:40c:205:210:19:248 distance '1'
set protocols static route6 ::/0 next-hop 2605:4e40:0:40c:205:210:19:249 distance '2'

• Again , thank you in advance of any reply
• fyi one of the nightly 1.5 downloads
• fyi - reason for the almost full “show config command” of both BGP routers is so that others trying to do the same similar thing will be able to easily follow this post topic and find a solution for their needs.
  Tom Jones

[L0crian]

@North-Idaho-Tom-Jone I can look at in a bit. In the mean time, please edit your post by adding | strip-private to your config output. You don’t really want all of your IPs to be on a public forum.

[North-Idaho-Tom-Jone]

I thought about removing much more IP information , but a few simple arin searches will get all of the IPs and AS numbers. And a few traceroutes will show router hops … - then it is pretty easy to guess the IP address on both ends router connections.
However , I did change my ssh port from what I actually use. And I did remove usernames and SNMP information.

EDIT - add more info; Not shown in the config; I do have some additional packages I installed to log and help prevent unwanted service connections to services.

[L0crian]

@North-Idaho-Tom-Jone I edited your post to remove elements not relevant to this scenario (e.g. service, system). Additionally, I formatted it in code blocks to make things easier to read.

General Notes

• If you don’t already, I recommend mocking up a pre-production version of your network in something like GNS3
  • This lets you test every change prior to implementing in production.
• Naming conventions for policies are often personal preference, so feel free to rename anything.
• Request a password to be used with your upstream peer
  • Some peers won’t do this if it wasn’t in the orignal cutsheet, but it’s worth asking
• Apply inbound firewall to only allow your desired traffic (BGP and SSH if that’s all you want)
  • This enables conntrack, but you can set conntrack to ignore all traffic if you don’t need it. That will speed things up a bit, since conntrack is enabled when a firewall rule is created.
• All of your internal peerings can be private IPs. You don’t need to burn public IPs for those.
  • This can likely let you reclaim the 16 IPs in: 205.210.19.240/28 (or more if you’re using public IPs to connect your devices downstream).
• Much of your static routing can likely be handled by OSPF, making maintaining everything much easier.
• Why are you setting the address for lo to the same as eth1?

LibertyLake:

ASN:  40033
eth0: 50.52.36.250/30
eth1: 205.210.19.246/28
lo:   205.210.19.246/32

Upstream Peer: 50.52.36.249

Networks:
	23.162.144.0/24
	66.35.8.0/24
	66.35.15.0/24
	205.210.19.0/24 (prepended once)
	207.32.193.0/24
	207.32.194.0/24

Delete static default:

• You want this to be dynamic or it can lead to blackholes
• You’re already using the following to import a default into your OSPF environment:default-information originate always

delete protocols static route 0.0.0.0/0

Define policies for advertising to upstream peer:

• This prevents making your ISP a transit for other ISPs after peering between your routers. Your upstream peer may even down your peering if you send all prefixes back to them (if they have maximum-prefix set to something low)
• You’ll want to validate these are all of your prefixes. I looked in the public table for your ASN, and this is what I found. They’re also what you imported via the network statements.
• You can verify what you’re sending to your upstream peer with: show ip bgp neighbors 50.52.36.249 advertised-routes
• Commit this before moving to the internal bgp peering

set policy prefix-list Adv_to_Upstream_PFX description "Prefixes to advertise to Upstream"
set policy prefix-list Adv_to_Upstream_PFX rule 10 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 10 prefix 23.162.144.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 20 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 20 prefix 66.35.8.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 30 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 30 prefix 66.35.15.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 40 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 40 prefix 205.210.19.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 50 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 50 prefix 207.32.193.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 60 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 60 prefix 207.32.194.0/24 

set policy route-map Adv_to_Upstream_RM rule 10 description "Matches IPs in Adv_to_Upstream_PFX for upstream filtering outbound"
set policy route-map Adv_to_Upstream_RM rule 10 action permit
set policy route-map Adv_to_Upstream_RM rule 10 match ip address prefix-list Adv_to_Upstream_PFX

Apply new policy:

set protocols bgp neighbor 50.52.36.249 address-family ipv4-unicast route-map export Adv_to_Upstream_RM

Peer to your other BGP router:

• This advertises the full table.
• If you don’t have the resources for this (holding the full table twice in each router), you can advertise only a default.
• I use the IPs that you have configured on eth1, but you may wish to have a direct connection if this goes through a switch. Just create a new direct interface if that’s the case.

set protocols bgp neighbor 205.210.19.247 description "eBGP peering to Plummer"
set protocols bgp neighbor 205.210.19.247 remote-as 1052
set protocols bgp neighbor 205.210.19.247 address-family ipv4-unicast

Define policy for OSPF default injection conditional checks.

• These are all anycast subnets, so they’re good candidates for this.
• Only one of these need to be available for this to work.
• You do want to make sure you’re receiving these, which you should be.

set policy prefix-list OSPF_Def_Conditional_PFX description "Used as conditional check for OSPF default injection"
set policy prefix-list OSPF_Def_Conditional_PFX rule 10 description "Cloudflare"
set policy prefix-list OSPF_Def_Conditional_PFX rule 10 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 10 prefix 1.1.1.0/24
set policy prefix-list OSPF_Def_Conditional_PFX rule 20 description "Level 3"
set policy prefix-list OSPF_Def_Conditional_PFX rule 20 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 20 prefix 4.0.0.0/9
set policy prefix-list OSPF_Def_Conditional_PFX rule 30 description "Google"
set policy prefix-list OSPF_Def_Conditional_PFX rule 30 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 30 prefix 8.8.8.0/24
set policy prefix-list OSPF_Def_Conditional_PFX rule 40 description "Quad9"
set policy prefix-list OSPF_Def_Conditional_PFX rule 40 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 40 prefix 9.9.9.0/24

set policy route-map OSPF_Def_Conditional_RM description "Matches on common public anycast address from Cloudflare, Lev3, Google, and Quad9"
set policy route-map OSPF_Def_Conditional_RM rule 10 action permit
set policy route-map OSPF_Def_Conditional_RM rule 10 match ip address prefix-list OSPF_Def_Conditional_PFX

Redistribute anycast prefixes into OSPF

• OSPF requires the subnets for the conditional check to be in OSPF
• The policy can be reused for both this and the default injection

set protocols ospf redistribute bgp route-map OSPF_Def_Conditional_RM

Apply conditional check to OSPF default injection

• This will always generate a default into your network unless all of the prefixes are lost
• This should only happen in the case your router has neither a peering upstream, or to the other router.

set protocols ospf default-information originate always 
set protocols ospf default-information originate route-map OSPF_Def_Conditional_RM

Plummer:

ASN:  1052
eth0: 50.52.36.246/30
eth1: 205.210.19.247/28
lo:   205.210.19.247/32

Upstream Peer: 50.52.36.245

Networks:
	23.162.144.0/24
	66.35.8.0/24
	66.35.15.0/24
	205.210.19.0/24
	207.32.193.0/24
	207.32.194.0/24

Delete static default:

• You want this to be dynamic or it can lead to blackholes
• You’re already using the following to import a default into your OSPF environment:default-information originate always

delete protocols static route 0.0.0.0/0

Define policies for advertising to upstream peer:

• This prevents making your ISP a transit for other ISPs after peering between your routers. Your upstream peer may even down your peering if you send all prefixes back to them (if they have maximum-prefix set to something low)
• You’ll want to validate these are all of your prefixes. I looked in the public table for your ASN, and this is what I found. They’re also what you imported via the network statements.
• You can verify what you’re sending to your upstream peer with: show ip bgp neighbors 50.52.36.245 advertised-routes
• Commit this before moving to the internal bgp peering

set policy prefix-list Adv_to_Upstream_PFX description "Prefixes to advertise to Upstream"
set policy prefix-list Adv_to_Upstream_PFX rule 10 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 10 prefix 23.162.144.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 20 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 20 prefix 66.35.8.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 30 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 30 prefix 66.35.15.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 40 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 40 prefix 205.210.19.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 50 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 50 prefix 207.32.193.0/24
set policy prefix-list Adv_to_Upstream_PFX rule 60 action permit
set policy prefix-list Adv_to_Upstream_PFX rule 60 prefix 207.32.194.0/24 

set policy route-map Adv_to_Upstream_RM rule 10 description "Matches IPs in Adv_to_Upstream_PFX for upstream filtering outbound"
set policy route-map Adv_to_Upstream_RM rule 10 action permit
set policy route-map Adv_to_Upstream_RM rule 10 match ip address prefix-list Adv_to_Upstream_PFX

Apply new policy:

set protocols bgp neighbor 50.52.36.245 address-family ipv4-unicast route-map export Adv_to_Upstream_RM

Peer to your other BGP router:

• This advertises the full table.
• If you don’t have the resources for this (holding the full table twice in each router), you can advertise only a default.
• I use the IPs that you have configured on eth1, but you may wish to have a direct connection if this goes through a switch. Just create a new direct interface if that’s the case.

set protocols bgp neighbor 205.210.19.246 description "eBGP peering to Liberty Lake"
set protocols bgp neighbor 205.210.19.246 remote-as 40033
set protocols bgp neighbor 205.210.19.246 address-family ipv4-unicast

Define policy for OSPF default injection conditional checks.

• These are all anycast subnets, so they’re good candidates for this.
• Only one of these need to be available for this to work.
• You do want to make sure you’re receiving these, which you should be.

set policy prefix-list OSPF_Def_Conditional_PFX description "Used as conditional check for OSPF default injection"
set policy prefix-list OSPF_Def_Conditional_PFX rule 10 description "Cloudflare"
set policy prefix-list OSPF_Def_Conditional_PFX rule 10 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 10 prefix 1.1.1.0/24
set policy prefix-list OSPF_Def_Conditional_PFX rule 20 description "Level 3"
set policy prefix-list OSPF_Def_Conditional_PFX rule 20 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 20 prefix 4.0.0.0/9
set policy prefix-list OSPF_Def_Conditional_PFX rule 30 description "Google"
set policy prefix-list OSPF_Def_Conditional_PFX rule 30 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 30 prefix 8.8.8.0/24
set policy prefix-list OSPF_Def_Conditional_PFX rule 40 description "Quad9"
set policy prefix-list OSPF_Def_Conditional_PFX rule 40 action permit
set policy prefix-list OSPF_Def_Conditional_PFX rule 40 prefix 9.9.9.0/24

set policy route-map OSPF_Def_Conditional_RM description "Matches on common public anycast address from Cloudflare, Lev3, Google, and Quad9"
set policy route-map OSPF_Def_Conditional_RM rule 10 action permit
set policy route-map OSPF_Def_Conditional_RM rule 10 match ip address prefix-list OSPF_Def_Conditional_PFX

Redistribute anycast prefixes into OSPF

• OSPF requires the subnets for the conditional check to be in OSPF
• The policy can be reused for both this and the default injection

set protocols ospf redistribute bgp route-map OSPF_Def_Conditional_RM

Apply conditional check to OSPF default injection

• This will always generate a default into your network unless all of the prefixes are lost
• This should only happen in the case your router has neither a peering upstream, or to the other router.

set protocols ospf default-information originate always 
set protocols ospf default-information originate route-map OSPF_Def_Conditional_RM

[North-Idaho-Tom-Jone]

L0crian ( and everybody else here ),

Wow - I’m rather blown away at your great support in this VyOS forum topic. – super big thank you - you are a huge credit to this VyOS forum and to people like me who want to be able to do good things with VyOS. - again thank you !!!

Re: GNS3 ; I’ve always wanted to set up a GNS3 virtual lab test environment. Your suggestion about mocking up a network using GNS3 sounds far better & easier than building an off-line clone network for lab testing. - Sooo GNS3 will be on my to-do list.

I will go through your recommended settings in my off-line LAB line by line. I want to understand everything rather than just copy & paste something that works and not learn.

I have to say it , to me - VyOS appears to be one of the best, most stable, fast router operating systems I have encountered.

• To any other other future network admins looking for something better/faster , stop and take a good look and try running VyOS. IMO , VyOS scores a 10-out-of-a-10 on my list

North Idaho Tom Jones

[Apachez]

Did you try my suggestion of instead using this?

set protocols static route 0.0.0.0/0 next-hop 192.0.2.1 distance 254

[North-Idaho-Tom-Jone]

Apachez

re: Did you try my suggestion of instead using this?
set protocols static route 0.0.0.0/0 next-hop 192.0.2.1 distance 254

Yes I did try this with a distance of 254 last year.
Because my upstream BGP peers do not send me a default bgp 0.0.0.0/0 , I was able to verify that traceroutes/pings to IP address not found in any BGP table bounced between my two BGP routers ( up until the packet hit it’s TTL max count ). The good thing was when I tested this , I did not see any deration in on-line routing throughput performance. However , I am pretty sure that if I suddenly had many of my customers scanning all IPs in 0.0.0.0/0 , that there will be blocks of IPs that would ping-pong between my two BGP routers.

• somewhat related to default-routes * on my OSPF network , I do have default routes for each of my /24’s to an OSPF black-hole router which logs everything to my syslog server. So this way , if I am hit with a packet from the Internet or from a customer to any of my /24 blocks which do not have a smaller specific route ( in OSPF ) , then it gets sent to my black-hole and logged then dropped which saves my network from going crazy , especially with the always never-ending huge concurrent amount of network probes from the Internet. Also - on my live-IP OSPF network , I also default route RFC-1918 blocks and CGN blocks ( and other not Internet routable IP blocks ) to my OSPF black-hole router and log it. It’s surprising how many customers have leaking NAT routers or customers that do not block RFC-1918 routes.

• also somewhere around here , I had/have a script that can check the black-hole logs and identify attempted connections to any of my dark IPs ( non used ) , then the script would add those remote IPs scanning/probing my networks and also sent their IPs to my blackhole router - then sometime later release it. Thus , when somebody is scanning my entire network would likely randomly hit one of my dark IPs which pretty much helps to limit and prevents their scanning of my networks.

[16again]

Can you stop the ping-pong using a firewall rule, that blocks traffic being returned on same interface as it entered?

[roedie]

Yes you can. But when you operate a big router with full tables I guess you do not want a firewall. At least don’t want that