Re: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread Andrew Jones 
Even if the first numbers were correctly calculated, they don't allow 
for further deaggregation of already advertised prefixes, which 
shouldn't be underestimated as the commercial value of each address 
increases...



On 10.06.2014 06:17, Bryan Tong wrote:

I botched those numbers.

Let me fix.

According to this countdown:
http://inetcore.com/project/ipv4ec/index_en.html we have 6.41 /8's 
left. So

that is 107,541,955 IPs.

CIDR - Prefixes
-
/20 - 26,255.36
/21 - 52,510.72
/22 - 105,021.44
/23 - 210,042.88
/24 - 420,085.76

My apologies for my erroneous math, I was off one number making the 
table.


Johns solution to combine MPLS and IPv4 is the best solution. I would
implement it if I hadn't already rebooted a few days ago.

RE: L3/HE/Inbound Pathing Question

2014-06-09 Thread Brandon Lehmann 
If you're not familiar with how you can engineer traffic on L3's network
take a peek at
http://www.scn.rain.com/~neighorn/PDF/Traffic_Engineering_with_BGP_and_Level
3.pdf (slightly outdated but still useful)

As far as HE is concerned, when I asked them about communities a few weeks
ago all they could offer was a blackhole community.

However, as Jay said, you're likely at the mercy of the blended provider and
what they support.

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jay Hennigan
> Sent: Monday, June 09, 2014 3:10 PM
> To: nanog@nanog.org
> Subject: Re: L3/HE/Inbound Pathing Question
> 
> On 6/9/14 9:38 AM, Dennis Burgess wrote:
> > I have ran into this a few times, and have not found a solution:
> >
> > L3 à
> >
> > HEà  --- blended Provider A --- > Customer
> >
> > Cogent -- > Customer
> >
> > Cogent of course is cheaper, and customer wishes to use the blended
> provder more as backup and/or have most of the inbound traffic coming
> in the cheaper path (cogent).  The issue appears to be L3 and HE
> specifically (of course they make up a good chunk of inbound traffic)
> always prefers their customer peers, so even if we advertise any prefix
> to the blended, those companies (l3/he) always choose to come in though
> the customer peer and then to my customer.
> >
> > Any thoughts on how to get around this, and still have some kind of
> route in the blended provider for failover?Off list is fine..
> Thanks in advance.
> 
> Advertise a community to the other providers to localpref your prefixes
> down to the point of being a backup.
> 
> 3356:70 should work for Level 3, you will need to talk to HE and/or
> your blended provider for what to use (and whether they support it).
> 
> 
> --
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
> Impulse Internet Service  -  http://www.impulse.net/ Your local
> telephone and internet company - 805 884-6323 - WB6RDV


smime.p7s
Description: S/MIME cryptographic signature

Re: question about bogon prefix

2014-06-09 Thread Robert Drake 


On 6/9/2014 11:00 PM, Song Li wrote:

Hi everyone,

I found many ISP announced bogon prefix, for example:

OriginAS Announcement Description
AS7018  172.116.0.0/24unallocated
AS209   209.193.112.0/20 unallocated

my question is why the tier1 and other ISP announce these unallocated 
bogon prefixes, and another interesting question is:


You could also ask why are other providers accepting the route, since I 
could announce 209.193.112.0/20 from my router and my upstream would 
reject it.


Of course, those two ASNs have a huge number of routes so they probably 
aren't filtered as closely by their peers.


But.. even if you're hyper diligent and blocking bogon routes, you'll 
need to ask yourself why it's not in the bogon list:


curl -s http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt | 
grep 209.193


It's also not on http://www.cymru.com/BGP/bogons.html but 172.116.0.0/24 is.

Now, according to this:
http://myip.ms/view/ip_addresses/3519115264/209.193.112.0_209.193.112.255

