We have noticed that when the Netrangers are updating ACLs on our 6500's and when that happens we drop packets. Here is our take on what is happening;
Netranger telnets in, applies the ACL to the interface and then begins to write the access-list. Because the ACL is already applied to the interface the permit IP any any is not considered to be in the ACL and is denying traffic until the list is completed.
Has anyone seen this? Is this supposed to happen? I understand the implication that security may be more important than traffic but with 2 different ACLs switching back and forth you would think that this problem could be avoided. I am not sure if this is configurable, if it is please help :)...
This is a problem first diagnosed in version 2.1.1 of NetRanger.
Managed would ONLY use ACL 199 for configuring the router.
In version 2.2.1and version 2.5 (may also have been in 2.2.0), managed was upgraded to alternate between 2 ACLs (199 and 198 by default).
When managed would telnet into the router it will automatically create ACL 199 and then apply it to the interface/direction. Then when a change was made it would create ACL 198 and then apply 198 to the interface/direction and remove ACL 199.
This worked fairly well in concept until you realize that managed will ALWAYS start with ACL 199. The sensor can wind up in the following situation:
Since the sensor alternates between 199 and 198 it is possible to stop the sensor while ACL 199 is applied on the router.
Then when the sensor is restarted, managed will begin by creating ACL 199, but since it is already applied you run into the same problem as we did back in 2.1.1.
In version 3.0 coming out this summer, managed is switching from numbered ACLs to named ACLs, and will alternate between 2 named ACLs for each interface/direction. It is also being built so that on startup it will check to see if an ACL is already being used, and if so then it will alternate to the other name; in order to keep the startup problem described above from happening.
So keep an eye out for 3.0 this summer, and this problem should be fixed.
Actually this is not the problem that we are seeing. The ACLs (198 and 199) are cycling back and forth but it looks like the ACL is being created AFTER it has been applied to the interface. We have verified this by logging into the router and actually watching the ACL get created, line by line, by repeating the sh access-list 198 (or 199) command after verifying that the ACL that we are looking at is the one applied to the interface.
On a side-note, I have heard some fairly magical things concerning this 3.0 code. In fact it has been the answer to almost every TAC case that I have opened up in the last 3 months. I believe it is slated to come out this month, any thoughts on when I can get my hands on it?
I will test the 2.5 and 3.0 managed to see if I can replicate your problem. 3.0 general availability will be the middle of this summer (mid July timeframe I would suspect). If the issue is resolved in 3.0 then I can talk to management about possibly sending you a Beta version.
I was able to replicate your problem using version 2.5(1)S2 of the sensor. The managed application was not updating the router properly when multiple shuns were happening in short time periods. As the router was being updated, managed would begin a second update. Managed owuld become confused and wind up applying partial or incomplete ACLs.
This was also noticed in initial 3.0 managed testing from a few weeks ago. The issue has been addressed in recent test versions, and the problem has not been reproducible in the lab with the last 3 or so test versions.
I was told by management to have you contact the TAC about this issue. Let the TAC know that we have diagnosed the problem and we believe it addressed in the 3.0 version. And that we asked you to go through the TAC to request to be a 3.0 EFT site. Our management team can then send to the TAC the appopriate forms and documentation to make you an EFT site for the 3.0 version for managed.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :