Utilizing BGP Communities for traffic steering – part 1: Firewalls

Overview:

I typically spend more time in the enterprise data center than most of our team members and this comes with its own unique set of problems. One discussion that seems to never fail to come up is “where do I put the Firewalls (FWs)?”. That is typically followed by I have a disaster recovery or backup site with FWs there as well. This inevitably leads to a state management problem. Let’s look at how we can utilize BGP to address this problem:

  • what is a BGP standard community
  • BGP best path selection process
  • how to utilize them to steer traffic

This is something most service providers deal with on a daily basis but can be new to an enterprise.

BGP Standard communities

A BGP community is a route attribute that, essentially provides extra information for someone to take action or glean information from the route such as where it came from (location, type, organizational role).

By definition, a community is a 32 bit number that can be included with a route and when utilizing the new community format is displayed as (0-65535):(0-65535). It is recommend to utilize the new community format versus the old community format which is just a number. It is typically to utilize $YOURASN:$VALUE such as 65000:1000 which would be a community within ASN 65000 to signify something such as 1000 came from datacenter 1. This insures that you know the community was originated by your organization.

There are some well known communities that have global meaning. BGP communities are also what is called an optional transitive BGP attribute meaning that they can be passed from autonomous system (ASN) to autonomous system. It is typically recommended to strip communities sent from other organizations to prevent interference with your local policy. Telia has a great looking glass utility (https://lg.telia.net)that gives information on the communities they’ve attached to your routes.

BGP path selection

Now that we know what is a community is lets look at the BGP path selection process. It’s not uncommon for vendors to have vendor specific selection criteria with “weight” being at the top. However, typically local preference is the first with highest being the best. Then locally originated, shortest AS path, origin check, and Multi Exit Discriminator (MED). There are more selection criteria than this but we will focus on local preference (LP) since it is at the top of the list.

Modifying local preference will ALWAYS beat one of the other criteria with the exception of a weight value where applicable. For example in a Cisco environment the highest weight will beat the LP, if the weight is equal it will move to LP.

You might have noticed that there is no “community” value in the path selection process. That is because we are going to combine the community value with a policy to take an action on a route. Let’s tie this back to firewalls, security zones, and policy in the next section.

Modifying behavior with communities and LP

There are two ways to extend a security zone through a firewall. You can either route and utilize a Virtual Routing and Forwarding instance (VRF) or switch and put the Switched Virtual Interface (SVI) on the firewall. Switching limits your options as you scale and is not recommended. For this reason we will focus on utilizing VRFs. In this case we have VRF blue with community 65000:1 and VRF Orange with community 65000:2. These are segregated by firewalls and have different security policy.

With two firewalls it is easy to introduce a state problem and have packets rejected because of invalid state. When a packet ingresses one firewall and egresses another this introduces the problem as firewall 2 does not have a session for the flow. “How come we don’t run an HA pair?” is a common question; these might already be an HA pair and you’re preparing for a migration, they’re different vendors, or they’re in different data centers completely.

So now I can tie communities and local preference (LP) together to pin flows to firewalls and manage state. I can raise or lower the LP based on the community to ensure routing always returns to the firewall with the active session state. If the firewalls are in different data centers you can even do this to move flows of the same security level below the firewalls and maintain state across the DCs. Doing so involves advanced network techniques and policy configurations which IParchitechs has successfully implemented in dozen of DCs in spite of vendor attestation that this is not feasible.

Juniper to MikroTik – BGP commands

About the Juniper to MikroTik series

In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly.  Juniper is a popular option for service providers/data centers and is widely deployed across the world. 

This is a continuation of the Rosetta stone for network operating systems series.  We’ll be working through several protocols over series of posts to help you quickly move between different environments. 

While many commands have almost the exact same information, others are as close as possible.  Since there isn’t always an exact match, sometimes you may have to run two or three commands to get the information needed. 

Using EVE-NG for testing

We conducted all of this testing utilizing EVE-NG and the topology seen below. 

Juniper CommandMikroTik Command
show bgp summaryrouting bgp peer print brief
show bgp neighborrouting bgp peer print status
show route advertising-protocol bgp 172.31.254.2routing bgp advertisements print peer=peer_name
show route receive-protocol bgp 172.31.254.2ip route print where received-from=peer_name
show route protocol bgpip route print where bgp=yes
clear bgp neighbor 172.31.254.2 soft-inboundrouting bgp peer refresh peer_name
clear bgp neighbor 172.31.254.2 softrouting bgp peer resend peer_name
set routing-options autonomous-system 1/routing bgp instance
set default as=2
set protocols bgp group EBGP type external
set protocols bgp group EBGP peer-as 2
set protocols bgp group EBGP neighbor 172.31.254.2
/routing bgp peer
add name=PEER-1 remote-address=172.31.254.1 remote-as=1
set policy-options policy-statement REDIS-CONNECTED term 1 from protocol direct
set policy-options policy-statement REDIS-CONNECTED term 1 then accept
set protocols bgp group EBGP export REDIS-CONNECTED
/routing bgp network
add network=100.89.88.0/24
add network=100.89.87.0/24
add network=100.89.86.0/24
set routing-options static route 0.0.0.0/0 discard
set protocols bgp group EBGP export SEND-DEFAULT
set policy-options policy-statement SEND-DEFAULT term 1 from protocol static
set policy-options policy-statement SEND-DEFAULT term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement SEND-DEFAULT term 1 then accept
/routing bgp peer
add default-originate-always name=PEER-1 remote-address=172.31.254.1 remote-as=1


https://iparchitechs.com/contact

Examples of the commands above


This is a quick way to get a list of the peers/ASN and their status

[[email protected]] > routing bgp peer print brief

[email protected]> show bgp summary

This next command will show you more information about a peer.  In this case we did not specify the peer as there is only one.  On a peering router with multiple peers it is recommended to look only at specific peer information to not be overwhelmed with irrelevant information. 

[[email protected]] > routing bgp peer print status

[email protected]> show bgp neighbor

The next command allows you to see the prefixes that are sent to your peer as well as the next-hop associated with it. 

[[email protected]] > routing bgp advertisements print peer=PEER-1

[email protected]> show route advertising-protocol bgp 172.31.254.2

This next one will show you what routes were received from the peer and the next-hop you will advertise. 

[[email protected]] > ip route print where received-from=PEER-1

[email protected]> show route receive-protocol bgp 172.31.254.2

Here we will see the BGP prefixes that are in the routing table – both active and not.  On junOS you will see the count for hidden routes in the output but you will not see the hidden entries.  This will require the use of “show route protocol bgp hidden” to see the hidden entries.  On mikrotik you will see this type of route in the route table as inactive. 

[[email protected]] > ip route print where bgp=yes

[email protected]> show route protocol bgp

Configure BGP instance, peering, and originate a default route. 

Here is a very basic BGP peering configuration to establish a peer, advertise a few routes, and originate a default route. 

Let’s look at some of the differences in the configuration. 

It’s worth noting that everything in CAPS was manually defined . 

On junOS there is no concept of the “network” command that you might see in MikroTik or Cisco.

To accomplish the same functionality in this example I used a policy-statement named REDIS-CONNECTED that matched any connected route for redistribution. 

This is then applied as an export statement into the EBGP peer group.  Likewise, there is not a construct for “default-originate”.  In order to accomplish the same functionality, we created a static route to discard and exported this to the EBGP peer.

MikroTik BGP Configuration

/routing bgp instance
set default as=2
/routing bgp network
add network=100.89.88.0/24
add network=100.89.87.0/24
add network=100.89.86.0/24
/routing bgp peer
add default-originate=always name=PEER-1 remote-address=172.31.254.1 remote-as=1

Juniper BGP Configuration

set interfaces lo0 unit 0 family inet address 100.99.98.1/24
set interfaces lo0 unit 0 family inet address 100.99.97.1/24
set interfaces lo0 unit 0 family inet address 100.99.96.1/24
set routing-options static route 0.0.0.0/0 discard
set routing-options autonomous-system 1
set protocols bgp group EBGP type external
set protocols bgp group EBGP export REDIS-CONNECTED
set protocols bgp group EBGP export SEND-DEFAULT
set protocols bgp group EBGP peer-as 2
set protocols bgp group EBGP neighbor 172.31.254.2
set policy-options policy-statement REDIS-CONNECTED term 1 from protocol direct
set policy-options policy-statement REDIS-CONNECTED term 1 then accept
set policy-options policy-statement SEND-DEFAULT term 1 from protocol static
set policy-options policy-statement SEND-DEFAULT term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement SEND-DEFAULT term 1 then accept

More to come

There are so many commands to consider for BGP, we probably could have added close to 100, but we decided to list the commands we use most often to start with and will be adding to the list of BGP commands as well as other like OSPF, MPLS, and VLANs in future posts.