Ive got to tend to agree after reading that and from what I have seen today. Stability is not a word I would associate with this feature.
Strange thing is my standby router R4 has randomly restarted even though I havent manually changed the interface states, which is worrying. Another downside is that I have incorporated some granular protocol inspection (which as far as I can tell is just using PAM with CBAC) on these devices, and that doesnt work either although both devices are identically configured in terms of PAM and CBAC. I have tried to removing cbac from the interface and rebooting both devices and this just doesnt work. You never see get the session table entry on secondary device for the custom apps. R2# *May 16 19:07:26.503: %FW-6-SESS_AUDIT_TRAIL_START: Start user-HTTP8004 session: initiator (10.1.1.100:4925) -- responder (192.1.246.6:8004) R2# R4# *May 16 19:07:59.579: %FW_HA-6-PROT_MISMATCH: Firewall High availability - L4 protocol/mapping for user defined application mismatch between active and standby R4# Generally not a feature I plan to use and Im hoping I do not see this in my lab, sods law says it will be though :-( Stu On Sat, May 16, 2009 at 6:45 PM, Paul Stewart <[email protected]> wrote: > Stuart, > > I am doing the same thing with SSO right now. I am seeing similar things. > What I have found is that as a device transitions from active mode to > standby mode, it reboots. I thought it was a bug at first. At the URL > below, you will find something that seems to say that is the way it works. > I have also been playing with IPSec Profiles within the redundancy and have > had some issue there. Secifically, one of my routers went into "Socket > Error" in show redundancy inter-device. The only way I cleared it up was to > remove the security profile inside of the redundancy config and re add it. > Ironically, the SA's were passing traffic. > > I really don't feel like I would implement SSO in production. I think I > understand it quite well now, but it is not nearly as good of way to do > things as the ASA does with its failover. Moreover, IOS doesn't seem to > have a mechanism to preserve the MAC address on nat translations, so it is > important that the nat pool be behind the interface IP subnet and not part > of it. Then the MAC address is a moot point and inbound traffic is framed > toward the hsrp mac address. > > See this url on SSO > > http://www.cisco.com/en/US/prod/collateral/routers/ps5855/white_paper_c11_472858.html > > On Sat, May 16, 2009 at 12:00 PM, < > [email protected]> wrote: > >> Send CCIE_Security mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://onlinestudylist.com/mailman/listinfo/ccie_security >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of CCIE_Security digest..." >> >> >> Today's Topics: >> >> 1. Re: LAB1B - ASA Static PAT Error (Tyson Scott) >> 2. OT: Jumbo frames / large packets (Stuart Hare) >> 3. Re: OT: Jumbo frames / large packets (Pieter-Jan Nefkens) >> 4. Global & Interface policy precedence (Dnyaneshwar Gore) >> 5. IOS FW Stateful redundancy (Stuart Hare) >> 6. FPM (Stuart Hare) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 14 May 2009 15:09:38 -0400 >> From: "Tyson Scott" <[email protected]> >> Subject: Re: [OSL | CCIE_Security] LAB1B - ASA Static PAT Error >> To: "'Stuart Hare'" <[email protected]> >> Cc: 'Cisco certification' <[email protected]>, 'OSL Security' >> <[email protected]> >> Message-ID: <000901c9d4c7$899c1da0$9cd458...@com> >> Content-Type: text/plain; charset="us-ascii" >> >> Stuart this should work fine. I believe it is shown in the verification >> for >> it working. Did you enable SSH for the ASA on the outside using >> >> Ssh permit x.x.x.x x.x.x.x outside as Dave is asking below? >> >> >> >> Regards, >> >> >> >> Tyson Scott - CCIE #13513 R&S and Security >> >> Technical Instructor - IPexpert, Inc. >> >> >> Telephone: +1.810.326.1444 >> Cell: +1.248.504.7309 >> Fax: +1.810.454.0130 >> Mailto: [email protected] >> >> >> >> Join our free online support and peer group communities: >> <http://www.IPexpert.com/communities<http://www.ipexpert.com/communities>> >> http://www.IPexpert.com/communities <http://www.ipexpert.com/communities> >> >> >> >> IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On >> Demand >> and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE >> Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage >> Lab Certifications. >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Stuart >> Hare >> Sent: Thursday, May 14, 2009 1:34 PM >> Cc: Cisco certification; OSL Security >> Subject: Re: [OSL | CCIE_Security] LAB1B - ASA Static PAT Error >> >> >> >> Great! apparently this is on the resolved caveat list for ASA 8.0(4). >> >> >> >> Evidently this is not the case =) >> >> >> >> >> http://www.cisco.com/en/US/docs/security/asa/asa80/release/notes/arn804n.htm >> l >> >> >> >> >> On Thu, May 14, 2009 at 6:01 PM, Dave Craddock <[email protected]> wrote: >> >> do you have ssh on the outside as you are using the interface and this is >> the asa's ssh address ? >> >> >> >> ________________________________ >> >> From: [email protected] on behalf of Stuart Hare >> Sent: Thu 14/05/2009 18:07 >> To: OSL Security; Cisco certification >> Subject: [OSL | CCIE_Security] LAB1B - ASA Static PAT Error >> >> >> >> Has anyone come across the following error when using static PAT. >> >> asa(config)# static (DMZ7,outside) tcp interface ssh 10.7.7.7 ssh netmask >> 255.255.255.255 >> ERROR: unable to reserve port 22 for static PAT >> ERROR: unable to download policy >> >> Other static PAT statements are in and working correctly. >> static (DMZ8,outside) tcp 192.1.24.8 www 10.8.8.8 www netmask >> 255.255.255.255 >> static (DMZ8,outside) tcp 192.1.24.8 telnet 10.8.8.8 telnet netmask >> 255.255.255.255 >> static (DMZ8,outside) tcp 192.1.24.8 8080 8.8.8.8 www netmask >> 255.255.255.255 >> static (DMZ7,outside) tcp interface https 10.7.7.7 https netmask >> 255.255.255.255 >> >> Not came across this before, any ideas? >> >> Stu >> >> -- >> Stuart Hare >> >> [email protected] >> >> >> >> >> >> >> >> >> >> -- >> Stuart Hare >> >> [email protected] >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 15 May 2009 13:46:35 +0100 >> From: Stuart Hare <[email protected]> >> Subject: [OSL | CCIE_Security] OT: Jumbo frames / large packets >> To: OSL Security <[email protected]>, Cisco >> certification <[email protected]> >> Message-ID: >> <[email protected]> >> Content-Type: text/plain; charset="us-ascii" >> >> Guys >> >> I have a VMware virtaul server that is using enhanced NIC so has jumbo >> frames and tcp offloading enabled. >> And we are seeing performance issues to the app on this server. >> When we capture the traffic with wireshark on the server we see a huge >> amount jumbo frames/packets (anywhere from 2500 to 32000 bytes), that we >> are >> not seeing on the network or end client, as well as of a lot tcp errors, >> in >> terms of bad checksums and retransmissions. On top of this each of the >> jumbo >> frames/packets have the DF bit set, which immediately tells me that these >> packets will be dropped by the lower default MTU on the network devices, >> due >> to no fragmentatoin occurring. >> >> My problem is Im struggling to pinpoint this and find where these packets >> are being dropped if at all. >> I was hoping to see this maybe from the interfaces counters on the >> switches >> but I see nothing. >> Or maybe this is happening at the physically interface of the VM host >> server? >> >> Is my logic around this correct or am i missing something? >> >> Cheers >> Stu >> >> -- >> Stuart Hare >> >> [email protected] >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sat, 16 May 2009 11:44:33 +0200 >> From: Pieter-Jan Nefkens <[email protected]> >> Subject: Re: [OSL | CCIE_Security] OT: Jumbo frames / large packets >> To: Stuart Hare <[email protected]> >> Cc: Cisco certification <[email protected]>, OSL Security >> <[email protected]> >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="us-ascii" >> >> Hello Stuart, >> >> Do you have access to the switch that has the connection between the >> VMWare server and the rest of the network? >> If it's a cisco, check the command >> >> show interfaces <interface> counters all >> >> It will show you if the problem is in the netwerk (from that switch to >> the client PC) or in the vmware environment by looking at the jumbo >> frames counters. >> >> Check out this document: >> http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00801350c8.shtml >> >> You could do this step-by-step on the LAN infrastructure, and then >> check on the firewall / router if the jumbo frames are dropped. >> >> There should be a way to determine (I think with SNMP) to see what >> packets are dropped. I would go from the switch connecting to the >> vmware server up the path to the client PC.. >> >> Pieter-Jan >> >> On 15 mei 2009, at 14:46, Stuart Hare wrote: >> >> > Guys >> > >> > I have a VMware virtaul server that is using enhanced NIC so has jumbo >> > frames and tcp offloading enabled. >> > And we are seeing performance issues to the app on this server. >> > When we capture the traffic with wireshark on the server we see a huge >> > amount jumbo frames/packets (anywhere from 2500 to 32000 bytes), >> > that we are >> > not seeing on the network or end client, as well as of a lot tcp >> > errors, in >> > terms of bad checksums and retransmissions. On top of this each of >> > the jumbo >> > frames/packets have the DF bit set, which immediately tells me that >> > these >> > packets will be dropped by the lower default MTU on the network >> > devices, due >> > to no fragmentatoin occurring. >> > >> > My problem is Im struggling to pinpoint this and find where these >> > packets >> > are being dropped if at all. >> > I was hoping to see this maybe from the interfaces counters on the >> > switches >> > but I see nothing. >> > Or maybe this is happening at the physically interface of the VM host >> > server? >> > >> > Is my logic around this correct or am i missing something? >> > >> > Cheers >> > Stu >> > >> > -- >> > Stuart Hare >> > >> > [email protected] >> > >> >> --- >> Nefkens Advies >> Enk 26 >> 4214 DD Vuren >> The Netherlands >> >> Tel: +31 183 634730 >> Fax: +31 183 690113 >> Cell: +31 654 323221 >> Email: [email protected] >> Web: http://www.nefkensadvies.nl/ >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: green.gif >> Type: image/gif >> Size: 87 bytes >> Desc: not available >> Url : >> http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/eff03770/attachment-0001.gif >> -------------- next part -------------- >> Think before you print. >> >> >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Sat, 16 May 2009 16:00:44 +0530 >> From: Dnyaneshwar Gore <[email protected]> >> Subject: [OSL | CCIE_Security] Global & Interface policy precedence >> To: [email protected], [email protected] >> Message-ID: >> <[email protected]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi, >> >> I am referring to ASA ver 8.0 config guide. On page 16-23, it is mentioned >> that "Interface service policies take precedence over the global service >> policy for a given feature." >> >> But on page 25-5, they are saying "For example, if you configure standard >> priority queueing for the global policy, and then configure traffic >> shaping >> for a specific interface, the feature you configured last is rejected >> because the global policy overlaps the interface policy." >> >> Here contradictory explanation is given for interface policy and global >> policy implementation on interface. >> >> Kindly help me to understand this. >> >> Regards, >> D.M.Gore >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/0b23cabe/attachment-0001.htm >> >> ------------------------------ >> >> Message: 5 >> Date: Sat, 16 May 2009 16:20:53 +0100 >> From: Stuart Hare <[email protected]> >> Subject: [OSL | CCIE_Security] IOS FW Stateful redundancy >> To: OSL Security <[email protected]>, Cisco >> certification <[email protected]> >> Message-ID: >> <[email protected]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> >> Im currently labbing up IOS firewall redundancy. >> >> I have 2 routers R2 & R4 setup for this and although everythings seem to >> work ok I have one small issue. >> When I shut an interface to test the failover, it failovers over as >> expected >> but R2 (the primary device) proceeds to reload itself. >> >> R2(config)#int vlan 246 >> R2(config-if)#sh >> R2(config-if)# >> *May 16 15:42:28.375: %HSRP-5-STATECHANGE: Vlan246 Grp 246 state Active -> >> Init >> *May 16 15:42:28.375: %TRACKING-5-STATE: 1 interface Vl246 line-protocol >> Up->Down >> *May 16 15:42:29.015: %HSRP-5-STATECHANGE: Vlan24 Grp 24 state Active -> >> Speak >> *May 16 15:42:29.015: %RF_INTERDEV-4-RELOAD: % RF induced self-reload. my >> state = ACTIVE peer state = STANDBY HOT >> R2(config-if)# >> *May 16 15:42:29.331: %RF-5-RF_RELOAD: Peer reload. Reason: >> R2(config-if)# >> >> Once R2 comes back up and becomes the active device then R4 reloads >> itself. >> >> Is this a default feature of SSO/IPC? If so is there a cmd that prevents >> this action? >> Or is this a bug? >> >> For reference I used the following guide to configure this: >> http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_sfo.html#wp1164398 >> >> Cheers >> Stu >> >> -- >> Stuart Hare >> >> [email protected] >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/1b2956af/attachment-0001.htm >> >> ------------------------------ >> >> Message: 6 >> Date: Sat, 16 May 2009 16:40:33 +0100 >> From: Stuart Hare <[email protected]> >> Subject: [OSL | CCIE_Security] FPM >> To: OSL Security <[email protected]>, Cisco >> certification <[email protected]> >> Message-ID: >> <[email protected]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Ive been going over the guides for Access Control and Flexible Pattern >> Matching. >> Although theres good info around how to configure this, I cant find >> anything >> that explains the thought process or logic for the patterns or the offsets >> used to classify the traffic. >> >> Is there a decent doc that explains this or can someone shed some light on >> this for me please? >> >> Many thanks >> Stu >> >> -- >> Stuart Hare >> >> [email protected] >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/f2515ff9/attachment-0001.htm >> >> End of CCIE_Security Digest, Vol 35, Issue 28 >> ********************************************* >> > > -- Stuart Hare [email protected]
