ASA Active/Standby with BDI/BVI

I see a lot of ASA designs and they are typically flanked with switches. One of the reasons for this is that the failover requirements typically dictate that the devices to be layer 2 adjacent in each security zone. There is obviously the requirement to be L3 directly connected to their next hop. The result of this requirement that an ASA can’t typically be directly connected directly to an L3 only device and it is often the case that a switch is sandwiched between the FW and the next L3 device.

This article is meant to outline a possible work around with IOS and IOS-XE based routers to provide the L2 two adjacency using inherit L2 features. Readers may use these sample configurations to build out there own labs and more fully validate the applicability the their environment.

TL;DR–BDI and BVI allow ASA A/S to function properly in my testing.

The Topology

Below is the topology that used for validating this. In a real world scenario it is less likely that routers would be the connection point on all interfaces. The reason I positioned them here is to demonstrate both IOS and IOS-XE techniques in the same lab.

asa_bvi_bdi

Solution Overview

To make asav-1 and asav-2 L2 adjacent on both transit interfaces, IOS and IOS-XE (csr100v) have bridging functions the can be leveraged.

IOS

IOS has a concept of bridges exposed as bridge-groups (to which physical interfaces are assigned) and bridge virtual interfaces. The bridge virtual interface (or bvi) is a virtual interface with a mac address that becomes a routing instance for the bridge group. The BVI allows iosv-1 and iosv-2 to do an IGP peer between each other and the Firewalls.

IOS-XE

IOS-XE, found in later ISR’s, ASR 1000’s, and CSR1000v have a similar concept known as bridge domains. Physical interfaces are assigned to the bridge domain and a virtual interface, known as a BDI (Bridge Domain Interface) is used as the L3 instance inside the L2 instance.

Examples (relevant snippets)

ASA Configuration (asav-1 shown, asav-2 similar)

interface GigabitEthernet0/0
 nameif inside
 security-level 100
 ip address 10.10.30.100 255.255.255.0 standby 10.10.30.101 
!             
interface GigabitEthernet0/1
 description to csr1000v-X
 nameif outside
 security-level 0
 ip address 10.10.20.100 255.255.255.0 standby 10.10.20.101 
!             
interface GigabitEthernet0/2
 description LAN/STATE Failover Interface
!
//adjust for secondary -- failover lan unit secondary
failover
failover lan unit primary
failover lan interface FOVER GigabitEthernet0/2
failover link FOVER GigabitEthernet0/2
failover interface ip FOVER 10.10.10.1 255.255.255.252 standby 10.10.10.2
!
object network obj-any
 subnet 0.0.0.0 0.0.0.0
!
nat (inside,outside) source static obj-any interface
!
router ospf 1 
 network 10.10.30.0 255.255.255.0 area 0
 log-adj-changes
 default-information originate always
!
//routing to the HSRP standby on the BDI of csr1000v-1/csr1000v-2
route outside 0.0.0.0 0.0.0.0 10.10.20.1 1

IOS Router Config (iosv-1 shown, iosv-2 similar)

!
//bridge configuration
!
bridge irb
 bridge-group 1
 bridge-group 1
bridge 1 protocol ieee
bridge 1 route ip
!
interface Loopback0
 description Loopback
 ip address 192.168.0.1 255.255.255.255
!         
interface GigabitEthernet0/1
 description to iosv-3
 ip address 10.0.0.17 255.255.255.252
 ip ospf cost 1
!
//next two physical interfaces are in bridge-group 1
!         
interface GigabitEthernet0/2
 description to iosv-2
 no ip address
 bridge-group 1
!         
interface GigabitEthernet0/3
 description to asav-1
 no ip address
 bridge-group 1
!         
//BVI for peering between the routers and ASAs (unique IP per Router)
!         
interface BVI1
 ip address 10.10.30.2 255.255.255.0
!
router ospf 1
 passive-interface Loopback0
 network 10.0.0.16 0.0.0.3 area 0
 network 192.168.0.1 0.0.0.0 area 0

IOS-XE Router Config (csr1000v-1 shown, csr1000v-2 similar)

bridge-domain 1
interface Loopback0
 description Loopback
 ip address 192.168.0.7 255.255.255.255
!
//Next two interfaces assigned to bridge domain 1
!
interface GigabitEthernet2
 description to asav-1
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
  bridge-domain 1
 !
!
interface GigabitEthernet3
 description to csr1000v-2
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
  bridge-domain 1
!
interface GigabitEthernet4
 description to iosv-4
 ip address 10.0.0.37 255.255.255.252
 ip ospf cost 1
!
//BDI routing interface for csr1000v-1, showing with HSRP
!
interface BDI1
 ip address 10.10.20.2 255.255.255.0
 standby 1 ip 10.10.20.1
 standby 1 priority 90
 standby 1 preempt
!
router ospf 1
 passive-interface Loopback0
 network 10.0.0.36 0.0.0.3 area 0
 network 10.10.20.2 0.0.0.0 area 0
 network 192.168.0.7 0.0.0.0 area 0

Full unedited configuration of all devices can be downloaded here.

Conclusion

BVI and BDI interfaces seem to work as expected for providing L2 Adjacency. With this topology built, I performed various cursory failover scenarios and everything worked as expected. I think BDI/BVI could be a viable solution for certain use cases. As with any solution, this should be tested and validated against the requirement.

If you have a similar configuration and have additional feedback or have ran into challenges, please share those with the community by commenting below.

 

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

 

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Uncategorized and tagged . Bookmark the permalink.

8 Responses to ASA Active/Standby with BDI/BVI

  1. Shuja says:

    Hey Paul

    I see a lot of ASA designs and they are typically flanked with switches. One of the reasons for this is that the failover requirements typically dictate that the devices to be layer 2 adjacent in each security zone. There is obviously the requirement to be L3 directly connected to their next hop. The result of this requirement that an ASA can’t typically be directly connected directly to an L3 only device and it is often the case that a switch is sandwiched between the FW and the next L3 device.

    Can you explain further. Somethings are unclear here

    • If you use ASA in active/standby (or other failover config), the Firewalls must share a layer 2 network with each other and the next hop device(s). When the standby (physically separated device) goes active, it assumes the IP. The upstream L3 network still needs access to that IP. Typically that is also deployed redundantly. So the ASA interface can’t connect directly to a router if that router is doing only L3 functions and failover needs to be seemless. Allowing the router to do L3 and L2 functions is the purpose of this article (so you may eliminate the switch sandwiched between the Router and ASA unless it’s needed for other things–additional connectivity, SPAN).

      Does that help.

  2. Shuja says:

    Ok cool. So this config is viable if there is no direct failover link present. Right ?

  3. karmicgeezer says:

    Paul – great article, many thanks. On the assumption you used VIRL to create the topology, would you mind sharing the virl topology file?

Comments are closed.