RE: eur.army.mil net ops contact?

2010-05-19 Thread Robert D. Scott
Normally you need to contact the entity you cannot reach, and they will open
a ticket backwards through MilNet. This is the only process I have been able
to get to work.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell

-Original Message-
From: Malte von dem Hagen [mailto:m...@hosteurope.de] 
Sent: Wednesday, May 19, 2010 7:31 AM
To: nanog@nanog.org
Subject: eur.army.mil net ops contact?

Hi there,

I need to get in contact with someone from (eur.)army.mil network operations
staff, since they seem to block our whole AS. Any hints how to reach them?

TIA && rgds,

Malte
--
Malte von dem Hagen
Teamleitung Network Engineering & Operation Abteilung Technik

---
Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln -
Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht
Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller

(*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt.
Mobilfunknetzen





RE: Rate of growth on IPv6 not fast enough?

2010-04-19 Thread Robert D. Scott

-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Monday, April 19, 2010 7:28 AM
To: Chris Campbell
Cc: nanog@nanog.org
Subject: Re: Rate of growth on IPv6 not fast enough?


On Apr 19, 2010, at 3:16 AM, Chris Campbell wrote:

> 
> On 19 Apr 2010, at 03:52, joel jaeggli wrote:
> 
>> On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote:
>>> Franck Martin wrote:
 Sure the internet will not die...
 
 But by the time we run out of IPv4 to allocate, the IPv6 network will
not have completed to dual stack the current IPv4 network. So what will
happen?
 
>>> 
>>> Reality is that as soon as SSL web servers and SSL-capable web browsers
>>> have support for name-based virtual hosts, the number of IPv4 addresses
>>> required will drop.  Right now, you need 1 IP address for 1 SSL site;
>>> SNI spec of SSL gets rid of that.
>> 
>> my load balancer needs 16 ips for every million simultaneous 
>> connections, so does yours.
>> 
> 
> I'm pretty sure that's not the case for inbound connections...
> 
> http://vegan.net/pipermail/lb-l/2008-June/000871.html
> 
Depends on which side of the loadbalancer you're talking about and how it is
configured.

Owen


Sounds like he is talking about a source NAT pool.  If the box will support
a million simultaneous PATS, it takes 16 addresses to make a PAT pool of
that size. But if you are routing in the data center they can be private, as
only the real servers will see them. If you had a need to do 1 arm across
the Internet a single NAT pool would provide service for a large number of
VIPS. These are featuress of an ACE.




RE: Telx - Atlanta

2010-02-04 Thread Robert D. Scott
Try this:
Telx Internet Exchange (TIE)
Support Phone: 404-325-2714
Email: t...@telx.com
Website: http://tie.telx.com 


Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Hale, William C [mailto:william.c.h...@windstream.com] 
Sent: Thursday, February 04, 2010 3:00 PM
To: nanog@nanog.org
Subject: Telx - Atlanta

Our normal contact for Telx at 56 Marietta has not responded in a couple
of days, does anyone have a 24x7 contact number for Telx at 56 Marietta
in Atlanta?
 
Regards,
Bill 
 
William C. Hale
Sr. Network Design Engineer
Windstream Communications
501.748.6526 office
501.690.0830 mobile
501.748.6487 fax
william.c.h...@windstream.com
 
 



***
The information contained in this message, including attachments, may
contain
privileged or confidential information that is intended to be delivered only
to the
person identified above. If you are not the intended recipient, or the
person
responsible for delivering this message to the intended recipient,
Windstream requests
that you immediately notify the sender and asks that you do not read the
message or its
attachments, and that you delete them without copying or sending them to
anyone else.




RE: Level 3 DC issues?

2010-01-29 Thread Robert D. Scott
Looks like an internal problem to BoA. The redirect works, and I get an
immediate reply. The https redirect page appears boinked. Even with a -k
curl took over 30 seconds to get the page, and the browser would have timed
out.

rob...@robert ~
$ curl -i -G www.bankofamerica.com
HTTP/1.1 301 Moved Permanently
Server: Sun-ONE-Web-Server/6.1
Date: Fri, 29 Jan 2010 19:25:08 GMT
Content-length: 122
Content-type: text/html
Location: https://www.bankofamerica.com/index.jsp
Connection: close

Moved Permanently
Moved Permanently
An error has occurred.

rob...@robert ~
$ curl -i -G www.bankofamerica.com
HTTP/1.1 301 Moved Permanently
Server: Sun-ONE-Web-Server/6.1
Date: Fri, 29 Jan 2010 19:25:28 GMT
Content-length: 122
Content-type: text/html
Location: https://www.bankofamerica.com/index.jsp
Connection: close

Moved Permanently
Moved Permanently
An error has occurred.

rob...@robert ~
$ curl -i -G https://www.bankofamerica.com/index.jsp
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

rob...@robert ~
$ curl -k -i -G https://www.bankofamerica.com/index.jsp


Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: John Palmer (NANOG Acct) [mailto:nan...@adns.net] 
Sent: Friday, January 29, 2010 2:22 PM
To: NANOG list
Subject: Level 3 DC issues?

Anyone see any connectivity issues with Level-3 in the DC area? This issue
is causing big latency problems
that appeared to have taken out Bank of America's website. 







RE: NAP MIA peering problems

2009-09-11 Thread Robert D. Scott
Major DC power issues at the NOTA.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Wolfgang Nagele [mailto:wnag...@ripe.net] 
Sent: Friday, September 11, 2009 9:17 AM
To: nanog@nanog.org
Subject: NAP MIA peering problems

Hi,

Anybody seeing peerings down at NAP Miami (198.32.124.0/23)?

Regards,
Wolfgang






nanog@nanog.org

2009-09-03 Thread Robert D. Scott
Work through your provider, I would start with you local end.  They should
help you, you ARE their customer.  If not, you need a new provider. Look
into out of band management.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Brian Raaen [mailto:bra...@zcorum.com] 
Sent: Thursday, September 03, 2009 7:29 AM
To: nanog@nanog.org
Subject: Need Help Getting IP Unblocked by AT&T

I'm not sure where to take this issue.  The Regular AT&T NOC contacts are
refusing to talk to me since I do not have a circuit ID, and do not seem to
have any understanding about transiting issues.  I am unable to fully
monitor and manage a router I control, as all traffic bound to its lan IP
that transits through the AT&T network is blocked.  The Router is connected
to a Verizon circuit, but any connection that transits through AT&T is
blocked.  The ip in Question is from a direct ARIN allocation that I
control.  I have attached a ping demonstrating that I am receiving an ICMP
deny from an AT&T core router.  I have also attached a traceroute to both
the offending IP and the WAN IP which appears to be working.

bra...@brian-debian:~$ ping gw.bwtc.net
PING gw.bwtc.net (72.14.76.1) 56(84) bytes of data.
>From 12.89.27.105 icmp_seq=1 Packet filtered From 12.89.27.105 
>icmp_seq=3 Packet filtered
^C
--- gw.bwtc.net ping statistics ---
4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3004ms


bra...@brian-debian:~$ sudo traceroute-nanog -AO gw.bwtc.net [sudo] password
for braaen:
traceroute to gw.bwtc.net (72.14.76.1), 64 hops max, 40 byte packets
 1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms
3 ms  3 ms
 2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms
3 ms  4 ms
 3  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  13 ms
69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
 4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  12 ms  35 ms  17 ms
 5  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net [MPLS: Label 673 Exp 0]  15 ms  14 ms  25 ms
 6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net  14 ms  14 ms  18 ms
 7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  14 ms  12 ms  14 ms
 8  border11.tge3-3.qts-1.acs.pnap.net (64.94.3.113) [AS14745]
hostmas...@pnap.net  14 ms  14 ms  14 ms
 9  core1.te2-2-bbnet2.acs002.pnap.net (64.94.0.79) [AS14745]
hostmas...@pnap.net  14 ms core1.te2-1-bbnet1.acs002.pnap.net
(64.94.0.15) [AS14745] hostmas...@pnap.net  14 ms 12.86.102.5
(12.86.102.5) [] rm-hostmas...@ems.att.com  14 ms 10  12.86.102.5
(12.86.102.5) [] rm-hostmas...@ems.att.com  13 ms
23 ms  13 ms
11  cr1.attga.ip.att.net (12.122.141.2) [] rm-hostmas...@ems.att.com
[MPLS: Label 16745 Exp 0]  40 ms cr2.ormfl.ip.att.net (12.122.5.141)
[] rm-hostmas...@ems.att.com
[MPLS: Label 20348 Exp 0] More labels  40 ms More labels  40 ms
12  cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmas...@ems.att.com
More labels  40 ms More labels  41 ms More labels  40 ms
13  cr2.nwrla.ip.att.net (12.122.30.77) [] rm-hostmas...@ems.att.com
[MPLS: Label 0 Exp 0] More labels  40 ms gar1.nwrla.ip.att.net
(12.123.153.85) [] rm-hostmas...@ems.att.com  38 ms  38 ms
14  gar1.nwrla.ip.att.net (12.123.153.85) [] rm-hostmas...@ems.att.com
50 ms  38 ms  38 ms
15  12.89.27.106 (12.89.27.106) [] rm-hostmas...@ems.att.com  43 ms
44 ms  44 ms
16  * * 12.89.27.105 (12.89.27.105) [] rm-hostmas...@ems.att.com
44 ms !A




bra...@brian-debian:~$ sudo traceroute-nanog -AO 157.130.26.166 traceroute
to 157.130.26.166 (157.130.26.166), 64 hops max, 40 byte packets
 1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  4 ms
3 ms  6 ms
 2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms
3 ms  3 ms
 3  rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  14 ms
13 ms  13 ms
 4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms  13 ms  12 ms
 5  66.0.192.194 (66.0.192.194) [AS20141] d...@deltacom.net  13 ms  13 ms  15
ms
 6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net [MPLS: Label 673 Exp 0]  30 ms
ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  14 ms gig4-16.core2.suw1.qualitytech.com
(64.88.172.145) [AS20141] dnsad...@globix.net  34 ms
 7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  19 ms  13 ms  13 ms
 8  core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745]
