On Wed, Mar 17, 2010 at 08:58:09PM +0000, Peter Rathlev wrote:
Q: IPv6 auto-configuration on p-t-p core links: Good or bad idea? I
guess the downside is comparable to using RFC1918 addresses on Internet
core router's interfaces, where e.g. traces break.
Every ipv6 link has a link-local configured with SLAAC. I don't think
this is what you mean though?
Q: We run an MPLS VPN network, global routing only used for management.
According to this document (which should also cover 12.2SX):
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-ov_mpls_6vpe.html#wp1054029
6VPE supports an MPLS IPv4-signaled core. An MPLS IPv6-signaled core
is not supported.
We have to keep an IPv4 core then? I guess the important part is to
enable IPv6 for the users and services, but (excuse my french) it seems
a little half-assed to not support an IPv6 core. Especially MPLS being
what it is.
You can *run* IPv6 in the default VRF; you just can't do LDP over ipv6,
or transport vpnv4/vpnv6 over ipv6 BGP peerings.
Q: Should our initial "test phase" with IPv6 be accomplished using
FE00::/7 local addresses (as per RFC 4193), or should we just aim at
starting out with globally unique addresses? (I assume they're almost
trivial to apply for and have allocated.)
Go for real space.
Q: We almost only use 6500/Sup720 (12.2(33)SXI) and 3560/3750
(12.2(5n)SEn). According to Cisco's IPv6 technology white paper
http://www.cisco.com/en/US/technologies/collateral/tk648/tk872/tk373/technologies_white_paper_09186a00802219bc.html
we should be okay. Are all relevant management stuff IPv6-ready? TACACS
+, NetFlow (C6k FTW!), SSH, syslog, SNMPv3 et cetera.
Much of it will *handle* IPv6 but not run over it e.g. I don't think you
can export netflow over v6, but you will see v6 flows.
SNMP & SSH will accept v6 PDUs.
There isn't 100% parity, but it's improving.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
