BGP Filters in Juniper

So, this topic might be a bit too short for you, and I’m sure your BGP filters in your SRX are way more advanced. But for the simpler people like me that just need to get something done; this one is for you.

When I did the AnyCast DNS setup using BGP at home and in Azure, I noticed that my Juniper was also sending the default route 0.0.0.0/0 to Azure. Which caused some problems over there with VM’s not being able to reach certain things and all traffic going from the million Gigabits available in Azure to my home 100Mbps connection just for internet related stuff.

In short, I needed to remove the 0.0.0.0/0 connection from my BGP advertisements towards Azure. And we can do this easily (well – it took me quite some time to figure this one out) by using Policy-Options in SRX.

The thing to note here (I learned the hard way) is that the BGP policies are:

processed in top-down order
by default: accept

There are also 2 policies you can create (per BGP group); one for incoming, one for outgoing.

Now let’s build a policy. In this case I called it “bgp_advertisements” so we control what we are sending out. Each policy has multiple statements (terms) that can contain what we want to allow or deny. For example we can say:

set policy-options policy-statement bgp_advertised term localNetwork from protocol-direct
set policy-options policy-statement bgp_advertised term localNetwork from route-filter 172.16.5.0/24 exact
set policy-options policy-statement bgp_advertised term localNetwork from route-filter 172.16.4.0/24 exact
set policy-options policy-statement bgp_advertised term localNetwork then accept

The above will take the protocol direct (all direct routes on the router) and filter out only 172.16.5.0/24 (and only that one exactly) to be accepted to be sent. This is how you can control the BGP advertisement of each and every (direct) route in the routing table.

But remember we also have an inbound BGP route from AnyCast DNS – which is not a protocol-direct route that we also have to forward (preferably with a lower priority). And to avoid someone from the DC/DNS team making mistakes and taking down the network, we actively filter for the AnyCast DNS IP as well:

(small note on the AnyCast IP: 51.51.51.51 is a public IP address – I wanted to keep this post aligned with my previous AnyCast one, but internally I have changed my AnyCast IP for DNS to 172.16.51.51/32 to avoid publishing public IP’s on my internal network)

set policy-options policy-statement bgp_advertised term AnyCastDNS from neighbor 172.16.5.120
set policy-options policy-statement bgp_advertised term AnyCastDNS from neighbor 172.16.5.121
set policy-options policy-statement bgp_advertised term AnyCastDNS from protocol bgp
set policy-options policy-statement bgp_advertised term AnyCastDNS from route-filter 51.51.51.51/32 exact
set policy-options policy-statement bgp_advertised term AnyCastDNS then preference subtract 10
set policy-options policy-statement bgp_advertised term AnyCastDNS then accept

Then we also remove the default route (just in case it slips through – although we are already filtering on protocol direct in the localNetwork rule)

set policy-options  policy-statement bgp_advertised term removeDefaultRoute from route-filter 0.0.0.0/0 exact
set policy-options policy-statement bgp_advertised term removeDefaultRoute to neighbor 172.16.9.228 set policy-options policy-statement bgp_advertised term removeDefaultRoute to neighbor 172.16.9.229
set policy-options policy-statement bgp_advertised term removeDefaultRoute then reject

And the blockAll to ensure we override that “default allow”

set policy-options policy-statement bgp_advertised term BlockAll then reject

And again.. be sure to have the order correctly…

And then we need to make sure the bgp group azure is actually using this new policy filter:

set protocols bgp group azure export bgp_advertised

And there we go (with 9.229 being one of the Azure VPN Gateway nodes)

our advertisements towards Azure VPN GW’s

And obviously in Azure the 0.0.0.0/0 route is now fixed as well.. – pfiew – finally we have everything working again.

Now, if you are indeed a Juniper SRX administrator and you are reading this, and you are like.. wait; what; huh? This guy has no clue what he just did and there is a way better way for this.. then.. yeah you are right; I’m not a Juniper SRX administrator at all, and indeed I just treaded into BGP – but please please send me an e-mail, LinkedIn invite and let me know how to actually do this!