hostmas...@pnap.net  14 ms core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67)
[AS14745] hostmas...@pnap.net  14 ms

RE: Sprint/Verizon BGP

2009-08-05 Thread Robert D. Scott
They will almost always prefer their IBGP to any learned routes.  Why send
traffic to a transit network and skew their I/O peering numbers when you can
handle it yourself. I doubt you will change their mind.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Edward Brookhouse [mailto:eb...@setuidzero.org] 
Sent: Wednesday, August 05, 2009 11:36 AM
To: nanog@nanog.org
Subject: Sprint/Verizon BGP

Hi all, 

 

Any Sprint BGP admins on this list can offer any thoughts on why Sprint
connected networks are preferring my Sprint connection when they should be
preferring my Verizon?

 

I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and
63.78.31.0/24, being announced by sprint and Verizon, preferred to
Verizon(DS3) over Sprint 3MB.

 

Verizon BGP admins think everything is ok, have not heard back from BGP4 at
sprint.

 

Any thoughts appreciated, off-list contact welcome.

 

Edward

eb...@healthydirections.com

 

 






RE: Anomalies with AS13214 ?

2009-05-11 Thread Robert D. Scott
It looks like Cyclops is seeing these from AS 48285, but I see no indication
they are being advertised to any production upstream provider. Our /16 is
being alerted in Cyclops, but I can not find any advert on any looking
glass.