It belongs to the Franciscan Health System.  The one IP that is in DNS 
seems to back this up (it's called mercyvpn.org)


Whois Record created: 04 Jan 2005
Whois Record updated: 24 Feb 2012

My guess is one of two things.  Maybe they renumbered out of the /20 but 
left a VPN server up and haven't managed to migrate off it yet, but they 
have asked to return the block.. or, they forgot to pay their bill to 
ARIN and the block has been removed from whois but Qwest isn't as 
diligent because they're still being paid.


I've CC'd the technical contact listed in the old whois information so 
maybe he can get things corrected.


If I am ISP, can I announce the same bogon prefix(172.116.0.0/24) with 
AS7018 announced? Will this result in prefix hijacking?


Thanks!

I can find nothing on google that offers any legitimacy for 
172.116.0.0/24, but it is has been announced for 2 years so maybe there 
is some squatters rights at least.  It doesn't appear to be a spam 
source and I don't think any hosts are up on it right now. Maybe it's a 
test route that never got removed.  It makes me sad that nobody at ATT 
reads the CIDR report.  They've only got a couple of bogon announcements 
so it would be trivial for them to either acknowledge them and claim 
legitimacy or clean them up.

Re: question about bogon prefix

2014-06-09 Thread Christopher Morrow 
On Mon, Jun 9, 2014 at 11:00 PM, Song Li  wrote:
> Hi everyone,
>
> I found many ISP announced bogon prefix, for example:

sad, right?

> OriginAS Announcement Description
> AS7018  172.116.0.0/24  unallocated
> AS209   209.193.112.0/20 unallocated
>
> my question is why the tier1 and other ISP announce these unallocated bogon

OSS is hard.

> prefixes, and another interesting question is:
>
> If I am ISP, can I announce the same bogon prefix(172.116.0.0/24) with
> AS7018 announced? Will this result in prefix hijacking?
>

technically you are probably hijacking a hijack :( or something like that.

> Thanks!
>
> --
> Song Li
> Room 4-204, FIT Building,
> Network Security,
> Department of Electronic Engineering,
> Tsinghua University, Beijing 100084, China
> Tel:( +86) 010-62446440
> E-mail: refresh.ls...@gmail.com

question about bogon prefix

2014-06-09 Thread Song Li 

Hi everyone,

I found many ISP announced bogon prefix, for example:

OriginAS Announcement Description
AS7018  172.116.0.0/24  unallocated
AS209   209.193.112.0/20 unallocated

my question is why the tier1 and other ISP announce these unallocated 
bogon prefixes, and another interesting question is:


If I am ISP, can I announce the same bogon prefix(172.116.0.0/24) with 
AS7018 announced? Will this result in prefix hijacking?


Thanks!

--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com

Re: World Cup Streaming

2014-06-09 Thread Clinton Work 
CBC in Canada has just released details about their World Cup app. 
http://mobilesyrup.com/2014/06/09/cbcs-fifa-world-cup-2014-app-offers-live-matches-multi-angle-replays-scores-news-and-bios/

I heard that some of the broadcasters had privacy agreements with Akamai
which is why they wouldn't share event traffic predictions.   I reached
out to Akamai before the 2014 Winter Olympics and they wouldn't share
anything.  

-- 
Clinton Work
Airdrie, AB

On Sun, Jun 8, 2014, at 03:48 PM, Alvaro Pereira wrote:
> In Canada, the last Winter Olympic Games were streamed from
> olympics.cbc.ca
> (hosted by Akamai), which helped us find which upstream provider we would
> be getting the content from.
> 
> Does anyone know which hostname will be used for the cbc.ca World Cup
> streaming?
> 
> Thanks,
> 
> Alvaro Pereira
> 
> 
> On Sun, Jun 8, 2014 at 11:48 AM, Paul Stewart 
> wrote:
> 
> > Thank you.
> >
> > I’m actually based in Canada and there is a strong following of Soccer here
> > :)
> >
> > Akamai will be doing the streaming here (not sure about the US or other
> > countries).  I have reached out to them in the past to ask questions about
> > anticipated volumes and they never answer with details.
> >
> > Thanks,
> > Paul
> >
> >
> > From:  Rubens Kuhl 
> > Date:  Sunday, June 8, 2014 at 12:57 PM
> > To:  Paul Stewart 
> > Cc:  Nanog 
> > Subject:  Re: World Cup Streaming
> >
> > >
> > > Sports events have their rights sold on per country basis; this leads to
> > some
> > > fragmentation of those numbers as network X has the rights for country 1,
> > > network Y for country 2, and they account their numbers separate even if
> > they
> > > use the same CDN.
> > >
> > > Considering Soccer (or Football as we non-US call it) is not so popular
> > in the
> > > US, my guess (not an estimate) is for traffic levels for the US network
> > that
> > > carries the World Cup online to not be as high as Summer and/or Winter
> > > Olympics.
> > >
> > > What we have pretty good educated estimates is for 2014 World Cup
> > streaming to
> > > Brazil to be higher in volume than what was seen in the Olympics
> > streaming to
> > > the US.
> > >
> > > Rubens
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Jun 8, 2014 at 12:11 PM, Paul Stewart 
> > wrote:
> > >> Hey folks
> > >>
> > >> One part of capacity planning that is always challenging at times with
> > >> various providers I have worked with is determining the traffic levels
> > >> required for upcoming events such as World Cup.  Obviously there is
> > >> speculation and it varies dependent on the provider, their geography,
> > and
> > >> size of eyeball/downstream eyeball customers.
> > >>
> > >> Is there any resources out there other than news articles that provide
> > for a
> > >> reasonable estimation as to how much impact World Cup will have for
> > example?
> > >> I’ve heard offline from some folks that put World Cup at greater traffic
> > >> levels than the recent Olympics for example but have no way to know if
> > that
> > >> is a pure guess or an educated estimate.
> > >>
> > >> I am assuming that the CDN’s involved have some pretty accurate ideas on
> > >> what to expect but in the past I have not been able to get feedback from
> > >> them with any specific estimations.
> > >>
> > >> Thanks,
> > >>
> > >> Paul
> > >>
> > >>
> > >>
> > >
> >
> >
> >


-- 
Clinton Work
Airdrie, AB

Re: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread Bryan Tong 
I botched those numbers.

Let me fix.

According to this countdown:
http://inetcore.com/project/ipv4ec/index_en.html we have 6.41 /8's left. So
that is 107,541,955 IPs.

CIDR - Prefixes
-
/20 - 26,255.36
/21 - 52,510.72
/22 - 105,021.44
/23 - 210,042.88
/24 - 420,085.76

My apologies for my erroneous math, I was off one number making the table.

Johns solution to combine MPLS and IPv4 is the best solution. I would
implement it if I hadn't already rebooted a few days ago.

RE: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread John van Oppen 
Yep, exactly… the problem is the carving suggested by most kills the fact that 
MPLS and v4 are pooled, which on a larger network is very nice, especially if 
using 6PE where each v6 route may need an MPLS route too.

From: Bryan Tong [mailto:cont...@nullivex.com]
Sent: Monday, June 09, 2014 12:37 PM
To: John van Oppen
Cc: nanog@nanog.org
Subject: Re: FW: Getting pretty close to default IPv4 route maximum for 
6500/7600routers.

John, great point!

Regardless, shouldn't need more than 626K to make it to v6 and we wont need as 
many for v6. That was one of the problems that v6 was designed to address.

On Mon, Jun 9, 2014 at 1:27 PM, John van Oppen 
mailto:jvanop...@spectrumnet.us>> wrote:
It is generally much better to do the following:

mls cef maximum-routes ipv6 90
mls cef maximum-routes ip-multicast 1

This will leave v4 and mpls in one big pool, puts v6 to something useful for 
quite a while and steals all of the multicast space which is not really used on 
most deployments.


This gives us the following (which is pretty great for IP backbone purposes in 
dual stack):

#show mls cef maximum-routes
FIB TCAM maximum routes :
===
Current :-
---
 IPv4 + MPLS - 832k (default)
 IPv6- 90k
 IP multicast- 1k


John


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On 
Behalf Of Jon Lewis
Sent: Monday, June 09, 2014 12:10 PM
To: Pete Lumbis
Cc: nanog@nanog.org
Subject: Re: Getting pretty close to default IPv4 route maximum for 
6500/7600routers.

Why, in your example, do you bias the split so heavily toward IPv4 that the 
router won't be able to handle a current full v6 table?  I've been using

mls cef maximum-routes ip 768

which is probably still a little too liberal for IPv6

FIB TCAM maximum routes :
===
Current :-
---
  IPv4- 768k
  MPLS- 16k (default)
  IPv6 + IP Multicast - 120k (default)

given that a full v6 table is around 17k routes today.

A more important question though is how many 6500/7600 routers will fully 
survive the reload required to affect this change?  I've lost a blade 
(presumably to the bad memory issue) each time I've rebooted a 6500 to apply 
this.

On Mon, 9 Jun 2014, Pete Lumbis wrote:

> The doc on how to adjust the 6500/7600 TCAM space was just published.
>
> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie
> s-switches/117712-problemsolution-cat6500-00.html
>
>
> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis 
> mailto:alum...@gmail.com>> wrote:
>
>> There is currently a doc for the ASR9k. We're working on getting on
>> for
>> 6500 as well.
>>
>>
>> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg
>> regation-services-routers/116999-problem-line-card-00.html
>>
>>
>>
>>
>> On Tue, May 6, 2014 at 1:34 PM, 
>> mailto:bedard.p...@gmail.com>> wrote:
>>
>>> I would like to see Cisco send something out...
>>>
>>> -Original Message-
>>> From: "Drew Weaver" mailto:drew.wea...@thenap.com>>
>>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM
>>> To: "'nanog@nanog.org'" 
>>> mailto:nanog@nanog.org>>
>>> Subject: Getting pretty close to default IPv4 route maximum for
>>> 6500/7600routers.
>>>
>>> Hi all,
>>>
>>> I am wondering if maybe we should make some kind of concerted effort
>>> to remind folks about the IPv4 routing table inching closer and
>>> closer to the 512K route mark.
>>>
>>> We are at about 94/95% right now of 512K.
>>>
>>> For most of us, the 512K route mark is arbitrary but for a lot of
>>> folks who may still be running 6500/7600 or other routers which are
>>> by default configured to crash and burn after 512K routes; it may be
>>> a valuable public service.
>>>
>>> Even if you don't have this scenario in your network today; chances
>>> are you connect to someone who connects to someone who connects to
>>> someone
>>> (etc...) that does.
>>>
>>> In case anyone wants to check on a 6500, you can run:  show platform
>>> hardware capacity pfc and then look under L3 Forwarding Resources.
>>>
>>> Just something to think about before it becomes a story the
>>> community talks about for the next decade.
>>>
>>> -Drew
>>>
>>>
>>
>

--
  Jon Lewis, MCP :)   |  I route
  |  therefore you are _ 
http://www.lewis.org/~jlewis/pgp for PGP public key_



--
eSited LLC
(701) 390-9638

Re: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread Bryan Tong 
John, great point!

Regardless, shouldn't need more than 626K to make it to v6 and we wont need
as many for v6. That was one of the problems that v6 was designed to
address.


On Mon, Jun 9, 2014 at 1:27 PM, John van Oppen 
wrote:

> It is generally much better to do the following:
>
> mls cef maximum-routes ipv6 90
> mls cef maximum-routes ip-multicast 1
>
> This will leave v4 and mpls in one big pool, puts v6 to something useful
> for quite a while and steals all of the multicast space which is not really
> used on most deployments.
>
>
> This gives us the following (which is pretty great for IP backbone
> purposes in dual stack):
>
> #show mls cef maximum-routes
> FIB TCAM maximum routes :
> ===
> Current :-
> ---
>  IPv4 + MPLS - 832k (default)
>  IPv6- 90k
>  IP multicast- 1k
>
>
> John
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jon Lewis
> Sent: Monday, June 09, 2014 12:10 PM
> To: Pete Lumbis
> Cc: nanog@nanog.org
> Subject: Re: Getting pretty close to default IPv4 route maximum for
> 6500/7600routers.
>
> Why, in your example, do you bias the split so heavily toward IPv4 that
> the router won't be able to handle a current full v6 table?  I've been using
>
> mls cef maximum-routes ip 768
>
> which is probably still a little too liberal for IPv6
>
> FIB TCAM maximum routes :
> ===
> Current :-
> ---
>   IPv4- 768k
>   MPLS- 16k (default)
>   IPv6 + IP Multicast - 120k (default)
>
> given that a full v6 table is around 17k routes today.
>
> A more important question though is how many 6500/7600 routers will fully
> survive the reload required to affect this change?  I've lost a blade
> (presumably to the bad memory issue) each time I've rebooted a 6500 to
> apply this.
>
> On Mon, 9 Jun 2014, Pete Lumbis wrote:
>
> > The doc on how to adjust the 6500/7600 TCAM space was just published.
> >
> > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie
> > s-switches/117712-problemsolution-cat6500-00.html
> >
> >
> > On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis  wrote:
> >
> >> There is currently a doc for the ASR9k. We're working on getting on
> >> for
> >> 6500 as well.
> >>
> >>
> >> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg
> >> regation-services-routers/116999-problem-line-card-00.html
> >>
> >>
> >>
> >>
> >> On Tue, May 6, 2014 at 1:34 PM,  wrote:
> >>
> >>> I would like to see Cisco send something out...
> >>>
> >>> -Original Message-
> >>> From: "Drew Weaver" 
> >>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM
> >>> To: "'nanog@nanog.org'" 
> >>> Subject: Getting pretty close to default IPv4 route maximum for
> >>> 6500/7600routers.
> >>>
> >>> Hi all,
> >>>
> >>> I am wondering if maybe we should make some kind of concerted effort
> >>> to remind folks about the IPv4 routing table inching closer and
> >>> closer to the 512K route mark.
> >>>
> >>> We are at about 94/95% right now of 512K.
> >>>
> >>> For most of us, the 512K route mark is arbitrary but for a lot of
> >>> folks who may still be running 6500/7600 or other routers which are
> >>> by default configured to crash and burn after 512K routes; it may be
> >>> a valuable public service.
> >>>
> >>> Even if you don't have this scenario in your network today; chances
> >>> are you connect to someone who connects to someone who connects to
> >>> someone
> >>> (etc...) that does.
> >>>
> >>> In case anyone wants to check on a 6500, you can run:  show platform
> >>> hardware capacity pfc and then look under L3 Forwarding Resources.
> >>>
> >>> Just something to think about before it becomes a story the
> >>> community talks about for the next decade.
> >>>
> >>> -Drew
> >>>
> >>>
> >>
> >
>
> --
>   Jon Lewis, MCP :)   |  I route
>   |  therefore you are _
> http://www.lewis.org/~jlewis/pgp for PGP public key_
>



