Migrating away from BGP default-information originate

Background

I recently had yet another nbn unplanned outage. Now I have a GL-MT300N-V2 which I have basic config and a floating, static route on my central/downstream multilayer switch as a backup route with a worse metric than BGP, so that I can share my mobile phone's Mobile Broadband in the event that my Fortigate (FGT) can't forward default route traffic, but for some reason it was not working as expected/intended.

Problem #1 - IPTABLES default reject on FORWARD table

I did not capture the issue in detail, but it turned out that the GL-MT300N-V2 was blocking traffic in the forwarding table, changing this setting is what allowed forward traffic to pass to the MBB tether.

Problem #2 - default-information originate

The upstream BGP default route from my FGT persisted even in the event of an outage, when it should have disappeared so that the floating static route comes takes over internet forwarding (the Fortigate article linked herein explains this however this is normal BGP behaviour, but it was initially overlooked at the time of implementation. whoops!), but this was because I was using the Fortinet option 'set capability default-information-originate` in the BGP configuration, so I ended up tuning the BGP configuration and made the default route more dynamic as follows:

The solution

1. Created a DEFAULT route prefix list
2. Created a Route-map that uses the prefix list
3. Redistributed static routes into the BGP table using the route-map

It now looks something like this:

config router prefix-list

    edit "PL_DEFAULT"

        config rule

            edit 1

                set prefix 0.0.0.0 0.0.0.0

                unset ge

                unset le

            next

        end

    next

end

config router route-map

    edit "RM_DEFAULT"

        config rule

            edit 1

                set match-ip-address "PL_DEFAULT"

            next

        end

    next

end

config redistribute "static"

    set status enable

    set route-map "RM_DEFAULT"

end

I then disconnected the nbn and enabled `debug ip routing` on my switch to test the solution.

During testing and while the nbn was offline, the floating static was in place, exactly as expected:

SWITCH#show ip route | invl 0\.0\.0\.0\/0

S*    0.0.0.0/0 [254/0] via 192.168.81.1

SWITCH#

Once the nbn service was back and the upstream FGT inserted a static default, it wasn't long before I saw this the resulting debug message:

1w0d: RT: updating bgp 0.0.0.0/0 (0x0):

    via 10.8.18.1

1w0d: RT: closer admin distance for 0.0.0.0, flushing 1 routes

1w0d: RT: add 0.0.0.0/0 via 10.8.18.1, bgp metric [20/0]

1w0d: RT: default path is now 0.0.0.0 via 10.8.18.1

I followed this up with a check on the routing table, and here is the dynamic default route from an upstream ppp(oe) link in all its glory.

SWITCH#show ip route bgp | incl 0\.0\.0\.0\/0

B*    0.0.0.0/0 [20/0] via 10.8.18.1, 00:27:41

SWITCH#

Conclusion

This method provides a more elegant solution so that the backup internet solution can be leveraged with almost no touch.

In case your wondering why I use a floating static route, this is because the GL-MT300N-V2 is extremely limited in flash storage making it difficult to install and operate Quagga/FRR and I am tired of resetting the device as it has a tendency to fall over after a while which I suspect is due to lack of space.

The only possible improvement I could do right now is improving security through policy by putting the GL-MT300N-V2 behind the firewall itself, but that is a project for another day (not to mention it runs OpenWRT under the hood and has its own IPTABLES firewall anyway). I also plan to swap out the FGT for a dedicated, OPNSense appliance hosted on an SBC.

I hope this has been informative and I'd like to thank you for reading!

Stay tuned for more...