>From Cyclops:
BGP protocol Time (UTC) W/A/B Peer IP Peer ASN Prefix AS_PATH Origin
NEXT_HOP LOCAL_PREF MED Community Atomic Agg Aggregator 
BGP4MP 1242044196 A 194.71.0.1 48285 128.227.0.0/16 48285 13214 INCOMPLETE
194.71.0.1 0 0  NAG  

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: James Kelty [mailto:jke...@pandora.com] 
Sent: Monday, May 11, 2009 12:20 PM
To: nanog@nanog.org
Subject: Re: Anomalies with AS13214 ?

Seeing the same issues with AS13214 and no corresponding drop in  
traffic, route views doesn't show any rogue adverts for out prefixes  
either.

-James

On May 11, 2009, at 9:01 AM, Vincent Hoffman wrote:

> On 11/5/09 16:30, Jay Hennigan wrote:
>> We're getting cyclops[1] alerts that AS13214 is advertising itself as
>> origin for all of our prefixes.  Their anomaly report shows thousands
>> of prefixes originating there.
>>
>> Anyone else seeing evidence of this or being affected?
>>
>>
>> [1] http://cyclops.cs.ucla.edu/
>>
>
> I'm seeing alerts for AS13214 advertising our prefixes from
> cyclops also.  However a quick look at a few looking glasses and route
> servers doesnt seem to show any rogue advertisments, and we havent see
> any drop in traffic as yet.
>
> Vince
>
>>
>> -- 
>> 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
>
>



"Ravioli is the square root of pasta."
- Max K., Age 11