-- 
eSited LLC
(701) 390-9638

FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread John van Oppen 
It is generally much better to do the following:

mls cef maximum-routes ipv6 90
mls cef maximum-routes ip-multicast 1

This will leave v4 and mpls in one big pool, puts v6 to something useful for 
quite a while and steals all of the multicast space which is not really used on 
most deployments.


This gives us the following (which is pretty great for IP backbone purposes in 
dual stack):

#show mls cef maximum-routes 
FIB TCAM maximum routes :
===
Current :-
---
 IPv4 + MPLS - 832k (default)
 IPv6- 90k 
 IP multicast- 1k 


John


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jon Lewis
Sent: Monday, June 09, 2014 12:10 PM
To: Pete Lumbis
Cc: nanog@nanog.org
Subject: Re: Getting pretty close to default IPv4 route maximum for 
6500/7600routers.

Why, in your example, do you bias the split so heavily toward IPv4 that the 
router won't be able to handle a current full v6 table?  I've been using

mls cef maximum-routes ip 768

which is probably still a little too liberal for IPv6

FIB TCAM maximum routes :
===
Current :-
---
  IPv4- 768k
  MPLS- 16k (default)
  IPv6 + IP Multicast - 120k (default)

given that a full v6 table is around 17k routes today.

A more important question though is how many 6500/7600 routers will fully 
survive the reload required to affect this change?  I've lost a blade 
(presumably to the bad memory issue) each time I've rebooted a 6500 to apply 
this.

