Re: IPv6 Netowrk Device Numbering BP

[Karl Auer]

On Sat, 2012-11-03 at 00:44 -0500, Randy wrote:
> Veering off this topic's course, Is there any issue with addresses like 
> this ?
> 2001:470:1f00:1aa:abad:babe:8:beef < I have a bunch of these type 
> 'addresses' configured for my various machines.
> 
> I make it a point to come up with some sort of 'hex' speak address, what 
> are peoples opinions on this?

I tell my students to avoid them. For several reasons:

- if you need to remember an IP address, you are doing it wrong

- limiting yourself to "word space" wastes "address space". Possibly
acceptable in interface IDs, foolish in subnetting bits.

- if people expect something, they will type it, possibly instead of
what's actually needed. By making them expect words, you introduce a
source of error.

- cultural sensitivity and plain good sense suggest that many words or
combinations might not be a good idea. How do your female techs feel
about "BAD:BABE"? Only marginally better than they feel about
"B16:B00B:EEZ", probably. Your markets in India, with its 900 million
Hindus, might take a dim view of "DEAD:BEEF". Etc.

- clever addresses are guessable addresses for scanners, and highly
identifiable in data as probably attached to high-value targets

- something that is witty once is generally irritating the thousandth
time you see it. Doubly so if it wasn't very funny to begin with.

- the time you spend trying to find something "meaningful" is basically
wasted, and the time you spend will increase exponentially once you've
used all the low-hanging fruit.

All in all, using such addresses is probably a Bad Idea. 

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

Re: IPv6 Netowrk Device Numbering BP

[Graham Beneke]

On 03/11/2012 07:44, Randy wrote:
> Veering off this topic's course, Is there any issue with addresses like
> this ?
> 2001:470:1f00:1aa:abad:babe:8:beef < I have a bunch of these type
> 'addresses' configured for my various machines.
> 
> I make it a point to come up with some sort of 'hex' speak address, what
> are peoples opinions on this?

Why bother? DNS supports all 26 characters ;-)

Its cute... but it tends to only be useful in fairly small deployments.
You quickly run out of nice combinations.

I prefer to choose addresses that allow for the most consecutive zeros.
Many UIs I've used display IPv6 address strings in very un-useful ways
as they approach the allowable length of 39 characters. Many require you
to resize your viewing window/column/etc to see the full address and
some simply truncate the string and refuse to show you the host ID portion.

-- 
Graham Beneke

Re: qwest.net dropping packets... wife would like someone to pick them up please...

[Don Gould]

Hi Matt (and other helpful posters off list),

Yes, makes sense.

I'm told this pops up twice a month, so opps, clearly I need to spend 
more time reading and learning! :)


Thanks to the person who pointed out the PTR rec suggests that the 
impacted resource might be more west than I realised.  I confess I don't 
know the .us very well at all.


D

On 3/11/2012 6:43 p.m., Matthew Petach wrote:
Hi Don, based on your mtr output, there's no loss to the end 
destination; one router along the path showing loss that does not 
continue to affect the rest of the path simply means the cpu on that 
router is a bit too busy to respond to icmp messages; but there's 0% 
loss beyond it, which means it's doing its primary job of forwarding 
packets just fine. Thanks, and have a wonderful weekend! Matt 



--
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699

Re: IPv6 Netowrk Device Numbering BP

[Randy]

Veering off this topic's course, Is there any issue with addresses like 
this ?
2001:470:1f00:1aa:abad:babe:8:beef < I have a bunch of these type 
'addresses' configured for my various machines.


I make it a point to come up with some sort of 'hex' speak address, what 
are peoples opinions on this?

Re: qwest.net dropping packets... wife would like someone to pick them up please...

[Matthew Petach]

On Fri, Nov 2, 2012 at 8:42 PM, Don Gould  wrote:
> Hi all,
>
> Hope you're all getting on top of Sandy.
>
> Trying to hit kajabi.com, I'm getting up to 60% packet loss off qwest.net -
> dca2-edge-02.inet.qwest.net
>
> A bit of quick googleing and we assumed that they're on the west coast of
> US, so please excuse (and just ignore me) if you're on the east coast and
> this is being caused by all the Sandy issues (yes I've been following the
> Outage list and think you guys are just doing an amazing job right now!!!)
>
> Re the subject - told the wife that her problem is likely being caused by
> packets being dropped by qwest, her response "can someone pick them up for
> me plse :)"
>
>
> mx.8013.yournet.co.nz (0.0.0.0)Sat Nov  3 16:43:18
> 2012
> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>Packets   Pings
>  HostLoss%   Snt   Last   Avg  Best Wrst
> StDev
>  1. router0.0%390.2   0.2   0.2 0.3
> 0.0
>  2. ???
>  3. 218.101.61.1010.0%399.1  21.8   7.0 173.6
> 33.4
>  4. ie2-g-0-0-0.telstraclear.net  0.0%39   38.0  22.9  19.6 38.0
> 3.5
>  5. ge-0-2-0-1.xcore1.acld.telstracl  0.0%39   22.2  22.9  18.9 38.5
> 3.9
>  6. unknown.telstraglobal.net 0.0%39   23.4  22.1  17.6 26.4
> 1.4
>  7. i-0-6-1-0.tlot-core01.bx.telstra  0.0%39  153.4 153.3 151.2 163.9
> 2.3
>  8. i-4-2.eqla01.bi.telstraglobal.ne  0.0%39  147.0 154.8 143.5 313.8
> 27.7
>  9. lap-brdr-04.inet.qwest.net0.0%39  154.2 154.5 152.0 159.2
> 1.6
> 10. dca2-edge-02.inet.qwest.net  10.5%39  221.0 223.1 217.1 247.6
> 6.6
> 11. 67.133.224.1940.0%39  220.8 222.2 216.3 268.6
> 8.1
> 12. 72.21.220.161 0.0%39  221.2 225.3 217.6 268.2
> 10.8
> 13. 72.21.222.139 0.0%38  220.9 222.8 216.6 266.6
> 7.5
> 14. 216.182.224.8 0.0%38  221.3 223.2 220.5 243.9
> 4.1
> 15. ???
>
> D
> --
> Don Gould
> 31 Acheson Ave
> Mairehau
> Christchurch, New Zealand
> Ph: + 64 3 348 7235
> Mobile: + 64 21 114 0699
>
>


Hi Don,

based on your mtr output, there's no loss to the
end destination; one router along the path showing
loss that does not continue to affect the rest of the
path simply means the cpu on that router is a bit
too busy to respond to icmp messages; but there's
0% loss beyond it, which means it's doing its primary
job of forwarding packets just fine.

Thanks, and have a wonderful weekend!

Matt

Re: Looking for recommendation on 10G Ethernet switch

[Bryan Tong]

I have used the summit x650s for cloud and they work fine for public and
SAN traffic on the same switch. I have seen then as low as 7k if you can
work with extreme directly.  The only downside being the configuration for
large VLAN amounts.

Also netgear makes the xsm7224s which does everything the summit does aside
from only supporting 1024 vlans. I have a pair of these and they work very
well.

On Friday, November 2, 2012, Andrew Latham wrote:

> On Fri, Nov 2, 2012 at 2:38 PM, Kevin L. Karch 
> >
> wrote:
> > Andrew
> >
> > We offer several solutions that meet your initial requirements. Can you
> tell me if this is a multi rack deployment and a few more details?
> >
> > If you would like we could have a call with one of our applications
> engineers and get a budgetary quote assembled.
> >
> > Please let me know how you would like to proceed.
> >
> > Thank you,
> >
> > Kevin L. Karch
> > Network Specialist
> >
> > Direct: 847-833-8810
> > Fax: 847-985-5550
> > Email: kevinka...@vackinc.com 
> > Web: www.vackinc.com
> > The Optical Network Specialists
>
> Kevin, no thank you, I did not start this thread.  If I ever need
> products I reach out to my contacts at each manufacturer or
> distributor.  It would be much less embarrassing for you if the
> website in your signature actually finished loading the images
> containing the text for your company.
>
> --
> ~ Andrew "lathama" Latham lath...@gmail.com 
> http://lathama.net ~
>
>

-- 

Bryan Tong
Nullivex LLC | eSited LLC
(507) 298-1624

qwest.net dropping packets... wife would like someone to pick them up please...

[Don Gould]

Hi all,

Hope you're all getting on top of Sandy.

Trying to hit kajabi.com, I'm getting up to 60% packet loss off 
qwest.net - dca2-edge-02.inet.qwest.net


A bit of quick googleing and we assumed that they're on the west coast 
of US, so please excuse (and just ignore me) if you're on the east coast 
and this is being caused by all the Sandy issues (yes I've been 
following the Outage list and think you guys are just doing an amazing 
job right now!!!)


Re the subject - told the wife that her problem is likely being caused 
by packets being dropped by qwest, her response "can someone pick them 
up for me plse :)"



mx.8013.yournet.co.nz (0.0.0.0)Sat Nov  3 
16:43:18 2012

Keys:  Help   Display mode   Restart statistics   Order of fields   quit
   Packets   Pings
 HostLoss%   Snt   Last   Avg  Best 
Wrst StDev
 1. router0.0%390.2   0.2   0.2 
0.3   0.0

 2. ???
 3. 218.101.61.1010.0%399.1  21.8   7.0 
173.6  33.4
 4. ie2-g-0-0-0.telstraclear.net  0.0%39   38.0  22.9  19.6 
38.0   3.5
 5. ge-0-2-0-1.xcore1.acld.telstracl  0.0%39   22.2  22.9  18.9 
38.5   3.9
 6. unknown.telstraglobal.net 0.0%39   23.4  22.1  17.6 
26.4   1.4
 7. i-0-6-1-0.tlot-core01.bx.telstra  0.0%39  153.4 153.3 151.2 
163.9   2.3
 8. i-4-2.eqla01.bi.telstraglobal.ne  0.0%39  147.0 154.8 143.5 
313.8  27.7
 9. lap-brdr-04.inet.qwest.net0.0%39  154.2 154.5 152.0 
159.2   1.6
10. dca2-edge-02.inet.qwest.net  10.5%39  221.0 223.1 217.1 
247.6   6.6
11. 67.133.224.1940.0%39  220.8 222.2 216.3 
268.6   8.1
12. 72.21.220.161 0.0%39  221.2 225.3 217.6 
268.2  10.8
13. 72.21.222.139 0.0%38  220.9 222.8 216.6 
266.6   7.5
14. 216.182.224.8 0.0%38  221.3 223.2 220.5 
243.9   4.1

15. ???

D
--
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699

Re: Looking for recommendation on 10G Ethernet switch

[Andrew Latham]

On Fri, Nov 2, 2012 at 2:38 PM, Kevin L. Karch  wrote:
> Andrew
>
> We offer several solutions that meet your initial requirements. Can you tell 
> me if this is a multi rack deployment and a few more details?
>
> If you would like we could have a call with one of our applications engineers 
> and get a budgetary quote assembled.
>
> Please let me know how you would like to proceed.
>
> Thank you,
>
> Kevin L. Karch
> Network Specialist
>
> Direct: 847-833-8810
> Fax: 847-985-5550
> Email: kevinka...@vackinc.com
> Web: www.vackinc.com
> The Optical Network Specialists

Kevin, no thank you, I did not start this thread.  If I ever need
products I reach out to my contacts at each manufacturer or
distributor.  It would be much less embarrassing for you if the
website in your signature actually finished loading the images
containing the text for your company.

-- 
~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~

Re: IPv6 Netowrk Device Numbering BP

[Owen DeLong]

On Nov 2, 2012, at 02:52 , Tore Anderson  
wrote:

> * Owen DeLong
> 
>> Yes, it was pointed out to me that for some silly reason passing
>> understanding, that syntax is supported. It's absurd, but supported.
>> Sigh
>> 
>> Probably we should deprecate it as it really doesn't make sense to 
>> use it that way.
> 
> It absolutely does make sense, especially in the case of IPv4/IPv6
> translation. For example, when using NAT64, "64:ff9b::192.0.2.33" is an
> example of a valid IPv6 address that maps to 192.0.2.33. Much easier to
> relate to for a human than "64:ff9b::c000:221" is.
> 

But there are two situations where you'd use that for NAT64...

1.  Presentation of electronic information to the end user, where it's 
virtually
impossible for the system to know whether that's a NAT64 address
representing an IPv4 remote end or an IPv6 address, so, how do you
know when to represent it that way to the end user?

2.  As a destination specifier (in which case the system most likely got 
the address
as a binary return from DNS64 and doesn't present it to the end user 
prior
to sending the request off to the remote server and even if it did, 
again, doesn't
likely have a way to know when to use that notation.

Sure, there's the third possibility that an end-user is hand-typing an 
IPv6-encoded
IPv4 address to go through a translator, but, I think for a variety of reasons, 
that
behavior should be relatively strongly discouraged, no?

> Similarly, when using SIIT, the same syntax may be used in firewall
> rules or ACLs. So if you want to open, say, the SSH port from a trusted
> IPv4 address 192.0.2.33 on the far side of the SIIT gateway to your IPv6
> server, it's much easier to open for "64:ff9b::192.0.2.33", and it will
> also make your ACL much more readable to the next guy that comes along
> than if you had used "64:ff9b::c000:221".

SIIT is a really bad idea. Codifying it into a firewall only makes things worse.


> 
> Also see RFC 6052 section 2.4.

RFC's contain all kinds of embodiments and documentation of bad ideas that
should have been deprecated long ago.

Use of this notation for parsing rather than as an output-only format is just
another example.

Yes, once upon a time, lumping lots of V4-ness into IPv6 to try and create
some impression of backwards compatibility seemed like a good idea.

A couple of decades of experimentation and operational experience has
now taught us that it doesn't work out as well as one might have hoped.
Time to move on.

Owen

Re: Looking for recommendation on 10G Ethernet switch

[Maxim Khitrov]

On Fri, Nov 2, 2012 at 4:10 PM, Jeff Wheeler  wrote:
> On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann  wrote:
>> I'm looking for a recommendation on a smallish 10G Ethernet switch for a
>> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
>> iSCSI with some legacy boxes on GigE.
>
>> 1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
>> with quad GigE cards.  Trying to find the best solution for > 1G on a
>> trunk and < $50K per box.
>
> Certainly the days of doing NxGE to servers should be behind us.
> There are many good 10GE switch offerings.  The Juniper QFX and Arista
> (insert one of three good product lines here) have been excellent for
> us.  We like them for different reasons -- Arista is quite good if you
> want to integrate with a provisioning system; QFX is our choice when
> most provisioning is done manually.  Both are way under $50k per box.
>
> The biggest difference between the TOR-style switches and chassis
> offerings, aside from the obvious, is buffers.  All the TOR-type 10G
> switches have really small buffers and that can be a performance issue
> for iSCSI when utilization is high.  Most of the chassis-type switches
> have very generous buffers so you do not run into problems with
> micro-bursting, etc.  The vendors will all tell you about lossless
> ethernet, flow control, etc. and that crap sounds great on paper.  Try
> making it actually work.  You'll want those days of your life back. :)

I'm curious if anyone here has experience with the Extreme Summit X650
or X670 switches? I'm also currently looking for 10GBASE-T switch for
my first SAN, but one with 48 ports. The price for X670V-48T seems
reasonable, but I have no experience with 10 GbE over copper, so it's
difficult to figure out what criteria to use (other than price) when
comparing Extreme, Arista, Dell, and others. Any tips?

- Max

Re: Looking for recommendation on 10G Ethernet switch

[Nick Hilliard]

On 02/11/2012 20:10, Jeff Wheeler wrote:
> The biggest difference between the TOR-style switches and chassis
> offerings, aside from the obvious, is buffers.  All the TOR-type 10G
> switches have really small buffers and that can be a performance issue
> for iSCSI when utilization is high

not particularly when utilisation is high, but in situations where
congestion occurs, e.g. when you either have a high write load from
multiple clients to a single server, or if you're down-shifting from a 10G
server to 1G clients or something.

> The vendors will all tell you about lossless ethernet, flow control,
> etc. and that crap sounds great on paper.  Try making it actually work.

flow control on a switch port can lead to hol blocking, which is bad bad
news - guaranteed to trash multi-access network performance.  Some vendors
actually push this as a feature.  I don't completely understand why, but
maybe it has something to do with customers mistakenly believing that it
will make their lives better.  People believe in all sorts of odd
superstitions though: black cats, spilling salt, having full features on
ethernet LAGs, vendor marketing blurb, fear of the number 13, etc.  All
very odd stuff.

Nick

Re: AT&T Microcell Contact

[PC]

I wonder why they filter by IPs anyways?

The only reason I can guess is geolocation to ensure they have a frequency
license in a given geographic area.

However my experience has been that other providers use a GPS for this
(and unfortunately, require a GPS lock to operate).  Great for a house with
a window, not so good for the basement of a building.

On Fri, Nov 2, 2012 at 3:03 PM, Christopher Morrow
wrote:

> On Fri, Nov 2, 2012 at 4:38 PM, Gary Steers 
> wrote:
> > Hi All,
> >
> > Possibly not the best place but we have a couple of customers trying to
> use AT&T Microcell's (Femtocell) on our US Network and they won't
> >
> > We have previously had an issue on UK Networks not accepting our UK
> Range, we just needed to speak to the right team at the operator to get our
> IP Range/AS Whitelisted
> >
>
> it's a shame that for a service which ATT wants to charge you money to
> get/use/keep they won't accept packets from the internet, on a product
> which uses the 'internet' to get the voice packets from you to them :(
>
> at least att does the femtocell jazz? tmo won't :(
>
> > Does anyone on list have any contact details for AT&T's team (Feel free
> to reply off-list)
> >
> > Gary
>
> wow that disclaimer is long ... I mean ... really, very long!
>
>

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 25-Oct-12 -to- 01-Nov-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS28306   95190  3.3%2644.2 -- TC Net Informática e 
Telecomunicações LTDA
 2 - AS840255060  1.9%  26.7 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS31692   38258  1.3%4782.2 -- SATURN-R-AS OOO Saturn-R
 4 - AS982934381  1.2%  24.4 -- BSNL-NIB National Internet 
Backbone
 5 - AS22561   27857  1.0%  26.9 -- DIGITAL-TELEPORT - Digital 
Teleport Inc.
 6 - AS24560   24999  0.9%  24.2 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 7 - AS13118   22668  0.8% 462.6 -- ASN-YARTELECOM OJSC Rostelecom
 8 - AS163722256  0.8% 250.1 -- DNIC-AS-01637 - Headquarters, 
USAISC
 9 - AS702921380  0.8%   6.6 -- WINDSTREAM - Windstream 
Communications Inc
10 - AS19361   20568  0.7% 604.9 -- Atrium Telecomunicacoes Ltda
11 - AS28573   19804  0.7%   9.1 -- NET Servicos de Comunicao S.A.
12 - AS17974   17560  0.6%   7.2 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
13 - AS10620   16919  0.6%   7.6 -- Telmex Colombia S.A.
14 - AS638916633  0.6%   5.2 -- BELLSOUTH-NET-BLK - 
BellSouth.net Inc.
15 - AS476613330  0.5%   4.5 -- KIXS-AS-KR Korea Telecom
16 - AS27947   13256  0.5%  16.9 -- Telconet S.A
17 - AS11300   12806  0.5% 376.6 -- GLOBECOMM-11300 - Globecomm 
Services Maryland LLC
18 - AS580012797  0.5%  48.3 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
19 - AS755212425  0.4%  10.8 -- VIETEL-AS-AP Vietel Corporation
20 - AS270811426  0.4%  83.4 -- Universidad de Guanajuato


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS240575461  0.2%5461.0 -- AIGL-AS-AP PT. AIA FINANCIAL, 
Insurance company, Indonesia
 2 - AS216845061  0.2%5061.0 -- CYBERINETBGP - Cyberonics, Inc.
 3 - AS31692   38258  1.3%4782.2 -- SATURN-R-AS OOO Saturn-R
 4 - AS28306   95190  3.3%2644.2 -- TC Net Informática e 
Telecomunicações LTDA
 5 - AS597064882  0.2%2441.0 -- IBC-AS-TIRANA I.B.C shpk
 6 - AS146806913  0.2%2304.3 -- REALE-6 - Auction.com
 7 - AS416741411  0.1%1411.0 -- ALVARION-AS Alvarion SRL
 8 - AS31243  0.0%2240.0 -- CMED-AS Cmed Technology Ltd
 9 - AS498881175  0.0%1175.0 -- ULTRANET-AS Ultranet Sp. z o.o.
10 - AS231011090  0.0%1090.0 -- PERCEPTA-GW2-AS - Percepta
11 - AS249941687  0.1% 843.5 -- GENESYS-AS genesys informatica 
srl
12 - AS504783955  0.1% 791.0 -- BVOX BVOX AS
13 - AS19361   20568  0.7% 604.9 -- Atrium Telecomunicacoes Ltda
14 - AS57341 602  0.0% 602.0 -- FSC-UA-AS FINANCIAL COMPANY 
"FINANCIAL SOLUTIONS CENTER" LTD
15 - AS25585 519  0.0% 519.0 -- KENCOMP Kencomp Internet LTD
16 - AS13118   22668  0.8% 462.6 -- ASN-YARTELECOM OJSC Rostelecom
17 - AS57201 456  0.0% 456.0 -- EDF-AS Estonian Defence Forces
18 - AS16517 420  0.0% 420.0 -- LEEPROCESS - LEE & ASSOCIATES 
LLC
19 - AS32529 388  0.0% 388.0 -- CGI-FEDERAL-ASN-1 - CGI Federal
20 - AS194064222  0.1% 383.8 -- TWRS-MA - Towerstream I, Inc.


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 109.161.64.0/19   18988  0.6%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 184.159.130.0/23  12038  0.4%   AS22561 -- DIGITAL-TELEPORT - Digital 
Teleport Inc.
 3 - 122.161.0.0/1611548  0.3%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 4 - 184.157.224.0/19  10276  0.3%   AS22561 -- DIGITAL-TELEPORT - Digital 
Teleport Inc.
 5 - 200.46.0.0/19  9859  0.3%   AS21599 -- NETDIRECT S.A.
 6 - 178.161.162.0/24   9559  0.3%   AS31692 -- SATURN-R-AS OOO Saturn-R
 7 - 178.161.174.0/24   9558  0.3%   AS31692 -- SATURN-R-AS OOO Saturn-R
 8 - 178.161.166.0/24   9558  0.3%   AS31692 -- SATURN-R-AS OOO Saturn-R
 9 - 178.161.163.0/24   9558  0.3%   AS31692 -- SATURN-R-AS OOO Saturn-R
10 - 189.38.15.0/24 9501  0.3%   AS28306 -- TC Net Informática e 
Telecomunicações LTDA
11 - 187.94.82.0/24 9500  0.3%   AS28306 -- TC Net Informática e 
Telecomunicações LTDA
12 - 187.94.81.0/24 9500  0.3%   AS28306 -- TC Net Informática e 
Telecomunicações LTDA
13 - 189.38.5.0/24  9500  0.3%   AS28306 -- TC Net Informática e 
Telecomunicações LTDA
14 - 189.38.8.0/24  9500  0.3%   AS28306 -- TC Net Informática e 
Telecomunicações LTDA
15 - 189.38.14.0/24 9500  0.3%   AS28306 -- TC Net Informática e 
Telecomunicações LTDA
16 - 187.94.83.0/24 9500  0.3%   AS28306 

The Cidr Report

[cidr-report]

This report has been generated at Fri Nov  2 21:13:07 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
26-10-12431572  249274
27-10-12432213  249384
28-10-12432113  249282
29-10-12432015  248962
30-10-12431640  248679
31-10-12430741  248820
01-11-12430584  248727
02-11-12431467  249292


AS Summary
 42456  Number of ASes in routing system
 17666  Number of ASes announcing only one prefix
  3201  Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
  114164704  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 02Nov12 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 431785   249253   18253242.3%   All ASes

AS6389  3168  168 300094.7%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS28573 2129   70 205996.7%   NET Servicos de Comunicao S.A.
AS4766  2969  941 202868.3%   KIXS-AS-KR Korea Telecom
AS17974 2430  551 187977.3%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS22773 1971  140 183192.9%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS7029  3201 1391 181056.5%   WINDSTREAM - Windstream
   Communications Inc
AS18566 2084  423 166179.7%   COVAD - Covad Communications
   Co.
AS7303  1669  426 124374.5%   Telecom Argentina S.A.
AS4323  1597  399 119875.0%   TWTC - tw telecom holdings,
   inc.
AS10620 2243 1153 109048.6%   Telmex Colombia S.A.
AS4755  1618  531 108767.2%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS7552  1107  182  92583.6%   VIETEL-AS-AP Vietel
   Corporation
AS8151  1611  695  91656.9%   Uninet S.A. de C.V.
AS18101 1018  174  84482.9%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS7545  1802 1026  77643.1%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS4808    348  76368.7%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS13977  862  115  74786.7%   CTELCO - FAIRPOINT
   COMMUNICATIONS, INC.
AS1785  1927 1212  71537.1%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS855704   53  65192.5%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS3356  1122  498  62455.6%   LEVEL3 Level 3 Communications
AS17676  709   87  62287.7%   GIGAINFRA Softbank BB Corp.
AS24560 1034  434  60058.0%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS3549  1032  438  59457.6%   GBLX Global Crossing Ltd.
AS36998  772  178  59476.9%   SDN-MOBITEL
AS19262 1001  409  59259.1%   VZGNI-TRANSIT - Verizon Online
   LLC
AS22561 1019  433  58657.5%   DIGITAL-TELEPORT - Digital
   Teleport Inc.
AS4780   844  286  55866.1%   SEEDNET Digital United Inc.
AS22047  578   30  54894.8%   VTR BANDA ANCHA S.A.
AS7011  1222  692  53043.4%   FRONTIER-AND-CITIZENS -
   Frontier Communications of
   America, Inc.
AS18881  578   48  53091.7%   Global Village Telecom

T

Re: AT&T Microcell Contact

[John Levine]

>-- SHAREDBAND EMAIL DISCLAIMER --
>This e-mail and any attachments are confidential, are intended solely for the 
>use of the individual to
>whom it is addressed and may also be privileged. If you are not the named 
>recipient, please notify the
>sender immediately and do not disclose the contents to another person, use it 
>for any purpose, or store
>or copy the information in any medium.

I would suggest that people delete this mail unread to avoid
unpleasant legal consequences, since none of us are "nanog@nanog.org"
to which it was addressed.

R's,
John

Re: Cisco 6509 SUP32 SNMP Meltdown With CatOS

[Jeff Gehlbach]

On 11/02/2012 04:52 PM, Nick Hilliard wrote:

> E.g. a fully loaded 6509 with 384 ports would take ~3000 queries every
> several minutes to perform full port diagnostic polling, and you'd want to
> be doing this every couple of seconds to cause serious CPU impact.  Are you
> doing something like full DFZ or MAC table polling?

I bet you're close toward the end there.  My guess is he's carrying a
large BGP feed and querying the ipRouteTable.  The caveat below is for
IOS 12.4(20)T but equivalent issues surely exist for CatOS:

http://www.cisco.com/en/US/docs/ios/12_4t/release/notes/124TCAVS3.html#wp2057950

The killer in this case is not the SNMP traffic or anything resulting
directly from it, but the CPU overhead from constantly re-sorting the
ipRouteTable since that's generated from the FIB when CEF is enabled.
Workaround is to disable CEF (heh) or configure a MIB view that excludes
the ipRouteTable.  This one bites an OpenNMS support customer a few
times a year -- happened again just today, in fact, at a shop that just
enabled topology discovery.

> Also, you may want to consider moving away from CatOS, as it's now
> basically abandonware (or at least will formally be in Jan 2013), and
> hasn't even seen maintenance updates in the last 4 years.

What you said :)

-jeff

RE: Cisco 6509 SUP32 SNMP Meltdown With CatOS

[Matthew Huff]

By any chance were you querying a Sup32 that had BGP full routes? That and 
other large tables can easily swamp the cpu on the Sup32.

This technote is based on IOS, and I don't know if the same facilities exist in 
CatOS, but as Nick mentioned, run, don't walk and convert to IOS. CatOS is dead.

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800948e6.shtml


-Original Message-
From: david peahi [mailto:davidpe...@gmail.com] 
Sent: Friday, November 02, 2012 2:37 PM
To: nanog@nanog.org
Subject: Cisco 6509 SUP32 SNMP Meltdown With CatOS

Anyone have experience with Cisco 6509E/SUP32 crashing under heavy SNMP
polling load, causing high cpu utilization and 6509 lockup, requiring 6509
reboot? CatOS is deployed. Is the behavior any different with 6509 IOS?

David

Re: AT&T Microcell Contact

[Christopher Morrow]

On Fri, Nov 2, 2012 at 4:38 PM, Gary Steers  wrote:
> Hi All,
>
> Possibly not the best place but we have a couple of customers trying to use 
> AT&T Microcell's (Femtocell) on our US Network and they won't
>
> We have previously had an issue on UK Networks not accepting our UK Range, we 
> just needed to speak to the right team at the operator to get our IP Range/AS 
> Whitelisted
>

it's a shame that for a service which ATT wants to charge you money to
get/use/keep they won't accept packets from the internet, on a product
which uses the 'internet' to get the voice packets from you to them :(

at least att does the femtocell jazz? tmo won't :(

> Does anyone on list have any contact details for AT&T's team (Feel free to 
> reply off-list)
>
> Gary

wow that disclaimer is long ... I mean ... really, very long!

Re: Cisco 6509 SUP32 SNMP Meltdown With CatOS

[Nick Hilliard]

On 02/11/2012 18:37, david peahi wrote:
> Anyone have experience with Cisco 6509E/SUP32 crashing under heavy SNMP
> polling load, causing high cpu utilization and 6509 lockup, requiring 6509
> reboot? CatOS is deployed. Is the behavior any different with 6509 IOS?

You're being very coy about details here.  I've not managed to actually
crash a 6500 running IOS by excessive snmp, but the more interesting
question is: how on earth are you running so many snmp queries that this is
happening?

E.g. a fully loaded 6509 with 384 ports would take ~3000 queries every
several minutes to perform full port diagnostic polling, and you'd want to
be doing this every couple of seconds to cause serious CPU impact.  Are you
doing something like full DFZ or MAC table polling?  Or IP accounting over
snmp?  If you are, there are probably better ways of achieving what you're
trying to do.

Also, you may want to consider moving away from CatOS, as it's now
basically abandonware (or at least will formally be in Jan 2013), and
hasn't even seen maintenance updates in the last 4 years.

Nick

AT&T Microcell Contact

[Gary Steers]

Hi All,

Possibly not the best place but we have a couple of customers trying to use 
AT&T Microcell's (Femtocell) on our US Network and they won't

We have previously had an issue on UK Networks not accepting our UK Range, we 
just needed to speak to the right team at the operator to get our IP Range/AS 
Whitelisted

Does anyone on list have any contact details for AT&T's team (Feel free to 
reply off-list)

Gary

Gary Steers
Chief Network Engineer | Sharedband
e: gary.ste...@sharedband.com

-- SHAREDBAND EMAIL DISCLAIMER --
This e-mail and any attachments are confidential, are intended solely for the 
use of the individual to whom it is addressed and may also be privileged. If 
you are not the named recipient, please notify the sender immediately and do 
not disclose the contents to another person, use it for any purpose, or store 
or copy the information in any medium.

Sharedband Ltd, Sharedband Technologies LLC, their affiliates, assigns or 
successors ("Sharedband") make no representations and give no warranties of 
whatever nature in respect of the email and its contents including but not 
limited to the accuracy or completeness of any information, facts and/or 
opinions contained in the email. The email is provided by Sharedband solely for 
the recipient's information, and all rights in and to the email including 
copyright and other intellectual property rights therein are proprietary to 
Sharedband.

Any views or opinions expressed are solely those of the author and do not 
necessarily represent those of Sharedband.

Although this e-mail and any attachments are believed to be free from any virus 
or other defect which might affect any system into which they are opened or 
received, it is the responsibility of the recipient to check that they are 
virus free and that they will in no way affect systems and data. No 
responsibility is accepted by Sharedband for any loss or damage arising in any 
way from their receipt, opening or use.

Shared Band Ltd T/A Sharedband Ltd
Registered in England No 04861356, VAT No GB822654826
Registered Office: 40 Princes St, Ipswich, Suffolk, IP1 1RJ UK

Sharedband Technologies, LLC
2033 6th Avenue, Suite 902, Seattle, WA, 98121 US

IETF Nominations Committee seeks operations community input

[Matthew Lepinski]

The IETF Nominations Committee (NomCom) is currently working to select
a new Operations Area Director who will replace Ron Bonica (who is
stepping down next March). Ideally, the Operations area within the
IETF serves as a focal point for communication and collaboration with
the network operations community. I understand that over the years the
Operations area has had varying degrees of success at fostering
productive discussion with the networks operations community.

The IETF NomCom would greatly appreciate input from network operators
to ensure that we select an Operations Area Director who best serves
the needs of the community. The NomCom welcomes general feedback on
issues that the NomCom should take into account in selecting an
Operations Area Director, including things that the IETF Operations
area could/should be doing to better interface with the network
operations community. Please do not hesitate to send input/feedback by
email to the NomCom at nomco...@ietf.org

Additionally, the specific individuals that the NomCom is currently
considering for the position of Operations Area Director are:
-- Linda Dunbar
-- Joel Jaeggli
-- Melinda Shore
-- Tina Tsou
The NomCom welcomes any feedback specifically related to any of these
individuals, and whether they are particularly well suited for the
position of Operations Area Director.

The IETF NomCom takes very seriously the confidentiality of any input
provided to the committee (as per RFC 3777).

Thank you for any help that you can provide to the IETF NomCom,
- Matt Lepinski
  nomcom-ch...@ietf.org

Re: Looking for recommendation on 10G Ethernet switch

[Jeff Wheeler]

On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann  wrote:
> I'm looking for a recommendation on a smallish 10G Ethernet switch for a
> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
> iSCSI with some legacy boxes on GigE.

> 1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
> with quad GigE cards.  Trying to find the best solution for > 1G on a
> trunk and < $50K per box.

Certainly the days of doing NxGE to servers should be behind us.
There are many good 10GE switch offerings.  The Juniper QFX and Arista
(insert one of three good product lines here) have been excellent for
us.  We like them for different reasons -- Arista is quite good if you
want to integrate with a provisioning system; QFX is our choice when
most provisioning is done manually.  Both are way under $50k per box.

The biggest difference between the TOR-style switches and chassis
offerings, aside from the obvious, is buffers.  All the TOR-type 10G
switches have really small buffers and that can be a performance issue
for iSCSI when utilization is high.  Most of the chassis-type switches
have very generous buffers so you do not run into problems with
micro-bursting, etc.  The vendors will all tell you about lossless
ethernet, flow control, etc. and that crap sounds great on paper.  Try
making it actually work.  You'll want those days of your life back. :)

$0.02.
-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Dark fiber usage info request - know-how pointers and experience sharing

[chip]

Your people will need to come to grips with the fact that just being
able to see light coming out the end of the fiber is no longer
sufficient.  Depending on the length you will have to deal with
Chromatic Dispersion and compensation for that.  People will need to
understand that waves that are coming into a filter at -3 will totally
blow out waves coming in at -15, especially when EDFA (amps) are
concerned.  DWDM (in the metro instance) is all about light levels and
making sure that all waves are within 3-5db of each other as they go
from site to site.  Also documentation of exactly which waves are used
on each part of a path and management of your waves is important,
especially to the NOC when troubleshooting or determining exactly
everything that's affected when a path or wave goes down.  Also fiber
cleanliness and proper handling becomes really important.  With 850nm
and SMF you can pretty much lick the end of it and it will stick work
fine.  When running 20 lambdas over 50km it becomes a much bigger
issue.  I would recommend investing in good fiber cleaning/scoping
gear and proper training for your physical plant folks.  Also invest
in a couple of decent OSA's to check levels of all waves coming off a
fiber.  You don't have to drop $80k (or lots more) on gear, but you'll
need something capable of determining the power of different waves at
once and checking for noise.  JDSU, EXFO, and Fluke make some good
gear and should have options to meet just about whatever your budget
is.  An OTDR is nice to have but not crucial, whoever is leasing you
the fiber should be able to provide OTDR shots and characterization of
the paths.  Normal light level checking at various points should be
able to provide you enough info to determine whether its your gear or
the long fiber.

With fixed wave gear you can start pretty cheap and build a decent
enough system.  If you're making lots of moves/add/changes all the
time, I'd recommend tunable optics, especially for sparing.  Then move
to ROADM gear if needed.  For the most part if your system is fairly
static once you get it up and going you don't have to touch it much,
it just works.  The things that then change are when fiber is cut or
stretched due to weather conditions or backhoes.  The gear is pretty
stable.

Hope that helps a little bit.  Enjoy!

--chip

On Fri, Nov 2, 2012 at 1:31 PM, Stefan  wrote:
> Looking at dark fiber leasing as an alternative for existing ISP-acquired
> MPLS, MetroE, P2P, etc. services. I would appreciate some pointers (links)
> into specific technologies used with dark fiber, as direct consumer (not
> ISP). I am not looking for the theory behind (C)DWDM, but rather real life
> implementations and experience with folks operating such.
>
> Highly appreciated would also be extra info on what the learning curve
> required for traditional network engineering crew to operate devices
> terminating into such, and maybe even work (installation and operation)
> needed to maintain plants with this infrastructure.
>
> TIA,
> ***Stefan



-- 
Just my $.02, your mileage may vary,  batteries not included, etc

Re: Looking for recommendation on 10G Ethernet switch

[Dan Olson]

You may want to take a look at the Brocade VDX 6720, it provides 16 10gb ports, 
with 8 ports on demand with addl license.  

They are very reasonable, esp. if you only need 16 ports.   Maintenance costs 
are less
than cisco. 

- Original Message -
> From: "Eric Germann" 
> To: nanog@nanog.org
> Sent: Friday, November 2, 2012 10:13:01 AM
> Subject: Looking for recommendation on 10G Ethernet switch
> Colleagues,
> 
> I'm looking for a recommendation on a smallish 10G Ethernet switch for
> a
> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
> iSCSI with some legacy boxes on GigE.
> 
> Preferably
> 
> - 8-16 10G ports
> - several GigE ports for legacy GigE hosts or cross connect to a
> legacy
> GigE switch
> - preferably not a large chassis based solution with blades
> 
> The hosts aren't going to be driving full line rate, nor the SAN boxes
> providing full line rate, but their offered loads will definitely
> exceed
> 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing
> with quad GigE cards. Trying to find the best solution for > 1G on a
> trunk and < $50K per box.
> 
> Any recommendations appreciated.
> 
> Thanks
> 
> EKG

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 03 Nov, 2012

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  429394
Prefixes after maximum aggregation:  179257
Deaggregation factor:  2.40
Unique aggregates announced to Internet: 211352
Total ASes present in the Internet Routing Table: 42340
Prefixes per ASN: 10.14
Origin-only ASes present in the Internet Routing Table:   33614
Origin ASes announcing only one prefix:   15739
Transit ASes present in the Internet Routing Table:5668
Transit-only ASes present in the Internet Routing Table:144
Average AS path length visible in the Internet Routing Table:   4.6
Max AS path length visible:  42
Max AS path prepend of ASN ( 22394)  36
Prefixes from unregistered ASNs in the Routing Table:   928
Unregistered ASNs in the Routing Table: 334
Number of 32-bit ASNs allocated by the RIRs:   3429
Number of 32-bit ASNs visible in the Routing Table:3058
Prefixes from 32-bit ASNs in the Routing Table:8306
Special use prefixes present in the Routing Table:   14
Prefixes being announced from unallocated address space:161
Number of addresses announced to Internet:   2609947628
Equivalent to 155 /8s, 144 /16s and 163 /24s
Percentage of available address space announced:   70.5
Percentage of allocated address space announced:   70.5
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   93.8
Total number of prefixes smaller than registry allocations:  150664

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   103913
Total APNIC prefixes after maximum aggregation:   32578
APNIC Deaggregation factor:3.19
Prefixes being announced from the APNIC address blocks:  104695
Unique aggregates announced from the APNIC address blocks:43002
APNIC Region origin ASes present in the Internet Routing Table:4787
APNIC Prefixes per ASN:   21.87
APNIC Region origin ASes announcing only one prefix:   1245
APNIC Region transit ASes present in the Internet Routing Table:781
Average APNIC Region AS path length visible:4.7
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:347
Number of APNIC addresses announced to Internet:  712664992
Equivalent to 42 /8s, 122 /16s and 103 /24s
Percentage of available APNIC address space announced: 83.3

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 131072-133119
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:154569
Total ARIN prefixes after maximum aggregation:78063
ARIN Deaggregation factor: 1.98
Prefixes being announced from the ARIN address blocks:   155424
Unique aggregates announced from the ARIN address blocks: 69585
ARIN Region origin ASes present in the Internet Routing Table:15136
ARIN Prefixes per ASN:10.27
ARIN Region origin ASes announcing only

Cisco 6509 SUP32 SNMP Meltdown With CatOS

[david peahi]

Anyone have experience with Cisco 6509E/SUP32 crashing under heavy SNMP
polling load, causing high cpu utilization and 6509 lockup, requiring 6509
reboot? CatOS is deployed. Is the behavior any different with 6509 IOS?

David

Re: Dark fiber usage info request - know-how pointers and experience sharing

[david peahi]

In the USA the Federal School Lunch program has built out a parallel fiber
network equal to or superior to telco fiber in many urban locations, under
the E-Rate program. TheE-Rate  backbone fiber is leased typically on a
10-20 year IRU basis. Sunesys is a provider of dark fiber, and their web
site interfaces with Google Maps to provide detailed fiber maps where they
have deployed fiber (I do not work for Sunesys, or any other dark fiber
company).

My own experience with dark fiber using off the shelf long reach sfps
(GiGE, CWDM wavelengths with passive mux technology, h, connecting Ethernet
switches from various vendors) is that dark fiber networks are extremely
stable,and  require little maintenance once operational. An experienced
network engineer will have no trouble deploying such a network.

David

On Fri, Nov 2, 2012 at 10:31 AM, Stefan  wrote:

> Looking at dark fiber leasing as an alternative for existing ISP-acquired
> MPLS, MetroE, P2P, etc. services. I would appreciate some pointers (links)
> into specific technologies used with dark fiber, as direct consumer (not
> ISP). I am not looking for the theory behind (C)DWDM, but rather real life
> implementations and experience with folks operating such.
>
> Highly appreciated would also be extra info on what the learning curve
> required for traditional network engineering crew to operate devices
> terminating into such, and maybe even work (installation and operation)
> needed to maintain plants with this infrastructure.
>
> TIA,
> ***Stefan
>

Re: Looking for recommendation on 10G Ethernet switch

[Andrew Latham]

On Fri, Nov 2, 2012 at 1:58 PM, Mike Hale  wrote:
> If you're looking at sub 50k, the Nexus 5k isn't a terrible option.
> It gives you 32 10Gig SFP slots for ~$25,000 or less if you don't mind
> used from ebay.
>
> On Fri, Nov 2, 2012 at 8:18 AM, Andrew Latham  wrote:
>> On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann  wrote:
>>> Colleagues,
>>>
>>> I'm looking for a recommendation on a smallish 10G Ethernet switch for a
>>> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
>>> iSCSI with some legacy boxes on GigE.
>>>
>>> Preferably
>>>
>>> - 8-16 10G ports
>>> - several GigE ports for legacy GigE hosts or cross connect to a legacy
>>> GigE  switch
>>> - preferably not a large chassis based solution with blades
>>>
>>> The hosts aren't going to be driving full line rate, nor the SAN boxes
>>> providing full line rate, but their offered loads will definitely exceed
>>> 1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
>>> with quad GigE cards.  Trying to find the best solution for > 1G on a
>>> trunk and < $50K per box.
>>>
>>> Any recommendations appreciated.
>>>
>>> Thanks
>>>
>>> EKG
>>
>> This topic has been covered completely and often on the Beowulf list.
>> http://www.beowulf.org/pipermail/beowulf/ or do a site search via your
>> friendly search engine.
>>
>> --
>> ~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~
>>

Also note that new devices hit the market everyday.  For example
Supermicro has an offering at
http://www.supermicro.com/products/accessories/Networking/SSE-X24S.cfm
which at the very least will be supported forever.

-- 
~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~

Re: Looking for recommendation on 10G Ethernet switch

[Mike Hale]

If you're looking at sub 50k, the Nexus 5k isn't a terrible option.
It gives you 32 10Gig SFP slots for ~$25,000 or less if you don't mind
used from ebay.

On Fri, Nov 2, 2012 at 8:18 AM, Andrew Latham  wrote:
> On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann  wrote:
>> Colleagues,
>>
>> I'm looking for a recommendation on a smallish 10G Ethernet switch for a
>> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
>> iSCSI with some legacy boxes on GigE.
>>
>> Preferably
>>
>> - 8-16 10G ports
>> - several GigE ports for legacy GigE hosts or cross connect to a legacy
>> GigE  switch
>> - preferably not a large chassis based solution with blades
>>
>> The hosts aren't going to be driving full line rate, nor the SAN boxes
>> providing full line rate, but their offered loads will definitely exceed
>> 1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
>> with quad GigE cards.  Trying to find the best solution for > 1G on a
>> trunk and < $50K per box.
>>
>> Any recommendations appreciated.
>>
>> Thanks
>>
>> EKG
>
> This topic has been covered completely and often on the Beowulf list.
> http://www.beowulf.org/pipermail/beowulf/ or do a site search via your
> friendly search engine.
>
> --
> ~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Dark fiber usage info request - know-how pointers and experience sharing

[Stefan]

Looking at dark fiber leasing as an alternative for existing ISP-acquired
MPLS, MetroE, P2P, etc. services. I would appreciate some pointers (links)
into specific technologies used with dark fiber, as direct consumer (not
ISP). I am not looking for the theory behind (C)DWDM, but rather real life
implementations and experience with folks operating such.

Highly appreciated would also be extra info on what the learning curve
required for traditional network engineering crew to operate devices
terminating into such, and maybe even work (installation and operation)
needed to maintain plants with this infrastructure.

TIA,
***Stefan

Re: Looking for recommendation on 10G Ethernet switch

[Andrew Latham]

On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann  wrote:
> Colleagues,
>
> I'm looking for a recommendation on a smallish 10G Ethernet switch for a
> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
> iSCSI with some legacy boxes on GigE.
>
> Preferably
>
> - 8-16 10G ports
> - several GigE ports for legacy GigE hosts or cross connect to a legacy
> GigE  switch
> - preferably not a large chassis based solution with blades
>
> The hosts aren't going to be driving full line rate, nor the SAN boxes
> providing full line rate, but their offered loads will definitely exceed
> 1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
> with quad GigE cards.  Trying to find the best solution for > 1G on a
> trunk and < $50K per box.
>
> Any recommendations appreciated.
>
> Thanks
>
> EKG

This topic has been covered completely and often on the Beowulf list.
http://www.beowulf.org/pipermail/beowulf/ or do a site search via your
friendly search engine.

-- 
~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~

Looking for recommendation on 10G Ethernet switch

[Eric Germann]

Colleagues,

I'm looking for a recommendation on a smallish 10G Ethernet switch for a
small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
iSCSI with some legacy boxes on GigE.

Preferably

- 8-16 10G ports
- several GigE ports for legacy GigE hosts or cross connect to a legacy
GigE  switch
- preferably not a large chassis based solution with blades

The hosts aren't going to be driving full line rate, nor the SAN boxes
providing full line rate, but their offered loads will definitely exceed
1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
with quad GigE cards.  Trying to find the best solution for > 1G on a
trunk and < $50K per box.

Any recommendations appreciated.

Thanks

EKG

Re: IPv6 Netowrk Device Numbering BP

[Tore Anderson]

* Owen DeLong

> Yes, it was pointed out to me that for some silly reason passing
> understanding, that syntax is supported. It's absurd, but supported.
> Sigh
> 
> Probably we should deprecate it as it really doesn't make sense to 
> use it that way.

It absolutely does make sense, especially in the case of IPv4/IPv6
translation. For example, when using NAT64, "64:ff9b::192.0.2.33" is an
example of a valid IPv6 address that maps to 192.0.2.33. Much easier to
relate to for a human than "64:ff9b::c000:221" is.

Similarly, when using SIIT, the same syntax may be used in firewall
rules or ACLs. So if you want to open, say, the SSH port from a trusted
IPv4 address 192.0.2.33 on the far side of the SIIT gateway to your IPv6
server, it's much easier to open for "64:ff9b::192.0.2.33", and it will
also make your ACL much more readable to the next guy that comes along
than if you had used "64:ff9b::c000:221".

Also see RFC 6052 section 2.4.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

Re: Network scan tool/appliance horror stories

[Joakim Aronius]

* Jones, Barry (bejo...@semprautilities.com) wrote:
> I can share with you several stories personnel (both IT or vendors), who have 
> scanned Electric Utility environments with or without permission; and hence 
> caused multiple failures - including electro-mechanical systems and related 
> applications. Utilities typically utilize many industrial controllers - some 
> of which many IT personnel have no knowledge, and some are not robust enough 
> to weather the storm.
> 
> 1. Know your environment.
> 2. Know your tools.
> 3. Communicate.
> 

Second that. First agree on what rate they are allowed to scan your network, 
then let them come back with what they find before they point other tools at 
the found nodes. Then inform the owners of said nodes of what is going to 
happen.

In a previous life I found an publicly available SQL server on a network 
belonging to a medical institution that I was pen testing. I pointed Nessus at 
it and it just died... 

BR
/Joakim