Back
Lesson 2 of 7

Secure Firewall Platform Selection

Objective

Choose the correct Secure Firewall (FTD) platform for a given edge / Internet-access scenario. In this lesson you will learn how to evaluate BGP and multi-instance scale, map those requirements to appliance models (1100, 3100, 4200 series), and use real BGP summary output to justify a platform selection. This matters in production because a mis-sized firewall will either drop routes, run out of memory in the data plane, or fail to host the number of virtual instances you need in a multi-tenant deployment.

Real-world scenario: Your organization (NHPREP) peers with an ISP and receives full Internet BGP tables (IPv4 and IPv6). You announce a local prefix (10.16.24.0/24) and must choose an FTD model that supports the BGP table size, neighbor count, and multi-instance requirements for your deployment.

Quick Recap

Reference topology from Lesson 1 (no new devices added in this lesson). The topology illustrates an ISP peering to our route-reflector (CR-1), which is the BGP point-of-presence for the NHPREP edge; the firewall announces the customer prefix.

ASCII topology (showing exact IPs from the reference on each relevant interface):

        [ISP-Router]
        Gi0/0: 85.232.240.179
        Gi0/0: 2001:1A68:2C:2::179
               |
               | eBGP (IPv4 & IPv6)
               |
        [CR-1 (Route-Reflector)]
        Gi0/1: 169.254.10.254
               |
               | internal
               |
         [FW-1 (FTD)] -- announces --> 10.16.24.0/24 (local prefix)

Notes:

  • The IPv4 neighbor IP 85.232.240.179, IPv6 neighbor 2001:1A68:2C:2::179, and router-id 169.254.10.254 are taken verbatim from the reference output we will inspect.
  • The announced prefix 10.16.24.0/24 is the example local prefix.

Device Table

DeviceModel / IdentifierNotable scale figures (from reference)Typical role
FW-11010 / 1100 series exampleMaximum # of BGP routes tested: 5k / 10k ; Maximum # of BGP neighbours: 5Small branch / Internet edge for small sites
FW-13100 seriesMaximum # of BGP routes tested: 100k ; Maximum # of BGP neighbours: 500 (with BFD)Enterprise edge, mid-size data center
FW-14200 / 9300 seriesMaximum # of BGP routes tested: 200k ; Maximum # of BGP neighbours: 500 (with BFD)Large data center / Internet edge with high route counts
CR-1N/A (BGP router)Router-id: 169.254.10.254 (example)Route-reflector / edge BGP peer

Tip: Use the appliance model numbers and their tested BGP route/neighbour counts as a baseline. Production networks often receive full Internet tables (~800k–1.3M prefixes historically); compare your expected table size to the model capabilities.

Key Concepts (theory before hands-on)

  • BGP table scale and memory: BGP stores networks, path attributes, AS-PATHs, communities, and path attributes in memory. The output fields "network entries", "path entries", and "BGP using ... total bytes of memory" directly indicate control-plane memory usage. If the data plane (or control plane) runs out of memory, routing and forwarding will be impacted.
    • Practical: In production, receiving full tables requires appliances that were tested against similar table sizes; the reference lists the maximum BGP routes and neighbors tested per appliance model.
  • IPv4 vs IPv6 differences: IPv6 tables may have different sizes and memory profiles. The reference provides both IPv4 and IPv6 BGP summary outputs; compare both when choosing a platform.
    • Practical: If your ISP provides both IPv4 and IPv6 full tables, ensure the appliance supports both simultaneously in tested scales.
  • Multi-instance (virtual-instance) model: Some FTD appliances support multiple FTD instances (virtual firewalls) managed by FMC/FXOS. The maximum number of instances varies by model and software release.
    • Practical: In multi-tenant or multi-VRF designs, you must ensure your appliance supports the number of instances required (e.g., 3130 supports up to 7 instances per the reference).
  • Modules and interface bandwidth: Network module (NM) options affect I/O capacity. The FPR* module list in the reference shows which interface types and speeds are supported for different platforms; choose based on aggregate throughput and interface types you need.
    • Practical: A model with adequate route scale but insufficient interface bandwidth (or wrong port types) will bottleneck traffic.
  • Real-world analogy: Think of the FTD model like choosing a truck for delivery: BGP table size is the load capacity (how much you can carry), interface/module options are the trailer/connectors, and multi-instance capability is how many separate compartments the truck can have.

Step-by-step evaluation and verification

Step 1: Inspect current IPv4 BGP summary on the edge device

