Mailing List Archive: nsp: ipv6

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

Index | Next | Previous | View Threaded

rangha at microsoft

Jun 25, 2012, 10:14 AM

Post #1 of 11 (752 views)
Permalink

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

swmike at swm

Jun 25, 2012, 10:36 PM

Post #2 of 11 (711 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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

madams at netcologne

Jun 26, 2012, 12:33 AM

Post #3 of 11 (712 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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

madams at netcologne

Jun 26, 2012, 12:50 AM

Post #4 of 11 (712 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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

nick at foobar

Jun 26, 2012, 1:54 AM

Post #5 of 11 (710 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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

jared at puck

Jun 26, 2012, 7:10 AM

Post #6 of 11 (716 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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

berni at birkenwald

Jun 26, 2012, 7:24 AM

Post #7 of 11 (710 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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

jared at puck

Jun 26, 2012, 7:27 AM

Post #8 of 11 (709 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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

p.mayers at imperial

Jun 26, 2012, 7:30 AM

Post #9 of 11 (713 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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?

ipv6-ops at c0mplx

Jun 26, 2012, 7:35 AM

Post #10 of 11 (714 views)
Permalink

Re: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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 +49 171 3101372 8 years to go !

rangha at microsoft

Jun 26, 2012, 9:36 AM

Post #11 of 11 (727 views)
Permalink

RE: discussion: Enabling IPv6 on Cisco 6500/7600 breaks IPv4 Internet connectivity [In reply to]

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]
Sent: Monday, June 25, 2012 10:36 PM
To: Ranganath Hande
Cc: ipv6-ops [at] lists
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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads