IPv6 Operations

Ranganath Hande | 25 Jun 2012 19:14

discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

Looks like there is some discussion going on related to - Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity. This issue is interesting. Here is some more info...:)

It is fairly common for RP utilization to go up initially when either v4 or v6 internet BGP peer comes up first time--due to large number of BGP prefixes that router has to process. In case of v6, impact is more visible as resource utilization is 4 times higher. Possible solutions are --

· FIB/TCAM scaling (mls cef max-routes)

· Limiting/filtering BGP learned prefixes (For IPv6 - limit to /32 or /48)

· Avoid using VRF for full internet route table as VRFs have lower default resource allocations than global table and cannot scale much. In case full IPv6 internet routes are needed downstream and you have MPLS backbone, use 6PE for internet routes and 6VPE for IPv6 MPLS VPNs.

· If full internet route table is not really needed -- negotiate with upstream ISP to send only 'default+backbone or customer' routes.

· Shop for bigger router periodically as Internet route table grows --costs more as it needs more money.

Thank you,

Ranga

headers

Mikael Abrahamsson | 26 Jun 2012 07:36

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

On Mon, 25 Jun 2012, Ranganath Hande wrote:

> It is fairly common for RP utilization to go up initially when either v4 
> or v6 internet BGP peer comes up first time--due to large number of BGP 
> prefixes that router has to process. In case of v6, impact is more 
> visible as resource utilization is 4 times higher. Possible solutions 
> are --

In case of PFC3B(-XL), this is also of interest once IPv6 traffic is 
flowing:

<http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html>

PFC3B will by default punt IPv6 packets with fragmentation header to RP
and route them there, with the obvious performance penalty this incurs.

Workaround is to change this behaviour, meaning ACLs won't work for
packets with fragmentation header anymore:

    #platform ipv6 acl fragment hardware ?
      drop     Drop IPv6 fragments at hardware
      forward  Forward IPv6 fragments at hardware

PFC3C is supposed to not be affected.

--

-- 
Mikael Abrahamsson    email: swmike <at> swm.pp.se

headers

Michael Adams | 26 Jun 2012 09:33

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

Hi!

Am 26.06.2012 07:36, schrieb Mikael Abrahamsson:

> In case of PFC3B(-XL), this is also of interest once IPv6 traffic is flowing:
> 
> <http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html>
> 
> PFC3B will by default punt IPv6 packets with fragmentation header to RP
> and route them there, with the obvious performance penalty this incurs.

Is this behavior depending on using not not using ACL's?

Michael

--

-- 
Michael Adams                                  Tel: +49 221 2222 657
Network Engineering&  Design                   Fax: +49 221 2222 7657
NetCologne                                     Geschäftsführer
Gesellschaft für Telekommunikation mbH         Dr. Hans Konle (Sprecher)
Am Coloneum 9                                  Dipl.-Ing. Karl-Heinz Zankel
50829 Köln                                     HRB 25580, Amtsgericht Köln

headers

Michael Adams | 26 Jun 2012 09:50

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

Am 26.06.2012 09:33, schrieb Michael Adams:
> Hi!
> 
> Am 26.06.2012 07:36, schrieb Mikael Abrahamsson:
> 
>> In case of PFC3B(-XL), this is also of interest once IPv6 traffic is flowing:
>>
>> <http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html>
>>
>> PFC3B will by default punt IPv6 packets with fragmentation header to RP
>> and route them there, with the obvious performance penalty this incurs.
> 
> Is this behavior depending on using not not using ACL's?

Oops. s/not not/or not/

Is this behavior depending on using or not using ACL's?

Michael

--

-- 
Michael Adams                                  Tel: +49 221 2222 657
Network Engineering&  Design                   Fax: +49 221 2222 7657
NetCologne                                     Geschäftsführer
Gesellschaft für Telekommunikation mbH         Dr. Hans Konle (Sprecher)
Am Coloneum 9                                  Dipl.-Ing. Karl-Heinz Zankel
50829 Köln                                     HRB 25580, Amtsgericht Köln

headers

Nick Hilliard | 26 Jun 2012 10:54

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

On 26/06/2012 08:50, Michael Adams wrote:
> Is this behavior depending on using or not using ACL's?

no, it's a hardware limitation of the pfc3b, independent of ACL handling.

Nick

headers

Jared Mauch | 26 Jun 2012 16:10

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

On Jun 26, 2012, at 1:36 AM, Mikael Abrahamsson wrote:

> In case of PFC3B(-XL), this is also of interest once IPv6 traffic is flowing:
> 
> <http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html>
> 
> PFC3B will by default punt IPv6 packets with fragmentation header to RP
> and route them there, with the obvious performance penalty this incurs.
> 
> Workaround is to change this behaviour, meaning ACLs won't work for
> packets with fragmentation header anymore:
> 
>   #platform ipv6 acl fragment hardware ?
>     drop     Drop IPv6 fragments at hardware
>     forward  Forward IPv6 fragments at hardware
> 
> PFC3C is supposed to not be affected.

I'm once again reminded of something I observed.  Make sure you disable ipv6 redirects on all interfaces. 
This has significant performance penalty.  On 6500/sup720 this should be easy to do with interface range command.

- jared

headers

Bernhard Schmidt | 26 Jun 2012 16:24

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

Am 26.06.2012 16:10, schrieb Jared Mauch:

> I'm once again reminded of something I observed.  Make sure you
> disable ipv6 redirects on all interfaces.  This has significant
> performance penalty.  On 6500/sup720 this should be easy to do with
> interface range command.

Funky. Is this only the case with non-standard configurations like
multiple subnets on one interface?

There was also an interesting message on cisco-nsp recently about
tweaking ND timers when having a lot of direct neighbors.

Regards,
Bernhard

headers

Jared Mauch | 26 Jun 2012 16:27

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

On Jun 26, 2012, at 10:24 AM, Bernhard Schmidt wrote:

> Am 26.06.2012 16:10, schrieb Jared Mauch:
> 
>> I'm once again reminded of something I observed.  Make sure you
>> disable ipv6 redirects on all interfaces.  This has significant
>> performance penalty.  On 6500/sup720 this should be easy to do with
>> interface range command.
> 
> Funky. Is this only the case with non-standard configurations like
> multiple subnets on one interface?

No.  It was odd and I didn't collect too much data on this.  It led me
to push back against those at vendors who didn't view redirects as harmful.

Its easier to just forward/recirc the packet.  I wonder if this was related
to the performance hit observed.

- Jared

headers

Phil Mayers | 26 Jun 2012 16:30

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

On 26/06/12 15:10, Jared Mauch wrote:

> I'm once again reminded of something I observed.  Make sure you
> disable ipv6 redirects on all interfaces.  This has significant
> performance penalty.

How is it any different to IPv4 redirects?

headers

Kurt Jaeger | 26 Jun 2012 16:35

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

Hi!

> > I'm once again reminded of something I observed.  Make sure you
> > disable ipv6 redirects on all interfaces.  This has significant
> > performance penalty.
> 
> How is it any different to IPv4 redirects?

Good question, but the issue of ipv6 redirects caused some
issues on the regional internet exchange (http://www.s-ix.info/)
as well. Recommended policy is now: disable ipv6 redirects.

--

-- 
pi <at> opsec.eu            +49 171 3101372                         8 years to go !

headers

Ranganath Hande | 26 Jun 2012 18:36

RE: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

Agreed...Punting is specifically hardware related issue - applicable to the 3A, 3B, and 3BXL PFC/DFC
daughter cards.  Verify punts using - "sh tcam global acl in ipv6" command.  Workaround is using "platform
ipv6 acl fragment hardware" command and  is specific to the 6500/7600. The command enables the ipv6
fragements to be forwarded in HW with some tradeoff to ACL activity.  Per Cisco - this was corrected in the 3C
daughtercard.  

Thank you,

Ranga 

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike <at> swm.pp.se] 
Sent: Monday, June 25, 2012 10:36 PM
To: Ranganath Hande
Cc: ipv6-ops <at> lists.cluenet.de
Subject: Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity

On Mon, 25 Jun 2012, Ranganath Hande wrote:

> It is fairly common for RP utilization to go up initially when either 
> v4 or v6 internet BGP peer comes up first time--due to large number of 
> BGP prefixes that router has to process. In case of v6, impact is more 
> visible as resource utilization is 4 times higher. Possible solutions 
> are --

In case of PFC3B(-XL), this is also of interest once IPv6 traffic is
flowing:

<http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html>

PFC3B will by default punt IPv6 packets with fragmentation header to RP and route them there, with the
obvious performance penalty this incurs.

Workaround is to change this behaviour, meaning ACLs won't work for packets with fragmentation header anymore:

    #platform ipv6 acl fragment hardware ?
      drop     Drop IPv6 fragments at hardware
      forward  Forward IPv6 fragments at hardware

PFC3C is supposed to not be affected.

--

-- 
Mikael Abrahamsson    email: swmike <at> swm.pp.se