On Mon, 9 Jun 2014, Pete Lumbis wrote:

> The doc on how to adjust the 6500/7600 TCAM space was just published.
>
> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie
> s-switches/117712-problemsolution-cat6500-00.html
>
>
> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis  wrote:
>
>> There is currently a doc for the ASR9k. We're working on getting on 
>> for
>> 6500 as well.
>>
>>
>> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg
>> regation-services-routers/116999-problem-line-card-00.html
>>
>>
>>
>>
>> On Tue, May 6, 2014 at 1:34 PM,  wrote:
>>
>>> I would like to see Cisco send something out...
>>>
>>> -Original Message-
>>> From: "Drew Weaver" 
>>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM
>>> To: "'nanog@nanog.org'" 
>>> Subject: Getting pretty close to default IPv4 route maximum for 
>>> 6500/7600routers.
>>>
>>> Hi all,
>>>
>>> I am wondering if maybe we should make some kind of concerted effort 
>>> to remind folks about the IPv4 routing table inching closer and 
>>> closer to the 512K route mark.
>>>
>>> We are at about 94/95% right now of 512K.
>>>
>>> For most of us, the 512K route mark is arbitrary but for a lot of 
>>> folks who may still be running 6500/7600 or other routers which are 
>>> by default configured to crash and burn after 512K routes; it may be 
>>> a valuable public service.
>>>
>>> Even if you don't have this scenario in your network today; chances 
>>> are you connect to someone who connects to someone who connects to 
>>> someone
>>> (etc...) that does.
>>>
>>> In case anyone wants to check on a 6500, you can run:  show platform 
>>> hardware capacity pfc and then look under L3 Forwarding Resources.
>>>
>>> Just something to think about before it becomes a story the 
>>> community talks about for the next decade.
>>>
>>> -Drew
>>>
>>>
>>
>

--
  Jon Lewis, MCP :)   |  I route
  |  therefore you are _ 
http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread Bryan Tong 
The IPv6 table will not be as big as the v4 table even after full
acceptance. Given that most providers will be advertising a single /32 and
then rest will be some /48 routes for multi-homed scenarios.

My router looks like this

FIB TCAM maximum routes :
===
Current :-
---
 IPv4- 600k
 MPLS- 32k
 IPv6- 160k
 IP multicast- 32k

Probably a little heavy on MPLS considering we dont use it. With the
current level of exhaustion I dont think IPv4 will make it past 600k.

We are currently seeing 520,000 routes.

There are currently 107M IPs left globally.

If those all went to /21's that would require 26,255 prefixes.
If those all went to /22's that would require 52,510 prefixes.
If those all went to /24's that would require 105,021 prefixes.

So even the most conservative maximum should be no more than 626K





On Mon, Jun 9, 2014 at 1:09 PM, Jon Lewis  wrote:

> Why, in your example, do you bias the split so heavily toward IPv4 that
> the router won't be able to handle a current full v6 table?  I've been using
>
>
> mls cef maximum-routes ip 768
>
> which is probably still a little too liberal for IPv6
>
> FIB TCAM maximum routes :
> ===
> Current :-
> ---
>  IPv4- 768k
>  MPLS- 16k (default)
>  IPv6 + IP Multicast - 120k (default)
>
> given that a full v6 table is around 17k routes today.
>
> A more important question though is how many 6500/7600 routers will fully
> survive the reload required to affect this change?  I've lost a blade
> (presumably to the bad memory issue) each time I've rebooted a 6500 to
> apply this.
>
>
> On Mon, 9 Jun 2014, Pete Lumbis wrote:
>
>  The doc on how to adjust the 6500/7600 TCAM space was just published.
>>
>> http://www.cisco.com/c/en/us/support/docs/switches/
>> catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html
>>
>>
>> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis  wrote:
>>
>>  There is currently a doc for the ASR9k. We're working on getting on for
>>> 6500 as well.
>>>
>>>
>>> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-
>>> series-aggregation-services-routers/116999-problem-line-card-00.html
>>>
>>>
>>>
>>>
>>> On Tue, May 6, 2014 at 1:34 PM,  wrote:
>>>
>>>  I would like to see Cisco send something out...

 -Original Message-
 From: "Drew Weaver" 
 Sent: яя5/яя6/яя2014 11:42 AM
 To: "'nanog@nanog.org'" 
 Subject: Getting pretty close to default IPv4 route maximum for
 6500/7600routers.

 Hi all,

 I am wondering if maybe we should make some kind of concerted effort to
 remind folks about the IPv4 routing table inching closer and closer to
 the
 512K route mark.

 We are at about 94/95% right now of 512K.

 For most of us, the 512K route mark is arbitrary but for a lot of folks
 who may still be running 6500/7600 or other routers which are by default
 configured to crash and burn after 512K routes; it may be a valuable
 public
 service.

 Even if you don't have this scenario in your network today; chances are
 you connect to someone who connects to someone who connects to someone
 (etc...) that does.

 In case anyone wants to check on a 6500, you can run:  show platform
 hardware capacity pfc and then look under L3 Forwarding Resources.

 Just something to think about before it becomes a story the community
 talks about for the next decade.

 -Drew



>>>
>>
> --
>  Jon Lewis, MCP :)   |  I route
>  |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>



-- 
eSited LLC
(701) 390-9638

Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread Jon Lewis 
Why, in your example, do you bias the split so heavily toward IPv4 that 
the router won't be able to handle a current full v6 table?  I've been 
using


mls cef maximum-routes ip 768

which is probably still a little too liberal for IPv6