RE: DSX cross-connect solution

2009-05-04 Thread Robert D. Scott
You would get better density from a 110 patch than a 66, and telco frames
for 19 and 23 are readily available.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: sjk [mailto:s...@sleepycatz.com] 
Sent: Monday, May 04, 2009 3:56 PM
To: nanog@nanog.org
Subject: DSX cross-connect solution

I am trying to find hardware for a rebuild of our DS1 cross-connect
frame and can't seem to find much out there. We've got ~300 DS1s that
need to be x-connected between our M13s and I'm seeking an easy to
manage solution. I've looked at the Telect panels but I'm concerned that
my staff can't deal with wirewrap terminations. Has anyone seen, simply,
a high density 66 field that can fit in a 23" rack?

TIA -- steve






RE: Google Over IPV6

2009-03-27 Thread Robert D. Scott
Their press would indicate that more than www is IPV6. 

When I posted my original note, I was not really looking for end user
feedback, but rather is anyone peering V6 with them on either a public
fabric or private peer. Any idea if they have native V6 transit, or are
tunneling, and to where.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Grzegorz Janoszka [mailto:grzeg...@janoszka.pl] 
Sent: Friday, March 27, 2009 10:55 AM
To: Daniel Verlouw
Cc: nanog@nanog.org
Subject: Re: Google Over IPV6

Daniel Verlouw wrote:
> yes. We participate in the Google IPv6 trial program so our recursors
> get  records for www.google.com and so far it's been great, no
> issues whatsoever.

Same experiences - it just works.

> dan...@jun1> traceroute www.google.com
> traceroute6 to www.l.google.com (2001:4860:a003::68) from
> 2001:7f8:1::a501:2859:2, 64 hops max, 12 byte packets
>  1  pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1)  2.388 ms  1.798
> ms  1.712 ms
>  2  2001:4860::23 (2001:4860::23)  8.664 ms  8.480 ms  8.364 ms
>  3  2001:4860:a003::68 (2001:4860:a003::68)  8.624 ms  8.639 ms  8.719
> ms

Yes, but only www records have  record, the domain (google.com 
without www prefix) is still IPv4 only.


-- 
Grzegorz Janoszka






Google Over IPV6

2009-03-27 Thread Robert D. Scott
http://www.google.com/intl/en/ipv6/

http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html

Any one making use of Google IPV6?

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell






Seeking Connectivity in IRAQ

2009-03-16 Thread Robert D. Scott
A unit within the University has need to get reliable network connectivity
to Iraq, more specifically Baghdad. I was wondering if any nanogers have any
recommendations and/or contacts with providers in the area. Wired or
Wireless. Off-list is fine.

TIA

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell






RE: From San Jose to Google.com - via Europe

2009-02-06 Thread Robert D. Scott
I have had similar steaming issues with XMRadio. If I am at home and have a
VPN tunnel open to campus my XM steam is poor and choppy on a regular basis.
I need to open the stream before my VPN to get high quality. Different DNS,
the tunnel DNS does not reflect the same path to the stream. Akamai instead
of google.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Paul Ferguson [mailto:fergdawgs...@gmail.com] 
Sent: Friday, February 06, 2009 7:11 PM
To: Tony Rall
Cc: nanog@nanog.org
Subject: Re: From San Jose to Google.com - via Europe

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Feb 6, 2009 at 3:55 PM, Paul Ferguson 
wrote:

>
> On Fri, Feb 6, 2009 at 3:51 PM, Tony Rall  wrote:
>
>> Maybe you didn't read the thread "L3: Google from DC via the
>> Netherlands? "
>>
>> Probably the same issue (your nameserver is now perhaps quite remote
>> from you).
>>
>
>
> No, I guess I missed it, but reviewing the archives I see my question is
> already answered.
>
> Thanks for that -- sorry for the noise.
>

Just as an FYI, I did determine (hint from earlier thread) that I take "the
long route" when I am connected to my corporate SLL VPN (which forces DNS
resolution priority to my corporate DNS servers), but when I disconnect, I
take the short route (and use OpenDNS servers for DNS resolution)...

Go figure.

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFJjNGRq1pz9mNUZTMRAhioAKDgg3dm8noVz3EfMjs5+H2xloYgfACfepCc
a1LREz0mST06K4EMODI8yZQ=
=DvNx
-END PGP SIGNATURE-


-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/






RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

