Showing posts with label cisco. Show all posts
Showing posts with label cisco. Show all posts
Tuesday, November 27, 2012
FWSM supported with 15.1(1)SY on VS-S720-10G in VSS mode
Cisco does not seem to keep public changelogs of its release notes. The ones of IOS 15.1(1)SY for Catalyst 6500 just got updated to state that the FWSM is indeed supported with this software version on VS-S720-10G (Sup720-10GE) in VSS mode. The previous revision said that only non-VSS mode is supported.
Labels:
catalyst 6500,
cisco,
ios
Location:
Karlsruhe, Germany
Thursday, November 1, 2012
More IPv6 features on Cat6500 and ASA
Cisco published the unified Sup720/Sup2T 15.1SY release which brings features like OSPFv3 IPsec authentication, OSPFv3 VRF-lite, EIGRP IPv6 VRF-lite, RA guard and RADIUS/TACACS+/TFTP over IPv6 to Sup720 and IPv6 PBR in hardware to Sup2T.
For the ASA release 9.0 was made available, which (finally) includes features like DHCPv6 Relay, OSPFv3, Unified ACLs, IPv6 ranges, IPv6 for VPN, NAT64 and IPv6 NAT.
For more see the linked release notes. Also be careful what chassis types are supported by 15.1SY on the Catalyst 6500 if you have a support contract. I can confirm that it does boot on VS-S720-10G in a WS-C6509-NEB-A chassis even though it is not listed, but it is possible that Cisco refuses support for this combination.
For the ASA release 9.0 was made available, which (finally) includes features like DHCPv6 Relay, OSPFv3, Unified ACLs, IPv6 ranges, IPv6 for VPN, NAT64 and IPv6 NAT.
For more see the linked release notes. Also be careful what chassis types are supported by 15.1SY on the Catalyst 6500 if you have a support contract. I can confirm that it does boot on VS-S720-10G in a WS-C6509-NEB-A chassis even though it is not listed, but it is possible that Cisco refuses support for this combination.
Labels:
catalyst 6500,
cisco,
cisco asa,
ipv6
Location:
Karlsruhe, Germany
Wednesday, September 26, 2012
IPv6 neighbor discovery on Nexus 7000
If you attach multiple devices directly to a Nexus 7000 switch and expect them to communicate with each other over IPv6 in the same VLAN, you really want to set no ip igmp snooping optimise-multicast-flood. Otherwise they can communicate with the L3 interface on the switch, but not with the others. All your attempts to do neighbor discovery fail, as this runs over multicast and non-IPv4 multicast is dropped due to this setting. Sadly it's on by default, so you need to apply this fix on any Nexus 7k where you want to do serious IPv6 switching on.
Labels:
cisco,
cisco nexus 7000,
ipv6
Location:
Karlsruhe, Germany
Friday, September 21, 2012
IPv6 PBR on Catalyst 6500
The lesson of the day is: Better avoid IPv6 PBR on Cisco Catalyst 6500. It will be handled in software on Sup720/VSS720 if you assign a policy route-map to a Switch Virtual Interface (SVI) according to the documentation. Which only leaves routed ports as ones where hardware switching is supposed to happen. L3 VLAN interfaces and sub-interfaces are both SVIs and hence all IPv6 traffic that matches the PBR rules will be punted to the RP. The Sup2T supervisor does not support IPv6 PBR at all at this time.
Labels:
catalyst 6500,
cisco,
ipv6,
pbr
Location:
Karlsruhe, Germany
Sunday, November 20, 2011
Slots on Cisco ASA 5550
According to the Cisco product description of the ASA 5550 the appliance has a maximal throughput of "up to 1.2 Gbps". It's pretty common for Cisco to measure throughput in interesting ways. Mostly they'll add up RX and TX and mention the combined bandwidth. In this case this means that you're likely to be capped at somewhere around 600 Mbps of bi-directional traffic.
One thing you really have to watch out for, to get more out of that particular appliance, is balancing the traffic across its two slots. You can issue show traffic on the CLI which gives you the current balance at the end of its output. If you're just using one of the two slots and your CPU usage is at 100% you'll experience packet loss despite the fact that there's still some free capacity. It seems that the CPU is blocked too much waiting for the queues to get free at this point, when trying to send back traffic to where it came from. Using both slots the CPU usage went back to 50% which seems much more reasonable.
One thing you really have to watch out for, to get more out of that particular appliance, is balancing the traffic across its two slots. You can issue show traffic on the CLI which gives you the current balance at the end of its output. If you're just using one of the two slots and your CPU usage is at 100% you'll experience packet loss despite the fact that there's still some free capacity. It seems that the CPU is blocked too much waiting for the queues to get free at this point, when trying to send back traffic to where it came from. Using both slots the CPU usage went back to 50% which seems much more reasonable.
Labels:
cisco,
cisco asa,
cisco asa 5550,
cpu usage
Location:
Karlsruhe, Germany
Subscribe to:
Posts (Atom)