Route reduction?

Reason is simple. I have three small VMs (NYC1BR1, LUX1BR1, AMS1BR1) which have only 2GB of RAM available. Each of these VMs receive full routes from the VPS provider, and they also had all the other routes from the other VMs. It doesn't seem such a good idea to have these VMs, with a small amount of ram, storing 3 full IPv6 BGP tables, they're already running somewhat low in RAM.

Considering I have a full mesh of tunnels for IPv6 connectivity among all my AS203528 routers, and I have no services directly connected to either of those three VMs, then the idea is to have those VMs only have transit routes received from that provider, plus my internal routes only. I'll make sure that we never have the scenario of "IPv6 traffic traversing a VM that does not have a route for it".

Adding a community to transit routes

I decided to add large community "203528:1:1" to all routes I receive via transit. 

 1set policy large-community-list VIA_TRANSIT rule 10 action 'permit'
 2set policy large-community-list VIA_TRANSIT rule 10 regex '203528:1:1'
 3
 4set policy route-map IMPORT_FRC_AMS_002 rule 40 action 'deny'
 5set policy route-map IMPORT_FRC_AMS_002 rule 40 description 'Drop anything longer than /48'
 6set policy route-map IMPORT_FRC_AMS_002 rule 40 match ipv6 address prefix-list 'IPV6_SMALL_PREFIX'
 7set policy route-map IMPORT_FRC_AMS_002 rule 50 action 'deny'
 8set policy route-map IMPORT_FRC_AMS_002 rule 50 description 'Drop long AS paths'
 9set policy route-map IMPORT_FRC_AMS_002 rule 50 match as-path 'LONG_AS'
10set policy route-map IMPORT_FRC_AMS_002 rule 60 action 'deny'
11set policy route-map IMPORT_FRC_AMS_002 rule 60 description 'Drop Bogons'
12set policy route-map IMPORT_FRC_AMS_002 rule 60 match ipv6 address prefix-list 'IPV6_BOGONS'
13set policy route-map IMPORT_FRC_AMS_002 rule 70 action 'deny'
14set policy route-map IMPORT_FRC_AMS_002 rule 70 description 'Drop my own routes'
15set policy route-map IMPORT_FRC_AMS_002 rule 70 match ipv6 address prefix-list 'IPV6_MY_OWN_PREFIX'
16set policy route-map IMPORT_FRC_AMS_002 rule 100 action 'deny'
17set policy route-map IMPORT_FRC_AMS_002 rule 100 match rpki 'invalid'
18set policy route-map IMPORT_FRC_AMS_002 rule 110 action 'permit'
19set policy route-map IMPORT_FRC_AMS_002 rule 110 description 'Catch all'
20set policy route-map IMPORT_FRC_AMS_002 rule 110 set large-community add '203528:1:1'
21set policy route-map IMPORT_FRC_AMS_002 rule 110 set local-preference '90'

