Cisco ASA and BVI interfaces

Question

I'm in the middle of equipment migration and the setup is somewhat similar to Mike's (Configure Cisco ASA in Transparent mode: Layer2 DMZ w/ Vlan translation) but with a difference that I need the inside and outside VLANs to be different.

We have a X 'outside' VLANS (with IDs from 600-699) and X 'inside' VLANS (with IDs from 700 to 799). I was going with the same idea as in Mike's post: two subinterfaces (one outside, one inside) and one bridge group. Setup looked fine... on the paper.

First thing I found out is that you need to have a BVI interface for bridge group to work, so burning one (public in our case) IP for no apparent reason. Second thing, that some of you probably know but I didn't even think i should check, is that ASA allows maximum of 8 BVI interfaces (or 8 per context if in multimode).

My questions

I would mostly like to know the why ASA has such requirements.

1. Why is there a need for BVI interface with a valid IP address if we want just to bridge two interfaces? Documentation vaguely states that BVI is used for management and packets sourced from ASA (ARP, etc.) but why is any of that necessary for a transparent L2 firewall? I understand the need when we're talking about IRB on routers but I really don't on a device that basically should just drop or pass frames.
2. What is a reason for a limit of 8 bridge groups? Is there any technical reason or is this just so you would need to buy more context licenses if you want to do something like this.
3. And of course do you have any different solutions for this problem?

I know that their idea is probably to have a different context for each VLAN (or a mix of contexts and bridge groups). My concern is management, for example can you share objects between contexts? We have a lot of network devices and servers on the 'outside' and making object for them for each context would not be manageable.

Answer 1

1. When in transparent mode, the ASA performs some layer 2 validation. One thing it validates is that the MAC address and IP address of a packet flying by are correctly correlated. That is to say, that the ASA needs to believe that the MAC and IP belong together (think like an ARP table) in order for it to pass a packet where said MAC and IP are found together. If the firewall believes a packet is using the wrong MAC address for a given IP address, then it will drop the packet. If the ASA does not know the correct MAC for a given IP address, it will trigger an ARP request to find out. How does it do that? By using the BVI address that you assigned. Although the software developers could have written the code to simply not trigger an ARP, this feature is very important for security reasons (it is a firewall, ya know!) and for things to work correctly. Therefore, I think the software developers simply decided instead of writing a bunch of logic to do different things in different scenarios, they simply decided that you must configure the BVI IP before the firewall will function at all. That makes the software code a lot easier to develop and maintain.
2. Since a single bridge-group loosely equates to a single firewall, I'm only guessing that monetary revenue might have something to do with it. If they let you create however many you want, then you may not need to buy as many firewalls. However, there is probably an aspect of software development going on here, too, with how the bridge group numbers are held in memory, and how the connection tables correlate with the bridge-group numbers, etc. The more number of bridge groups they let you create, then the more RAM it will take up when all those connections are stored in the RAM with more bits taken up by the bridge group numbers.
3. Nope, I don't know of any other solutions to independently map 100 inside vlans to 100 outside vlans, and have layer 3 filtering abilities on all 100 pairs.
4. Nope, configurations are not shared between contexts. So any object, object-group, access-list configs are constrained to the device context in which they are configured.