Performance Scaling with Multiple FWSMs
For high throughput, up to four FWSMs can be installed in a single chassis using an active/active design. This section discusses two methods to load balance multiple FWSMs:
-
Traffic-engineering mechanisms, such as policy-based routing (PBR), to selectively steer traffic through multiple FWSMs
-
Routing, such as static or Equal Cost Multipath (ECMP) routing, to direct flows per FWSM
Example: Load Balancing FWSMs Using PBR
PBR is a mechanism for implementing packet forwarding and routing according to policies defined by the network administrator rather than paths selected by traditional routing methods. Instead of routing by the destination address as determined by a routing protocol, PBR uses more flexible methods such as source IP addresses or application types to match on the identity of the user and then selects the forwarding path. A redundant path could be configured in the event of a link failure or the device going down.
Figure 8-8 shows multiple FWSMs load balanced in an active/active design using PBR supported by the gateway router. A source-based selection method is used to determine the destination firewall path. This is a static load-sharing method based on class maps and route maps to divide traffic among multiple FWSMs. The route maps are configured so that if the first FWSM goes down, a backup FWSM is used.
Load Balancing FWSMs Using ECMP Routing
Static routing or ECMP routing can also be used to selectively route traffic through each of the FWSMs. Take care to ensure that the return path goes through the same firewall or that the FWSM supports asymmetric routing in an active/active design.
Figure 8-9 shows multiple FWSMs load balanced in an active/active design using ECMP routing. The standard destination-based selection method is used by the routing protocol to determine which FWSM to use. If an FWSM goes down, the routing protocol automatically load balances the traffic across the remaining FWSMs.
PVLAN Security
PVLANs allow Layer 2 isolation between ports within a VLAN. Figure 8-10 illustrates the PVLAN architecture and is explained in more detail in this section.
In a regular VLAN, all ports can communicate. PVLANs provide Layer 2 isolation between the ports within the same PVLAN without assigning ports to separate VLANs or assigning individual hosts to different Layer 3 IP networks. PVLANs provide a logical separation of the network that keeps traffic isolated.
The ports that belong to a PVLAN are associated with a primary VLAN. In addition, within the primary VLAN, ports are associated with either an isolated VLAN or a community VLAN. A PVLAN domain has one primary VLAN. Every port in a PVLAN domain is a member of the primary VLAN. Secondary VLANs provide Layer 2 isolation between ports within the same PVLAN domain. There are two types of secondary VLANs:
-
Isolated VLANs: Ports within an isolated VLAN cannot communicate with any other port on the switch, other than the promiscuous port.
-
Community VLANs: Ports within a community VLAN can communicate with each other but cannot communicate with ports in other communities or other isolated ports.
There are three types of PVLAN ports:
-
Promiscuous: This port communicates with all other PVLAN ports and is the port used to communicate with network devices including routers, backup servers, and administrative workstations. This port listens to the secondary VLANs, and sends traffic using the primary VLAN.
-
Isolated: This port has complete Layer 2 separation from the other ports within the same PVLAN with the exception of the promiscuous port. Even with static ARP entries, private ports cannot communicate with each other. Isolated ports use a secondary VLAN to send traffic out and block any traffic coming from the secondary VLAN. All the isolated ports in the system can share the same secondary VLAN.
-
Community: These ports communicate among themselves and with their promiscuous ports. These ports are isolated at Layer 2 from all other ports in other communities and from isolated ports. A separate secondary VLAN is allocated for each community.
| Note | If a broadcast or multicast packet comes from the promiscuous port, it is sent to all the ports in the PVLAN domain, including all community and isolated ports. |
FWSM in a PVLAN Environment: Isolated Ports
FWSM 3.1 supports PVLANs with Cisco IOS Release 12.2(18)SXF.
PVLANs provide an easy way to implement Layer 2 traffic segregation within a VLAN. This feature is popular in demilitarized zone (DMZ) and server farm designs.
On a Cisco Catalyst 6500 series switch, the primary and secondary VLANs are configured on the Supervisor Engine. From the perspective of the MSFC router integrated in the switch, the FWSM is sitting on a promiscuous port and sees all traffic to and from the PVLAN. Only the primary VLAN is assigned to the FWSM, but it is made aware of the primary and secondary VLAN mappings through the MSFC. The FWSM automatically supports isolation of the secondary VLAN traffic to the community and isolated VLANs. The FWSM acts as a gateway between hosts on the PVLANs and the outside world.
Figure 8-11 illustrates the use of PVLANs supporting isolated ports with the FWSM in routed mode. Isolated ports are separated at Layer 2 by the switch processor. Outbound traffic from an isolated port is sent by the FSWM to the MSFC, which routes the traffic appropriately. The FWSM will not forward traffic between isolated ports, because for a single subnet the FWSM will not route packets back out the interface they came in from. Inbound traffic for the isolated port is sent by the MSFC to the FWSM, which sends it to the switch processor. The switch processor forwards the packets to the isolated port based on the MAC address.
FWSM in a PVLAN Environment: Community VLANs
Community VLANs are supported by Layer 2 functions in the switch processor.
Figure 8-12 illustrates the use of community VLANs with the FWSM in routed mode. Community ports are interconnected at Layer 2 by the switch processor. Outbound traffic from a community port is seen by all devices on the community VLAN, including the FWSM. The FSWM will forward outbound traffic to the MSFC, which routes the traffic appropriately. Inbound traffic for the community port is sent by the MSFC to the FWSM, which sends it to the community VLAN. The Layer 2 switch processor forwards it to the appropriate community port or ports based on the MAC address.
Zone-Based Policy Firewall
The zone-based policy firewall configuration model is a new design supported by the Cisco IOS Firewall feature set.
The zone-based policy firewall changes the design model from the older interface-based model to a zone-based configuration model. The zone-based policy firewall configuration model assigns interfaces to zones, and applies an inspection policy to traffic moving between the zones. Zones establish the security borders of the network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of the network.
A security zone is configured for each region of relative security within the network, so that all interfaces that are assigned to the same zone are protected with a similar level of security. For example, Figure 8-13 shows an access router with three interfaces each assigned to its own zone:
In Figure 8-13, each zone holds only one interface. If an additional interface is added to the private zone, the hosts connected to the new interface in the zone can pass traffic to all hosts on the existing interface in the same zone. Traffic to hosts in other zones would be similarly affected by existing policies.
Zone-based policy firewalls allow a more flexible, more easily configured model. Firewall policy troubleshooting is based on the explicit policy on interzone traffic. The zone-based policy firewall default policy between zones is to deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from statefull inspection model, in which traffic was implicitly allowed unless it was explicitly blocked with an ACL. Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.
Interzone policies offer considerable flexibility and granularity, so different inspection policies can be applied to multiple host groups connected to the same router interface. Multiple traffic classes and actions can be applied per zone pair. Zone-based policy firewalls can tie to Cisco Content Switching Module (CSM) mechanisms for ACL deployment and management.
0 comments
Post a Comment