After deploying:

 1fabrizzio@AMS1BR1:~$ show bgp ipv6 2600::
 2BGP routing table entry for 2600::/48, version 32241838
 3Paths: (1 available, best #1, table default)
 4  34872 1239
 5    2a0c:b640:11::ffff from 2a0c:b640:11::ffff (10.192.255.193)
 6    (fe80::cc82:f5ff:fe1c:5819) (used)
 7      Origin IGP, metric 0, localpref 90, valid, external, bestpath-from-AS 34872, best (First path received), rpki validation-state: not found
 8      Community: 65101:1082 65102:1000 65103:276 65104:150
 9      Large Community: 34872:10:0 203528:1:1
10      AddPath ID: RX 0, TX-All 577767 TX-Best-Per-AS 0
11      Advertised to: 192.168.248.12 192.168.248.13 192.168.248.14 192.168.248.15 192.168.248.16 192.168.248.90 192.168.248.91
12      Last update: Thu Jun 29 16:39:23 2023

Not sending these routes to other Transit-only VMs.

For this I had to create a new route-map on each of my transit VMs to deny those routes that have transit community:

1set policy route-map ibgp_ula_nh_transit rule 9 action 'deny'
2set policy route-map ibgp_ula_nh_transit rule 9 match large-community large-community-list 'VIA_TRANSIT'
3set policy route-map ibgp_ula_nh_transit rule 10 action 'permit'
4set policy route-map ibgp_ula_nh_transit rule 10 set ipv6-next-hop global 'fc0e:8f02:21d0:ffff::10'

Compared to the old route-map:

1set policy route-map ibgp_ula_nh rule 10 action 'permit'
2set policy route-map ibgp_ula_nh rule 10 set ipv6-next-hop global 'fc0e:8f02:21d0:ffff::10'

And just configure that route-map as export on the iBGP sessions facing the other VPS VMs.

Blackhole prevention

Even though I have full mesh of tunnels for IPv6 connectivity between routers, and the IGP metrics I put there should make traffic to router X always use a tunnel directly to X (instead of taking a tunnel to Y and from then to X), I still want to be completely sure that no IPv6 traffic traffic not destined to the VPS VMs will be inspected by those.

For that purpose, on the three routers that are part of the IPv6 tunnel mesh but do not hold all the copies of routing tables, I enabled the IS-IS overload bit.

1set protocols isis set-overload-bit

That way, tunnels terminating there will never be used for transit traffic to a different router (they are fully meshed for a reason).

Results

 1IPv6 Unicast Summary (VRF default):
 2BGP router identifier 192.168.248.10, local AS number 203528 vrf-id 0
 3BGP table version 36188466
 4RIB entries 348056, using 64 MiB of memory
 5Peers 12, using 8682 KiB of memory
 6
 7Neighbor                     V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
 8192.168.248.11               4     203528   3571763   9313096        0    0    0 03w0d01h            3     2179 To NYC1BR1
 9192.168.248.12               4     203528   2792352  11942257        0    0    0 01w6d08h            8   185807 To OSR1BR1
10192.168.248.13               4     203528   2871855  11844769        0    0    0 01w6d08h          962   185807 To OSR1BR2
11192.168.248.14               4     203528    873696  11984491        0    0    0 01w6d08h           81   185807 To OSR2BR1
12192.168.248.15               4     203528     31803  11845179        0    0    0 01w6d08h            6   185807 To OSR2BR2
13192.168.248.16               4     203528     30344  11749802        0    0    0 01w6d08h            4   185807 To OSR1BR3
14192.168.248.18               4     203528      4230     16984        0    0    0 1d05h31m            3     2179 To LUX1BR1
15192.168.248.90               4     203528     30315  11654475        0    0    0 03w0d01h            1   185807 To OSR1GLASS1
16192.168.248.91               4     203528     30315  11654469        0    0    0 03w0d01h            1   185807 To OSR2GLASS1
172a0c:b640:11::ffff           4      34872  14567492    544268        0    0    0 02w4d21h       183628        1 Servperso Transit
182a0c:b641:701:0:a5:20:2409:1 4     202409    160597     60684        0    0    0 5d18h16m         1186        1 LocIX DUS RS1
192a0c:b641:701:0:a5:20:2409:2 4     202409    162836     60665        0    0    0 5d18h15m          990        1 LocIX DUS RS2

Looks much better now, compared to a router where I still hold multiple full tables:

 1IPv6 Unicast Summary (VRF default):
 2BGP router identifier 192.168.248.16, local AS number 203528 vrf-id 0
 3BGP table version 27201097
 4RIB entries 348239, using 64 MiB of memory
 5Peers 9, using 6511 KiB of memory
 6
 7Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
 8192.168.248.10  4     203528   8245023     19243        0    0    0 01w6d08h       185806        4 To AMS1BR1
 9192.168.248.11  4     203528   3314909     19243        0    0    0 01w6d08h       182993        4 To NYC1BR1
10192.168.248.12  4     203528     19383     19248        0    0    0 01w6d08h            8        4 To OSR1BR1
11192.168.248.13  4     203528    358776     19245        0    0    0 01w6d08h          970        4 To OSR1BR2
12192.168.248.14  4     203528    576986     19242        0    0    0 01w6d08h           81        4 To OSR2BR1
13192.168.248.15  4     203528     19415     19244        0    0    0 01w6d08h            6        4 To OSR2BR2
14192.168.248.18  4     203528   1171984     10633        0    0    0 2d05h57m       183111        4 To LUX1BR1
15192.168.248.90  4     203528     19242     19243        0    0    0 01w6d08h            1        4 To OSR1GLASS1
16192.168.248.91  4     203528     19242     19245        0    0    0 01w6d08h            1        4 To OSR2GLASS1