What we are doing: We fetch the IPv4 BGP summary from the edge router (CR-1) to see the current table size, memory usage, and neighbor state. This establishes the control-plane requirements the firewall must support for IPv4.

sh bgp ipv4 unicast summary

What just happened: The command reports the local BGP router identifier, local AS number, BGP table version, number of network entries and path entries, memory usage for various BGP data structures, and each neighbor's state and prefixes received. These numbers let you estimate the memory and path capacity an appliance must support.

Real-world note: When you receive a large number of prefixes from an ISP, the BGP process stores each path, AS-PATH, community, and attributes — these accumulate memory usage. The reference output shows an appliance handling ~983k network entries.

Verify:

sh bgp ipv4 unicast summary
BGP router identifier 169.254.10.254, local AS number 65055
BGP table version is 984072, main routing table version 984072
983198 network entries using 196639600 bytes of memory
983198 path entries using 78655840 bytes of memory
155154/155133 BGP path/bestpath attribute entries using 32272032 bytes of memory
173187 BGP AS -PATH entries using 9067894 bytes of memory
15389 BGP community entries using 1229164 bytes of memory
0 BGP route -map cache entries using 0 bytes of memory
0 BGP filter -list cache entries using 0 bytes of memory
BGP using 317864530 total bytes of memory
BGP activity 3584448/2388995 prefixes, 3584909/2389459 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent TblVer  InQ OutQ Up/Down  State/PfxRcd
85.232.240.179  4 65055 155728   6  984072    0    0   00:03:16  983198

Step 2: Inspect IPv6 BGP summary on the edge device

What we are doing: We fetch the IPv6 BGP summary to evaluate IPv6 memory usage and neighbor status. Many ISPs provide both IPv4 and IPv6 full tables; verify both.

sh bgp ipv6 unicast summary

What just happened: The IPv6 BGP summary lists IPv6 network and path entries and memory usage tied to IPv6 routes. Comparing IPv4 and IPv6 numbers is important for platform sizing because IPv6 tables may also be large and consume additional memory.

Real-world note: Some appliances have different behavior or internal structures for IPv6; ensure your target model was tested for combined IPv4+IPv6 scale if you will receive both.

Verify:

sh bgp ipv6 unicast summary
BGP router identifier 169.254.10.254, local AS number 65055
BGP table version is 212960, main routing table version 212960
212252 network entries using 50091472 bytes of memory
212252 path entries using 22074208 bytes of memory
54970/54970 BGP path/bestpath attribute entries using 11433760 bytes of memory
173187 BGP AS -PATH entries using 9067894 bytes of memory
15389 BGP community entries using 1229164 bytes of memory
0 BGP route -map cache entries using 0 bytes of memory
0 BGP filter -list cache entries using 0 bytes of memory
BGP using 93896498 total bytes of memory
BGP activity 3584448/2388995 prefixes, 3584909/2389459 paths, scan interval 60 secs
Neighbor                    V    AS MsgRcvd MsgSent TblVer  InQ OutQ Up/Down State/PfxRcd
2001:1A68:2C:2::179         4 65055 55611  6 212960    0    0   00:03:20 212204

Step 3: Map observed requirements to appliance models

What we are doing: Using the BGP memory and route numbers observed in Steps 1–2, we choose candidate FTD models whose tested maximums meet or exceed those requirements. This is an architectural decision rather than a CLI configuration.

sh bgp ipv4 unicast summary

What just happened: Running the IPv4 summary again confirms the working numbers we measured. We now compare those numbers to the tested maximums for candidate appliances:

  • 1010/1100 series: tested up to 5k / 10k routes — suitable for small sites only.
  • 3100 series: tested up to 100k routes — good for medium deployments.
  • 4200 / 9300 series: tested up to 200k routes — for large edge deployments.

Real-world note: The reference shows 3100 tested at 100k routes and 4200 at 200k routes; if you expect to receive full Internet tables (~983k in our sample), you must plan a design where the firewall does not need to hold the full Internet table in the data plane (for example, placing a route-reflector or using BGP route filtering/aggregation upstream).

Verify:

sh bgp ipv4 unicast summary
BGP router identifier 169.254.10.254, local AS number 65055
BGP table version is 984072, main routing table version 984072
983198 network entries using 196639600 bytes of memory
...
Neighbor        V    AS MsgRcvd MsgSent TblVer  InQ OutQ Up/Down  State/PfxRcd
85.232.240.179  4 65055 155728   6  984072    0    0   00:03:16  983198

Interpretation: The observed IPv4 network entries (~983k) far exceed the single-appliance tested maximums for the listed models. This indicates one of the following in production:

  • Use a larger platform family (not in the reference tested numbers for >200k); or
  • Perform upstream filtering (preferred): have the ISP or an upstream router send a filtered table (e.g., partial routes or aggregated default), or host BGP on a separate router that peers with the ISP and offloads full-table processing.

Step 4: Validate multi-instance and module needs

What we are doing: Determine whether multi-instance support and network module interface types on the target appliance meet your tenancy and throughput needs. Use the model / multi-instance summary from the reference to validate counts.

sh bgp ipv4 unicast summary

What just happened: Although the BGP command does not show multi-instance counts, re-checking BGP numbers helps you understand whether you need instances (isolated virtual firewalls) versus a single large firewall. The reference lists multi-instance scale for 3100/4200 series (for example: 3130 supports up to 7 instances; 3120 up to 5; 3110 up to 3 depending on release). Similarly, the FPR* network module lists show the available interface types (1/10/25/40/100/200/400G options) which determine physical connectivity.

Real-world note: In production, choose the model not only for route scale but for the number of FTD instances you must run (multi-tenant or multi-vsys use). If you need many instances, ensure the appliance and software release support that count.

Verify:

sh bgp ipv4 unicast summary
BGP router identifier 169.254.10.254, local AS number 65055
BGP table version is 984072, main routing table version 984072
983198 network entries using 196639600 bytes of memory
...
Neighbor        V    AS MsgRcvd MsgSent TblVer  InQ OutQ Up/Down  State/PfxRcd
85.232.240.179  4 65055 155728   6  984072    0    0   00:03:16  983198

Interpretation: The high BGP table numbers again highlight that multi-instance alone will not reduce the need to handle the full table unless each instance holds only a subset of required routes. Plan instance allocation and upstream filtering carefully.

Verification Checklist

  • Check 1: Confirm IPv4 BGP table size on the edge is within the target firewall tested maximum. Verify with sh bgp ipv4 unicast summary and confirm "network entries" <= appliance tested max.
  • Check 2: Confirm IPv6 BGP table size similarly with sh bgp ipv6 unicast summary and ensure combined IPv4+IPv6 memory expectations fit device capacity.
  • Check 3: Confirm required number of FTD instances is within the appliance multi-instance limits from the reference (e.g., 3130 supports up to 7 instances). Verify via appliance documentation / management (FMC/FXOS) — plan capacity if you need more instances.

Common Mistakes

SymptomCauseFix
Chosen firewall runs out of memory when peering with ISPUnderestimated BGP table size (e.g., expecting 100k but receiving ~1M prefixes)Re-evaluate requirements; shift BGP to a router designed for full-table or ask ISP to filter/limit prefixes; choose larger platform family
Selecting appliance based on throughput aloneIgnoring BGP route and neighbor scale (memory and control-plane requirements)Compare both throughput (modules) and BGP tested maximums before purchase
Assuming multi-instance count is unlimitedNot checking model/software-specific limits for instancesVerify multi-instance numbers for your model and release (e.g., 3130 -> up to 7) and plan accordingly
Mismatched interface typesSelecting a model without required NM or port speedsCheck FPR*-NM and FPR*-XNM listings for supported interfaces and speeds and order appropriate module for the platform

Key Takeaways

  • Match control-plane requirements (BGP table size, memory) before hardware selection. The sh bgp ipv4 unicast summary and sh bgp ipv6 unicast summary outputs reveal the true memory footprint you must support.
  • Model tested maximums matter. Use the tested BGP routes and neighbor counts from the appliance reference as baselines — 3100 tested to 100k routes; 4200/9300 tested to 200k routes. If your BGP table exceeds tested counts, use architectural alternatives (upstream filtering, separate full-table router).
  • Multi-instance and module fit are equally important. Ensure the appliance supports the number of FTD instances you need and has appropriate network module types for the interfaces and throughput required.
  • In production, design for the worst-case control-plane load. Plan for combined IPv4 and IPv6 tables, BGP churn, and future growth rather than just current numbers.

Warning: Selecting a firewall only by its throughput or port count without verifying BGP and multi-instance scale is a common root cause of outages during ISP peering or traffic growth. Always validate these numbers against real show output and the appliance tested limits.

If you need, in Lesson 3 we will walk through deploying a small test BGP peer and using filtered tables to validate a candidate FTD in-lab before committing to production.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security