2009-02-05 Thread Robert D. Scott
Wii should not even consider developing " a cool new protocol for the Wii"
that is not NAT compliant via V4 or V6. And if they do, we should elect a
NANOG regular to go "POSTAL" and handle the problem. The solution to many of
these networking conundrums should rest with the application people, and NOT
the network people.

While I am ranting, my other pet peeve are proprietary protocols that the
developer cannot take another couple of hours to provide a decoder for. If
you develop the protocol any of the developers at the Wireshark group would
help with the decode plugin.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Sven-Haegar Koch [mailto:hae...@sdinet.de] 
Sent: Thursday, February 05, 2009 7:11 PM
To: John Osmon
Cc: NANOG list
Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP
space (IPv6-MW)]

On Thu, 5 Feb 2009, John Osmon wrote:

> On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote:
> > [...] I've lived quite productively behind a single IPv4 address for  
> > nearly 15 years.  I've run 1000 user networks that only used one IPv4  
> > address for all of them.  I have 2 private /24's using a single public  
> > IPv4 address right now -- as they have been for 6+ years.  Yet, in the
new  
> > order, you're telling me I need 18 billion, billion addresses to cover 2

> > laptops, a Wii, 3 tivos, a router, and an access point? 
> 
> Thank you.  Your ability to live with proxied/NATed Internet access has
> helped stave off the problems we're seeing now.  
> 
> The flip side shows up when Nintendo creates a cool new protocol for the
Wii
> that requires Internet access.  You Wii won't be able to participate
> until you teach your proxy/NAT box about the new protocol.

What's the difference to firewalling without NAT? (Noone should connect 
their (home) network without at least inbound filtering) There I have to 
wait for the firewall box to support connection tracking for the new 
(broken) protocol.

If the end-users really get public addresses for their WII and game-PCs, 
do you really think they won't just open the box totally in their 
firewall/router and catch/create even more problems?

c'ya
sven

-- 
The lights are fading out, once more...






RE: Level(3) Issues

