Philipp Kern's networking blog
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
Friday, October 19, 2012
IPv6 deployment at a university and research organization (German slides)
I presented our IPv6 deployment at Karlsruhe Institute of Technology at a meeting of the Benutzergruppe Netzwerke today. I touched the subjects of mentality, security, addressing concepts, and hardware feature sets. No device we use satisfies all our wishes that we have, feature-wise. The slides are available, however be aware that they are in German.
Location:
Horst, Essen, 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
Saturday, June 9, 2012
Google's IPv6 blacklist
If you're not seeing AAAA records for Google's main services, then your DNS resolver might be blacklisted. It seems that Google tries to measure the penalty IPv6 imposes on their users and employs retaliation if it's not happy with it. Sadly they won't contact the affected networks and just stuff the address onto this list. There's also no rationale why that happened. It seems that one can ask google-ipv6@google.com and get a reply, though.
It also seems that this list is perused by other entities like Akamai and Facebook, because people on the blacklist report that the AAAA records of those providers vanished for them, too. The whole discussion thread can be found in the ipv6-ops archives.
It also seems that this list is perused by other entities like Akamai and Facebook, because people on the blacklist report that the AAAA records of those providers vanished for them, too. The whole discussion thread can be found in the ipv6-ops archives.
Location:
Karlsruhe, Germany
Sunday, March 11, 2012
ECN and D-Link switches
Apparently even today manufacturers of network devices fail to cope with technologies introduced a decade ago. If your host has ECN enabled unconditionally, D-Link switches won't let you connect to their web interface. At least the DGS-1210-16 I have here won't. With the newest firmware, too.
Now of course this is my own fault, given that I've switched the ECN mode away from the default "ECN server mode", i.e. advertise it, but don't use it for client connections, to "Use ECN". Still, given that RFC 3168 dates back to 2001, one would assume that network endpoints can deal with those bits (ECN and CWR) being set now. Especially as the RFC tells how to decline the usage of ECN when being the server. Instead you get back a TCP reset (RST=1, ACK=1). Thank you very much, D-Link.
Now of course this is my own fault, given that I've switched the ECN mode away from the default "ECN server mode", i.e. advertise it, but don't use it for client connections, to "Use ECN". Still, given that RFC 3168 dates back to 2001, one would assume that network endpoints can deal with those bits (ECN and CWR) being set now. Especially as the RFC tells how to decline the usage of ECN when being the server. Instead you get back a TCP reset (RST=1, ACK=1). Thank you very much, D-Link.
Location:
Karlsruhe, Germany
Subscribe to:
Posts (Atom)