FIB TCAM maximum routes :
===
Current :-
---
 IPv4- 768k
 MPLS- 16k (default)
 IPv6 + IP Multicast - 120k (default)

given that a full v6 table is around 17k routes today.

A more important question though is how many 6500/7600 routers will fully 
survive the reload required to affect this change?  I've lost a blade 
(presumably to the bad memory issue) each time I've rebooted a 6500 to 
apply this.


On Mon, 9 Jun 2014, Pete Lumbis wrote:


The doc on how to adjust the 6500/7600 TCAM space was just published.

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html


On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis  wrote:


There is currently a doc for the ASR9k. We're working on getting on for
6500 as well.


http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html




On Tue, May 6, 2014 at 1:34 PM,  wrote:


I would like to see Cisco send something out...

-Original Message-
From: "Drew Weaver" 
Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM
To: "'nanog@nanog.org'" 
Subject: Getting pretty close to default IPv4 route maximum for
6500/7600routers.

Hi all,

I am wondering if maybe we should make some kind of concerted effort to
remind folks about the IPv4 routing table inching closer and closer to the
512K route mark.

We are at about 94/95% right now of 512K.

For most of us, the 512K route mark is arbitrary but for a lot of folks
who may still be running 6500/7600 or other routers which are by default
configured to crash and burn after 512K routes; it may be a valuable public
service.

Even if you don't have this scenario in your network today; chances are
you connect to someone who connects to someone who connects to someone
(etc...) that does.

In case anyone wants to check on a 6500, you can run:  show platform
hardware capacity pfc and then look under L3 Forwarding Resources.

Just something to think about before it becomes a story the community
talks about for the next decade.

-Drew








--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: L3/HE/Inbound Pathing Question

2014-06-09 Thread Jay Hennigan 
On 6/9/14 9:38 AM, Dennis Burgess wrote:
> I have ran into this a few times, and have not found a solution:
>
> L3 à 
> 
> HEà  --- blended Provider A --- > Customer
>  
> Cogent -- > Customer
> 
> Cogent of course is cheaper, and customer wishes to use the blended provder 
> more as backup and/or have most of the inbound traffic coming in the cheaper 
> path (cogent).  The issue appears to be L3 and HE specifically (of course 
> they make up a good chunk of inbound traffic) always prefers their customer 
> peers, so even if we advertise any prefix to the blended, those companies 
> (l3/he) always choose to come in though the customer peer and then to my 
> customer.
> 
> Any thoughts on how to get around this, and still have some kind of route in 
> the blended provider for failover?Off list is fine.. Thanks in advance.  

Advertise a community to the other providers to localpref your prefixes
down to the point of being a backup.

3356:70 should work for Level 3, you will need to talk to HE and/or your
blended provider for what to use (and whether they support it).


-- 
--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread Bryan Tong 
Just had to do this on my router last week. Came in a few mornings ago and
we were software switching, yay!


On Mon, Jun 9, 2014 at 12:30 PM, Pete Lumbis  wrote:

> The doc on how to adjust the 6500/7600 TCAM space was just published.
>
>
> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html
>
>
> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis  wrote:
>
> > There is currently a doc for the ASR9k. We're working on getting on for
> > 6500 as well.
> >
> >
> >
> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html
> >
> >
> >
> >
> > On Tue, May 6, 2014 at 1:34 PM,  wrote:
> >
> >> I would like to see Cisco send something out...
> >>
> >> -Original Message-
> >> From: "Drew Weaver" 
> >> Sent: ‎5/‎6/‎2014 11:42 AM
> >> To: "'nanog@nanog.org'" 
> >> Subject: Getting pretty close to default IPv4 route maximum for
> >> 6500/7600routers.
> >>
> >> Hi all,
> >>
> >> I am wondering if maybe we should make some kind of concerted effort to
> >> remind folks about the IPv4 routing table inching closer and closer to
> the
> >> 512K route mark.
> >>
> >> We are at about 94/95% right now of 512K.
> >>
> >> For most of us, the 512K route mark is arbitrary but for a lot of folks
> >> who may still be running 6500/7600 or other routers which are by default
> >> configured to crash and burn after 512K routes; it may be a valuable
> public
> >> service.
> >>
> >> Even if you don't have this scenario in your network today; chances are
> >> you connect to someone who connects to someone who connects to someone
> >> (etc...) that does.
> >>
> >> In case anyone wants to check on a 6500, you can run:  show platform
> >> hardware capacity pfc and then look under L3 Forwarding Resources.
> >>
> >> Just something to think about before it becomes a story the community
> >> talks about for the next decade.
> >>
> >> -Drew
> >>
> >>
> >
>



-- 
eSited LLC
(701) 390-9638

Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.

2014-06-09 Thread Pete Lumbis 
The doc on how to adjust the 6500/7600 TCAM space was just published.

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html


On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis  wrote:

> There is currently a doc for the ASR9k. We're working on getting on for
> 6500 as well.
>
>
> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html
>
>
>
>
> On Tue, May 6, 2014 at 1:34 PM,  wrote:
>
>> I would like to see Cisco send something out...
>>
>> -Original Message-
>> From: "Drew Weaver" 
>> Sent: ‎5/‎6/‎2014 11:42 AM
>> To: "'nanog@nanog.org'" 
>> Subject: Getting pretty close to default IPv4 route maximum for
>> 6500/7600routers.
>>
>> Hi all,
>>
>> I am wondering if maybe we should make some kind of concerted effort to
>> remind folks about the IPv4 routing table inching closer and closer to the
>> 512K route mark.
>>
>> We are at about 94/95% right now of 512K.
>>
>> For most of us, the 512K route mark is arbitrary but for a lot of folks
>> who may still be running 6500/7600 or other routers which are by default
>> configured to crash and burn after 512K routes; it may be a valuable public
>> service.
>>
>> Even if you don't have this scenario in your network today; chances are
>> you connect to someone who connects to someone who connects to someone
>> (etc...) that does.
>>
>> In case anyone wants to check on a 6500, you can run:  show platform
>> hardware capacity pfc and then look under L3 Forwarding Resources.
>>
>> Just something to think about before it becomes a story the community
>> talks about for the next decade.
>>
>> -Drew
>>
>>
>

L3/HE/Inbound Pathing Question

2014-06-09 Thread Dennis Burgess 
I have ran into this a few times, and have not found a solution:

 

L3 à 

HEà  --- blended Provider A --- > Customer

 

Cogent -- > Customer

 

Cogent of course is cheaper, and customer wishes to use the blended provder 
more as backup and/or have most of the inbound traffic coming in the cheaper 
path (cogent).  The issue appears to be L3 and HE specifically (of course they 
make up a good chunk of inbound traffic) always prefers their customer peers, 
so even if we advertise any prefix to the blended, those companies (l3/he) 
always choose to come in though the customer peer and then to my customer.

 

Any thoughts on how to get around this, and still have some kind of route in 
the blended provider for failover?Off list is fine.. Thanks in advance.  

 

 

Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second 
Edition  "
 
 Link Technologies, Inc -- Mikrotik & WISP Support Services 
   
 Office: 314-735-0270   Website: http://www.linktechs.net 
  - Skype: linktechs   

 -- Create Wireless Coverage's with www.towercoverage.com 
  - 900Mhz - LTE - 3G - 3.65 - TV Whitespace

Linkedin Operations Contact ?

2014-06-09 Thread Anshuman Kanwar 
Looking to get in touch with the LinkedIn Ops team. Could one you kindly 
respond 1-1 ?

Thanks,
-ansh



Ansh Kanwar

Senior Director, Technical Operations
T: +1 805 690 5714 | M: +1 805 448 1890 | F: +1 805 879 3722
Skype: ansh_kanwar | AS: 16815
anshuman.kan...@citrix.com
[Description: Description: Description: 
cid:4A46DE88-037B-420B-B411-732B97826E8D@ad.corp.expertcity.com]
Powering mobile workstyles and cloud services

Re: World Cup Streaming

2014-06-09 Thread Chris Russell 
   3. British (English) humor is popular in the US.   Very four 
years, the
   "Three Lions" comedy troupe put on a performance that has them 
rolling in
   the aisles.  With cult performers Rooney, Gerrard, Welbeck, and 
Hart,

   hijinks will ensue and fun will be had by all![1]

1. Except the English, who will be bitter and depressed.  But they 
are

happiest being bitter and depressed.


 As a Limey, touche sir, touche.

 Rooney is the 2960G of football, plenty of potential but you know he 
won't quite cut it in the enterprise space.


 With that said, the hair transplant may provide additional buffer 
space for balls delivered with higher MTU.


Chris