I noticed the following problems when using FW MC;
would like to know if it is normal or if I missed something :
a) when modifying interface name (under device settings), the existing rules are not modified to reflect this change in the source I/F name ; this cause, of course, errors on generate config step ; is the interface name a non-modifiable field ?
2) object-group definitions and reference (inside rules) are well reflected into the PIX VMS-generated configuration when these are network object-group ;
but for the service object groups, the PIX VMS-generated configuration shows only the numerical UDP/TCP port values in the rules and no service object-group is generated ; this is not very convenient if you want to control, in some way, the VMS rules to the VMS-generated PIX config, or if you want to use this PIX config, as an object base to help migration from CSPM to VMS
a) It's an issue we're tracking as a bug, CSCsa06605. Some settings that refer to interface names cause generation errors when the interface is renamed or removed. These settings must be deleted or changed to reference the new name.
These settings refer to interfaces and must be changed to use the new name are as follows:
*ICMP Interface Rules
*URL Filter Server
To work around this problem, delete the settings resulting in generation errors or modify the settings to reflect the new interface name.
Unfortunately, we were not able to address this issue in our next release, v1.3. However, this issue is on our short list and will be addressed in a following release.
b) Service Groups were not fully supported in Firewall MC 1.2 and were flattened on import. We have addressed this issue in our next release, v1.3.
a) you don't refer the Access Rules in your previous list; this is the main concern because it means all these rules should be modified to reflect the new interface name
b) I noticed another case about generated rules in the PIX configuration :
the network object-group are referred ONLY in the acess rules applied to the inside interface, but not on the other interfaces, where they are replaced by the associated IP addresses and masks ;
this problem does not appear if you copy/paste, via FW MC access rules panel, all the rules on a 2nd PIX ; in this case, the rules generated for this 2nd PIX refer the network object-rules on all interfaces ;
if you do some modifications, via FW MC, on the rules of this 2nd PIX, same problem reappears ;
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...