2008-09-19 Thread Robert D. Scott
No issues Tampa to San Fran.

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Paul Stewart [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 19, 2008 9:17 AM
To: James Baldwin; nanog@nanog.org
Subject: RE: Level(3) Issues

Can you post a couple of IP's ?  We're out of Level(3) Detroit node and
don't see anything towards Disney.com etc

Paul


-Original Message-
From: James Baldwin [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 19, 2008 8:01 AM
To: nanog@nanog.org
Subject: Level(3) Issues

Is anyone else experiencing increased latency or packet loss through the
Level3/Broadwing network? I have seen sporadic packet loss to several
locations nationally over the last several hours.


 



"The information transmitted is intended only for the person or entity to
which it is addressed and contains confidential and/or privileged material.
If you received this in error, please contact the sender immediately and
then destroy this transmission, including all attachments, without copying,
distributing or disclosing same. Thank you."






RE: [Fwd:] Nvidia NICs with duplicate mac addresses

2008-09-05 Thread Robert D. Scott
The Marvel NIC presents the MAC as what we believe to be part of dot1x
negotiation. These were new Dells out of the box, not yet infected.  If we
disable dot1x on the NIC the problem goes away.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/re
lease/12.2_44_se/release/notes/OL14629.html#wp885689

Cisco's Recommendation: Replace the NIC

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Jon Kibler [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 05, 2008 12:56 PM
To: nanog@nanog.org
Cc: 'Robert E. Seastrom'
Subject: Re: [Fwd:] Nvidia NICs with duplicate mac addresses

-BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert D. Scott wrote:
> Does this MAC present itself all the time, or just during boot?
> 
> Marvel makes a NIC prevalent in some Dell systems, that presents MAC
> 0c00.. during its startup process. If you run port security, and
> several people boot their computer within the cam table expiration period,
> port security will disable the port. You can work around it but it is time
> consuming in large networks where port security are enabled.
> 

I know that this doesn't apply here, but a year or so ago I had a client
that had issues with port security continually dropping an end user's
PC. The problem was the MAC address kept changing from Realtek to Cisco.
Sometimes the same NIC would present both MACs at the same time.

It turned out the box was apparently infected with something. Never
could find anything specific (even when booting the Windows box from
Knoppix and scanning for unusual files) except for some large ADS files
that where apparently encrypted. A clean wipe and complete rebuild of
the box fixed the problem.

Jon
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
o: 843-849-8214
c: 843-224-2494
s: 843-564-4224

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjBZLQACgkQUVxQRc85QlMUpwCfQXrML+jZ8Lkwh3z2QuvldWh6
6+YAn3eqq2GBv7qof+urEGtibAKQf/6m
=un9B
-END PGP SIGNATURE-




==
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.





RE: [Fwd:] Nvidia NICs with duplicate mac addresses

2008-09-05 Thread Robert D. Scott
Does this MAC present itself all the time, or just during boot?

Marvel makes a NIC prevalent in some Dell systems, that presents MAC
0c00.. during its startup process. If you run port security, and
several people boot their computer within the cam table expiration period,
port security will disable the port. You can work around it but it is time
consuming in large networks where port security are enabled.

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Robert E. Seastrom [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 05, 2008 10:33 AM
To: nanog@nanog.org
Subject: [Fwd:] Nvidia NICs with duplicate mac addresses


Forwarded to NANOG in the interests of wider awareness...  having been
there and torn out my already scarce hair, duplicate MAC addresses can
really mess up your day...

---

Just when you thought this couldn't happen any more...

Copying from a different email list...

mac address 04:4b:80:80:80:03, was showing up in multiple places  
across the network. I googled the mac address and discovered that  
other people are having the same issue with this mac address. Below  
are some links describing the problem:

http://forums.nvidia.com/index.php?showtopic=22148
http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html


I just wanted everyone to know about this problem in case you run  
across similar slow "connectivity" issues. I believe the network card  
is made by NVIDIA.







RE: interger to I P address

2008-08-27 Thread Robert D. Scott
The harder way:

Decimal: 1089055123
Hex (dashes inserted at octals): 40-E9-A9-93
Decimal (of each octet): 64-233-169-147
IP Address: 64.233.169.147

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Matlock, Kenneth L [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 27, 2008 9:47 AM
To: Iljitsch van Beijnum
Cc: nanog@nanog.org
Subject: RE: interger to I P address

Huh, learn something new every day!

Well, at least my method shows the underlying theory behind how the
conversion works :)

Thanks!

Ken Matlock
Network Analyst
(303) 467-4671
[EMAIL PROTECTED]
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 27, 2008 6:27 AM
To: Matlock, Kenneth L
Cc: Colin Alston; kcc; nanog@nanog.org
Subject: Re: interger to I P address

On 27 aug 2008, at 14:18, Matlock, Kenneth L wrote:

> Easiest way.

$ ping 1089055123
PING 1089055123 (64.233.169.147): 56 data bytes
64 bytes from 64.233.169.147: icmp_seq=0 ttl=242 time=105.418 ms
64 bytes from 64.233.169.147: icmp_seq=1 ttl=242 time=105.891 ms
^C
--- 1089055123 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 105.418/105.655/105.891/0.236 ms

:-)






Comcast Gets FCC Slap on Wrist

2008-08-12 Thread Robert D. Scott
http://www.networkworld.com/newsletters/frame/2008/081108wan1.html


Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell





RE: Exploit for DNS Cache Poisoning - RELEASED

2008-07-23 Thread Robert D. Scott
Actually you are not missing anything. It is a brute force attack. I think
you had the right concept when you indicated that "networks and  hardware
may be fast enough". It is not maybe, it is; and every script kiddie on your
block has the power in his/her bedroom. Then you add the college crowd
sitting on 10Gig pipes to the Internet and the threat is real. But other
than just muck things up where is the motivation for a poisoning?

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell



-Original Message-
From: Joe Greco [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 23, 2008 6:31 PM
To: Robert D. Scott
Cc: [EMAIL PROTECTED]
Subject: Re: Exploit for DNS Cache Poisoning - RELEASED

> Now, there is an exploit for it.
> 
> http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Maybe I'm missing it, but this looks like a fairly standard DNS exploit.

Keep asking questions and sending fake answers until one gets lucky.

It certainly matches closely with my memory of discussions of the
weaknesses in the DNS protocol from the '90's, with the primary difference
being that now networks and hardware may be fast enough to make the
flooding (significantly) more effective.  I have to assume that one other
standard minor enhancement has been omitted (or at least not explicitly
mentioned), and will refrain from mentioning it for now.

So, I have to assume that I'm missing some unusual aspect to this attack.
I guess I'm getting older, and that's not too shocking.  Anybody see it?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then
I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN)
With 24 million small businesses in the US alone, that's way too many
apples.





Exploit for DNS Cache Poisoning - RELEASED

2008-07-23 Thread Robert D. Scott
Now, there is an exploit for it.

http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell







Re: [NANOG] Multihoming for small frys?

2008-05-20 Thread Robert D. Scott
The /24 address block has to be portable, an assignment, or the owner needs
to grant the secondary advertiser an LOA to readvertise that block. The LOA
is pretty common, but some ISPs may require you to renumber to get into
address space they will permit you to use and multihome. As always your
mileage may vary. 


Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611

-Original Message-
From: david raistrick [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 20, 2008 3:32 PM
To: William Herrin
Cc: nanog@nanog.org
Subject: Re: [NANOG] Multihoming for small frys?

On Tue, 20 May 2008, William Herrin wrote:

> The last I heard, the way to make this happen was: Find a service 
> provider with IP blocks available in ARIN's set of /8's that permit

that part isn't required.   Generally any /24 will do in my 
experience except for specific cases.

Other than that, you've got it about right.





---
david raistrickhttp://www.netmeister.org/news/learn2quote.html
[EMAIL PROTECTED] http://www.expita.com/nomime.html


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog



___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog


Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but nottotally consecutive)

2008-05-16 Thread Robert D. Scott
OH, You mean like putting a sniper in a bunch of trees. They know that
tactic well.  :)

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611


-Original Message-
From: Dorn Hetzel [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 16, 2008 1:59 PM
To: Jeroen Massar
Cc: NANOG list
Subject: Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but
nottotally consecutive)


Perhaps it is an attempt to make their address space so sparsely populated
that it's close to impossible to find a host without knowing it's address in
the first place?

On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar <[EMAIL PROTECTED]> wrote:

> Hi folks,
>
> As everybody is a big fan of securing their networks against foreign
> attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that
> is, not IPv4, they all come from a single IPv6 /13 though, which is what
> they apparently asked for in the beginning, at least that was the rumor,
> well they got what they wanted.
>
> I've recorded it into GRH as a single /13 though, as that is what it is,
> and I am not going to bother whois'ing and entering the 14 separate
> entries there, as that is useless, especially as they will most likely
> never appear in the global routing tables anyway.
>
> Depending on your love for the US, you might want to add special rules
> in your network to be able to easily detect Cyber Attacks and other such
> things towards that address space, to be able to better serve your
> country, may that be the US or any other country for that matter.
>
> I am of course wondering why ARIN gave 1 organization 14 separate /22's,
> even though they are recorded exactly the same, just different prefixes
> and netnames and it is effectively one huge /13. They could easily have
> been recorded as that one /13, it is not like eg Canada (no other
> countries that fall under ARIN now is there) will get a couple of the
> chunks of remaining space in between there. By assigning them separate
> /22's, they effectively are stating that it is good to fragment the
> address space and by having them recorded in whois, also that announcing
> more specifics from that /13 is just fine.
>
> The other fun question is of course what a single organization has to do
> with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which
> cover 2.251.799.813.685.248 /64's which is a number that I can't even
> pronounce. According to Wikipedia the US only has a mere population of
> 304,080,000, that means that every US citizen can get a 1000+ /48's from
> their DoD, thus maybe every nuclear warhead and every bullet is getting
> their own /48 or something to be able to justify for that amount of
> address space. At least this gives the opportunity to hardcode that
> block out of hardware if you want to avoid it being ever used by the
> publicly known part of the US DoD. I wouldn't mind seeing the request
> form that can justify this amount of address space though, must be a lot
> of fun.
>
> Now back to your regular NANOG schedule
>
> Greets,
> Jeroen
>
> (who will hide himself in a nice Swiss nuclear bunker till the flames
> are all gone ;)
>
> 1) http://en.wikipedia.org/wiki/United_States
>which points to: http://www.census.gov/population/www/popclockus.html
>
>
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
>
___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog



___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog


Re: [NANOG] DWDM

2008-04-25 Thread Robert D. Scott
www.nlr.net  www.internet2.edu

These are the major players in the Education RONS that are self owned and
managed. The nlr site will show the regional


Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611


-Original Message-
From: Scott E. MacKenzie [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 25, 2008 4:00 AM
To: NANOG
Subject: [NANOG] DWDM


Does anyone know where I can locate a list of DWDM networks deployed for
Education, Science & Research, and Commercialization?

We need to determine the practicality of DWDM use...


Scott 

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog



___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog