Failover and transparent mode

• You can configure failover on an emulated ASA, but it doesn't appear to work 100%.
• You can create 'failover' groups and attach contexts to each failover group. This enabled one firewall to be active for x contexts and another firewall to be secondary for y contexts.
• This is where it would be nice to have access to physical ASAs
• You can enable link based and/or lan based failover. 
• When configure the link IP, you configure the IP address as the same on both boxes, with the standby configured as well. The priority/preemption will determine the master
• For the most part, failover seemed pretty straight forward
• Transparent firewall
• Enabled with 'firewall transparent'
• 8.4 (and possibly 8.3) changes the configuration. Instead of just 'ip address x.x.x.x', you attach interfaces to bridge groups, and then give the ARP ip address to interface BVI
• I say 'ARP ip address' because even though the firewall is operating in transparent mode, you must still configure an IP address on the ASA for the purpose of ARP. 
• You can configure the Management interface independently of the bridge IP address - this is used for management access only.
• I've realized that transparent firewall just doesn't work very well in GNS3. I will be renting rack time to practice transparent firewall and coming back to this and failover later.
• Fragmented Traffic
• To disable fragment traffic, you set the maximum fragments to 1.

• By default, the security appliance accepts up to 24 fragments to reconstruct a full IP packet. Based on your network security policy, you should consider configuring the security appliance to prevent fragmented packets from traversing the security appliance by entering the fragment chain 1 interface command on each interface. Setting the limit to 1 means that all packets must be whole; that is, unfragmented. - Cisco ASA 8.0 Command Reference - Fragment

• To test, simply send a packet larger than the MTU
• Handling Application Issues
• DNS Doctoring
• Domain lookup to servers on the inside will reply with outside address - doctoring can fix this issue by way of the 'alias' command. You must also disable proxy arp with the 'sysopt noproxyarp inside' command.
• Example

• alias (inside) 10.10.10.10 99.99.99.99 255.255.255.255
  
  !--- This command sets up DNS Doctoring. It is initiated from the clients in
  !--- the "inside" network. It watches for DNS replies that contain
  !--- 99.99.99.99. Then it replaces the 99.99.99.99 address with the 10.10.10.10
  !--- address in the "DNS reply" sent to the client PC. - Cisco - Understanding the Alias command

• IDENT queries over new TCP connection (FTP/SMTP)
• To permit these queries for inside users, enable 'service resetinbound'
• To permit these queries for inside servers, enable 'service resetoutside'
• I see these two as being important - something that will be snuck in the requirements, and easily forgotten, thus missing out on the points for two simple commands!
• BGP through the FW
• BGP is not supported on the firewall but there are certainly instances where you need to establish BGP through the firewall
• R1 is the inside host - 136.1.121.1. R2 is the outside host 136.1.122.2. Configure eBGP peering between R1 and R2.
• The scenario had you build a static nat for the inside interface
• static (inside,outside) 136.1.122.1 136.1.121.1
• From the outside, you then establish a BGP peering to the NAT address
• This obviously requires ebgp multi-hop
• The peering comes up without an issue, but your routes are un-reachable - the next-hop of the routes received on the outside peer, are the inside address of the inside host - 136.1.121.1.
• You create a route-map that sets the next-hop to the NAT address (136.1.122.1) and apply to the neighbor
• Multicast Routing across the FW
• Enabled with multicast-routing
• PIM enabled by default
• Configure RP with 'pim rp-address x.x.x.x'
• There is nothing specific needed to do outside of what is already done on an IOS device - although this scenario is showing my 'rust' when it comes to multicast
• Make sure to enable pim on relevant interfaces
• Make sure to advertise the RP loopback address
• I wasn't getting my S,G , my pings were failing and my incoming/outgoing interfaces were NULL. Guess I should have checked to make sure the routes were there first - forgot to enable RIP on the FW!

I think I will stop here. Was still hoping to be farther along, but I realize you can't rush these things. Being only 15% of the way through is tough to swallow - especially when I just go confirmation that my payment for my lab went through! I hope to make a serious dent on Thursday when I study from home, and Sunday morning. More updates to come.