Re: Some truth about Comcast - WikiLeaks style
- Original Message - > From: "Leo Bicknell" > After looking at many models I think Australia might be on to > something. The model is that a quasi-government monopoly provides > the last mile physical wire, but is unable to sell services on it. > Basically they only provide UNE's. Then, at the switching center > any ISP can pick up those UNE's and provide services. Competition > to the end user, while the last mile is always a single povider > limiting the issues above. Many cities are trying the same with > electric service, one companie provides the transport infrastructure > and when you select a generation provider. That's what I've been advocating, what Verizon *really* *REALLY* doesn't want to happen (to the point that they've been agitating -- successfully in some cases -- for state laws to forbid it), and what I think, based on not a lot of evidence, Google is quietly encouraging with their Big Secret Project. Last mile fiber *really is* a Natural Monopoly. And yeah, that's roughly how power competition was handled as well. Cheers, -- jra
Re: Some truth about Comcast - WikiLeaks style
- Original Message - > From: "JC Dill" > On 19/12/10 8:31 PM, Chris Adams wrote: > > Look up pictures of New York City in the early days of electricty. > > There were streets where you couldn't hardly see the sky because of > > all > > the wires on the poles. > > > Can you provide a link to a photo of this situation? Sure, though they're a bit harder to find on the web than you'd think; it took me almost 20 minutes to find this one when I wrote the piece: http://baylink.pitas.com/#LASTMILE Cheers, -- jra
Re: Some truth about Comcast - WikiLeaks style
On Thu, Dec 23, 2010 at 10:03, Jay Ashworth wrote: > - Original Message - >> From: "JC Dill" > >> On 19/12/10 8:31 PM, Chris Adams wrote: >> > Look up pictures of New York City in the early days of electricty. >> > There were streets where you couldn't hardly see the sky because of >> > all >> > the wires on the poles. >> > >> Can you provide a link to a photo of this situation? > > Sure, though they're a bit harder to find on the web than you'd > think; it took me almost 20 minutes to find this one when I > wrote the piece: > > http://baylink.pitas.com/#LASTMILE > Those look more like power lines, with a substation in the background. Try this: http://www.copper.org/publications/newsletters/innovations/1998/05/images/historical001.jpg from http://www.copper.org/publications/newsletters/innovations/1998/05/evolution.html or a drawing: http://blog.silive.com/sinotebook/2008/12/Broadway-1885.jpg Andrew
Re: Some truth about Comcast - WikiLeaks style
On Thu, Dec 23, 2010 at 10:14, Andrew Koch wrote: > Those look more like power lines, with a substation in the background. Helps to read the whole thing; you were talking about power lines. I missed a few messages when this took a turn off from last mile communications access. Anyway, found one more from Bangkok, which shows what you might be asking for with competing last mile technologies. http://www.vibrant.com/images/cables/bangkok-wires-nurmi.jpg Andrew
Re: Some truth about Comcast - WikiLeaks style
- Original Message - > From: "Robert Bonomi" > "Overbuild" is practical *ONLY* where: (a) the population density is > high,lowering 'per customer' costs, and (b) service 'penetration' is high > enough that the active subscriber base (as distinct from 'potential' > subscribers) sufficient to support the 'overhead' of two complete, parallel, > physical plants. This tends to be 'self-limiting', to up-scale, high-density > housing, neighborhoods. The 'raw economics' of the situation may well be > distorted by local government 'intrference' -- e.g., requiring a provider > serve > _all_ households within arbitrary boundaries, rather than just 'low hanging > fruit' areas. Yup. And that's just another argument in favor of muni fiber -- since it's municipal, it will by definition serve every address, and since it's monopoly, it will enable competition by making it practical for competitors to start up, since they'll have trival access to all comers. And since D-CATV is pretty much delivered over IP these days *anyway*, it won't even be technically difficult for cable providers to hook up customers over such a backbone. Gee... I wonder if the teeny little town I live in wants to be the first in our county to do that. :-) Cheers, -- jra
Muni Fiber Last Mile - a contrary opinion
I was poking around to see what the current received wisdom was as to average install cost per building for suburban municipal home-run fiber, and ran across this article, which discusses the topic, and itemizes several large such deployments that "failed" or had to be sold private. I'd be interested to see what comments nanogers have on this piece. I'm not well enough read to critically evaluate the guy's assertions. http://www.digitalsociety.org/2010/03/why-municipal-fiber-has-not-succeeded/ Cheers, -- jra
Re: TCP congestion control and large router buffers
Some more historical pointers: If you want to look at the early history of the latency discussion, look at Stuart Cheshire's famous rant "It's the Latency, Stupid" (http://rescomp.stanford.edu/~cheshire/rants/Latency.html). Then look at Matt Mathis's 1997 TCP equation (and the 1998 Padhye-Firoiu version of that): The throughput is proportional to the inverse square root of the packet loss and the inverse RTT -- so as the RTT starts growing due to increasing buffers, the packet loss must grow to keep equilibrium! We started to understand that you have to drop packets in order to limit queueing pretty well in the late 1990s. E.g., RFC 3819 contains an explicit warning against keeping packets for too long (section 13). But, as you notice, for faster networks, the bufferbloat effect can be limited in effect by intelligent window size management, but the dominating Windows XP was not intelligent, just limited in its widely used default configuration. So the first ones to fully see the effect were the ones with many TCP connections, i.e. Bittorrent. The modern window size "tuning" schemes in Windows 7 and Linux break a lot of things -- you are just describing the tip of the iceberg here. The IETF working group LEDBAT (motivated by the Bittorrent observations) has been working on a scheme to run large transfers without triggering humungous buffer growth. Gruesse, Carsten
Router only speaks IGP in BGP network
Dear all In my network, I have a router in a middle only speaks OSPF. is there any solution (without redistribute BGP into OSPF) for this kind of problem? thanks -- Tarig Y. Adam CTO - SUIN www.suin.edu.sd
Re: Some truth about Comcast - WikiLeaks style
On 12/23/10 9:19 AM, Jay Ashworth wrote: > And that's just another argument in favor of muni fiber -- since it's > municipal, > it will by definition serve every address, and since it's monopoly, it will > enable competition by making it practical for competitors to start up, since > they'll have trival access to all comers. Muni-fiber builds do not "by definition serve every address." Municipalities have their own priorities which tend to involve police/fire water treatment/waste handling. Having worked on fiber-builds/swaps with a couple of municipalities, and the corporations that they set up to manage their facilites it's one thing when it runds down the street in front of your building and quite another when you want to extend a spur to some far flug location on the edge of town. The fact that I can get a wavelength to county dump in Eugene OR the composting facility in Palo Alto doesn't really do anything for the residential access market.
Re: .gov DNSSEC operational message
- Original Message - > From: "Matt Larson" > The new KSK will not be published in an authenticated manner outside > DNS (e.g., on an SSL-protected web page). Rather, the intended > mechanism for trusting the new KSK is via the signed root zone: DS > records corresponding to the new KSK are already present in the root > zone. That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell. Why was that decision taken, Matt? Cheers, -- jra
RE: Muni Fiber Last Mile - a contrary opinion
> I'd be interested to see what comments nanogers have on this piece. I'm not > well enough read to critically evaluate the guy's assertions. I'm not familiar with a GPON system that provides gigabit to every subscriber under 'high congestion'.I do know of FTTN systems that can provide a lot more than 10/50 service to the end user (VDSL2 or ethernet over coax). What I really want to know is why 'Active Ethernet' didn't even make the chart... I got a chuckle out of this: "Provo County’s iProvo was hoping for 10,000 subscribers by July 2006 with the assumption that 75% of those customers would subscribe to lucrative triple play services, but the reality was 10,000 customers in late 2007 with only 17% of those customers subscribing to triple play" A 75% upsell rate to triple play packages seems ludicrous. I can't think of any industry that sees an upsell rate of 75% - can you (hell, I sold running shoes in high school, and the -target- upsell rate on shoestrings/socks/whatever-else was 15%). Nathan
RE: Router only speaks IGP in BGP network
Hi Andre That actually what I had done.. I thought it might be another solution many thanks -- Tarig Y. Adam SUIN Network Date: Thu, 23 Dec 2010 13:41:12 -0500 Subject: Re: Router only speaks IGP in BGP network From: anf...@gmail.com To: tariq198...@hotmail.com how about sending only a default into your OSPF domain from BGP? of course this can be a "conditional" type of redistribution;if you want no redistribution at all, then consider generating the default at your ASBR, which also can be conditional. without much more details on your topology, this is as vague an answer i can provide. cheers On Thu, Dec 23, 2010 at 1:18 PM, Tarig Yassin wrote: Dear all In my network, I have a router in a middle only speaks OSPF. is there any solution (without redistribute BGP into OSPF) for this kind of problem? thanks -- Tarig Y. Adam CTO - SUIN www.suin.edu.sd
RE: Muni Fiber Last Mile - a contrary opinion
> > A 75% upsell rate to triple play packages seems ludicrous. I can't > think of any industry that sees an upsell rate of 75% - can you (hell, > I sold running shoes in high school, and the -target- upsell rate on > shoestrings/socks/whatever-else was 15%). > > Nathan Well, I won't get rid of my "wired" phone for VOIP. The power where I live is subject to outage during storms but the phones work. I want a phone that works when the power is out for an extended period of time. At most, they would get "double play" from me (TV and Internet) and that' it. And based on discussions with others, many feel the same way about having their telephone depend on their cable box having power.
Re: Some truth about Comcast - WikiLeaks style
On Thu, Dec 23, 2010 at 10:17:46AM -0800, Joel Jaeggli wrote: [...] > The fact that I can get a wavelength to county dump in Eugene OR the > composting facility in Palo Alto doesn't really do anything for the > residential access market. Why not? You have to start with connectivity *somewhere*. If the economics work out, *someone* will build the residential access market from those access points. The first phone in a community was boon to everyone. Later, the local communications were build out to encompass others. The last mile ended up getting regulated to ensure everyone had access to the new technology. Unfortunately, the regulatory regime got based on the service (voice) rather than the infrastructure -- because no one ever guessed that the two would be separable. Some places could have local infrastructure monopolies run by municpalities, others might be run by local co-ops, the state, county, or even the feds. And they all might start with municipal fiber to the city dump that allows others access lamdas...
Re: Some truth about Comcast - WikiLeaks style
- Original Message - > From: "John Osmon" > On Thu, Dec 23, 2010 at 10:17:46AM -0800, Joel Jaeggli wrote: > [...] > > The fact that I can get a wavelength to county dump in Eugene OR the > > composting facility in Palo Alto doesn't really do anything for the > > residential access market. > > Why not? > > You have to start with connectivity *somewhere*. If the economics work > out, *someone* will build the residential access market from those > access points. Well, I think Joel's real point was that it's not necessarily a given that just because fiber's being installed by (or under contract to) a city or other municipality, that it will necessarily be run to *every single premise* in that municipality. And of course he's right, but there are lots of good reasons to do it that way; buildings often change occupancy and purpose, and the dump, of course, is *run* by the municipality very often, and you want all your official facilities connected up anyway. And doing it all as one build probably makes it easier to finance. My personal favorite reason to do this is that it *increases the property values in the municipality*, an assertion for which I have no documentary evidence or studies. :-) (To clarify there, by "this" I mean muni fiber in general, not necessarily passing every premise, though Metcalfe's Law probably applies here as well...) Cheers, -- jra
Re: Muni Fiber Last Mile - a contrary opinion
- Original Message - > From: "Nathan Eisenberg" > I got a chuckle out of this: > "Provo County’s iProvo was hoping for 10,000 subscribers by July 2006 > with the assumption that 75% of those customers would subscribe to > lucrative triple play services, but the reality was 10,000 customers > in late 2007 with only 17% of those customers subscribing to triple > play" > > A 75% upsell rate to triple play packages seems ludicrous. I can't > think of any industry that sees an upsell rate of 75% - can you (hell, > I sold running shoes in high school, and the -target- upsell rate on > shoestrings/socks/whatever-else was 15%). Indeed. And it seems worth noting that, unless I'm missing something, iProvo specifically violated the condition we all seem to agree is most important in such a build: they were not only the fiber op, but the content transport provider (ie, cable company/IAP). Cheers, -- jra
Re: Muni Fiber Last Mile - a contrary opinion
There is a large difference between muni-fiber that attempts to compete for some of the best customers (e.g. the following the tranditional overbuild method) and muni-fiber who's goal is universal service of fiber to the home. Basically it is the difference between a small entity (the town) going up against a large one (iLEC, CableCo) compared to the small entity trying to be a supplier to those folks... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpaxeBIlWl9M.pgp Description: PGP signature
Re: Router only speaks IGP in BGP network
In a message written on Thu, Dec 23, 2010 at 09:18:57PM +0300, Tarig Yassin wrote: > In my network, I have a router in a middle only speaks OSPF. > is there any solution (without redistribute BGP into OSPF) for this kind of > problem? Sounds like the textbook case of how folks use MPLS. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpZJoTt43z61.pgp Description: PGP signature
Re: Router only speaks IGP in BGP network
Hello Tarig, Setup a gre tunnel between the two bgp speakers and do ibgp over the gre tunnel? (not clean but it works) or mpls.. If you implement the other solution mentioned you're creating routing loops. On 23 December 2010 19:18, Tarig Yassin wrote: > > Dear all > > In my network, I have a router in a middle only speaks OSPF. > is there any solution (without redistribute BGP into OSPF) for this kind of > problem? > > thanks > > -- > Tarig Y. Adam > CTO - SUIN > www.suin.edu.sd > > > > -- Wouter Prins w...@null0.nl
RE: Router only speaks IGP in BGP network
You could use a GRE tunnel to get traffic from one edge BGP outer to the other edge BGP router. Then run BGP over this link. - Brian J. >-Original Message- >From: Tarig Yassin [mailto:tariq198...@hotmail.com] >Sent: Thursday, December 23, 2010 12:19 PM >To: nanog; af...@afnog.org >Subject: Router only speaks IGP in BGP network > > >Dear all > >In my network, I have a router in a middle only speaks OSPF. >is there any solution (without redistribute BGP into OSPF) for this kind of >problem? > >thanks > >-- >Tarig Y. Adam >CTO - SUIN >www.suin.edu.sd > > > > CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
Good MPLS/VPLS book?
Does anyone have a favorite book or resource discussing MPLS and all associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? I understand the basics of what MPLS is and how you create a circuit from A to B but I'm afraid it still escapes me when trying to figure out how someone would, say, create a multicast capable VPN with 5 edge points. Any pointers to a good way to reduce my level of ignorance on this subject would be appreciated. Vendor literature doesn't bother me as long as the concepts are there. Regards, Michael H.
Re: Good MPLS/VPLS book?
While on a MPLS related TAC case recently, I was speaking to an engineer who helped vet portions of Cisco Press' MPLS Fundamentals (http://www.ciscopress.com/bookstore/product.asp?isbn=1587051974). He said it's one of the best he's come across, but there may perhaps be some bias there ;) Not knowing any better, I picked it up and I'm learning quite a bit. It's also seems to be a great reference manual to keep around too. The Kindle version is handy for quick reference from mobile devices too. On 2010-12-23, at 5:49 PM, Michael Helmeste wrote: > Does anyone have a favorite book or resource discussing MPLS and all > associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? > > I understand the basics of what MPLS is and how you create a circuit from > A to B but I'm afraid it still escapes me when trying to figure out how > someone would, say, create a multicast capable VPN with 5 edge points. > > Any pointers to a good way to reduce my level of ignorance on this subject > would be appreciated. Vendor literature doesn't bother me as long as the > concepts are there. > > Regards, >Michael H. > >
RE: Good MPLS/VPLS book?
IMO the best book on the market is 'MPLS-Enabled Applications' by Ina Minei, Julian Lucek. It has the best coverage all the things you mentioned plus VPLS, P2MP LSP, draft-rosen and NG-VPN multicast architectures and the explanations are clear and concise. I wrote a review of this book a while back: http://www.shortestpathfirst.net/2009/11/30/book-review-mpls-aplications/ This book is awesome. You won't regret buying it. Stefan Fouant > -Original Message- > From: Michael Helmeste [mailto:mhelm...@uvic.ca] > Sent: Thursday, December 23, 2010 5:49 PM > To: nanog@nanog.org > Subject: Good MPLS/VPLS book? > >Does anyone have a favorite book or resource discussing MPLS and all > associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? > >I understand the basics of what MPLS is and how you create a circuit > from > A to B but I'm afraid it still escapes me when trying to figure out how > someone would, say, create a multicast capable VPN with 5 edge points. > >Any pointers to a good way to reduce my level of ignorance on this > subject would be appreciated. Vendor literature doesn't bother me as > long > as the concepts are there. > >Regards, > Michael H. >
.gov registrar problem
In case anyone else notices spotty problems resolving .gov names, I just sent the following message to regist...@dotgov.gov: I started investigating a dns issue after we received a few customer complaints regarding intermittent problems resolving hostnames under noaa.gov. After some in-depth investigation, I believe I’ve identified the issue. First, the query to see the list of authoritative name servers for .gov: # dig NS gov @c.root-servers.net ; <<>> DiG 9.6.1-P3 <<>> NS gov @c.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53495 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 7 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;gov. IN NS ;; AUTHORITY SECTION: gov. 172800 IN NS f.usadotgov.net. gov. 172800 IN NS a.usadotgov.net. gov. 172800 IN NS g.usadotgov.net. gov. 172800 IN NS b.usadotgov.net. gov. 172800 IN NS d.usadotgov.net. gov. 172800 IN NS e.usadotgov.net. gov. 172800 IN NS c.usadotgov.net. ;; ADDITIONAL SECTION: a.usadotgov.net. 172800 IN A 74.208.172.129 b.usadotgov.net. 172800 IN A 206.204.217.151 c.usadotgov.net. 172800 IN A 69.72.142.35 d.usadotgov.net. 172800 IN A 204.168.112.71 e.usadotgov.net. 172800 IN A 213.165.80.240 f.usadotgov.net. 172800 IN A 66.207.175.172 g.usadotgov.net. 172800 IN A 64.62.200.134 ;; Query time: 9 msec ;; SERVER: 192.33.4.12#53(192.33.4.12) ;; WHEN: Thu Dec 23 17:37:59 2010 ;; MSG SIZE rcvd: 258 The glue records show a.usadotgov.net with an ip of 74.208.172.129. Next, using one of the authoritative name servers for usadotgov.net, we resolve the a.usadotgov.net name: # dig a.usadotgov.net @DNSSEC7.DATAMTN.COM ; <<>> DiG 9.6.1-P3 <<>> a.usadotgov.net @DNSSEC7.DATAMTN.COM ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61276 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 10 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;a.usadotgov.net. IN A ;; ANSWER SECTION: a.usadotgov.net. 86400 IN A 76.73.18.236 You can see that the ip address is incorrect for that hostname. This is going to cause an issue where some responses for .gov addresses will come from a non-authoritative source and should be taken care of as soon as possible as this could potentially affect all .gov domains. -- Andy Harrison Lead Systems Engineer Metrocast Cablevision
Re: Router only speaks IGP in BGP network
> In my network, I have a router in a middle only speaks OSPF. > is there any solution (without redistribute BGP into OSPF) for this > kind of problem? uh, what exactly is the problem? i.e. what do you want to accomplish? and do NOT redistribute bgp into ospf. randy
Throttle traffic for a single local IP on a Linux router?
Hi, I know this might not be 100% on-topic and might be better suited for a Linux-distro mailinglist, but I hope to get more diverse methods from you networking experts. Basically, I have a small residential connection, 5 Mbit down, 0.5 Mbit up. A user on my local network, who we will call 192.168.1.105, is using too much bandwidth. I have tried social engineering to get him to stop, he claims to, but iftop says otherwise. My network is setup like this: Cable modem goes to eth0 on router running Ubuntu server, eth1 on the Ubuntu box goes to a wrt54gl (behaving purely as a bridge), and all clients are connected wirelessly. The Ubuntu box handles everything. So I have tried this script, and it does not work -- download speed gets limited just fine, but upload remains unlimited for some reason: TC=/sbin/tc OUTIF=eth0 # Interface for WAN (internet) INIF=eth1# Interface for LAN (internal network) DNLD=0.5mbit # DOWNLOAD Limit UPLD=0.1mbit # UPLOAD Limit IP=192.168.1.105 U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32" $TC qdisc del dev $INIF root $TC qdisc del dev $OUTIF root $TC qdisc add dev $INIF root handle 1: htb default 30 $TC qdisc add dev $OUTIF root handle 1: htb default 30 $TC class add dev $INIF parent 1: classid 1:1 htb rate $DNLD ceil $DNLD $TC class add dev $OUTIF parent 1: classid 1:1 htb rate $UPLD ceil $UPLD $TC filter add dev $INIF parent 1:0 ip pref 1 u32 match ip src $IP/32 0x flowid 1:1 $TC filter add dev $OUTIF parent 1:0 ip pref 1 u32 match ip dst $IP/32 0x flowid 1:1 Anyone see any problems in my setup, this script, or have any idea how I can limit the speeds of Mr. 192.168.1.105 without social engineering? Thank you for your time.
Re: .gov registrar problem
In message , Andy Harrison writes: > In case anyone else notices spotty problems resolving .gov names, I > just sent the following message to regist...@dotgov.gov: > > > > I started investigating a dns issue after we received a few customer > complaints regarding intermittent problems resolving hostnames under > noaa.gov. After some in-depth investigation, I believe I've > identified the issue. > > First, the query to see the list of authoritative name servers for .gov: > > # dig NS gov @c.root-servers.net > > ; <<>> DiG 9.6.1-P3 <<>> NS gov @c.root-servers.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53495 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 7 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;gov.IN NS > > ;; AUTHORITY SECTION: > gov.17280 0 IN NS f.usadotgov.net. > gov.17280 0 IN NS a.usadotgov.net. > gov.17280 0 IN NS g.usadotgov.net. > gov.17280 0 IN NS b.usadotgov.net. > gov.17280 0 IN NS d.usadotgov.net. > gov.17280 0 IN NS e.usadotgov.net. > gov.17280 0 IN NS c.usadotgov.net. > > ;; ADDITIONAL SECTION: > a.usadotgov.net.172800 IN A 74.208.172.129 > b.usadotgov.net.172800 IN A 206.204.217.151 > c.usadotgov.net.172800 IN A 69.72.142.35 > d.usadotgov.net.172800 IN A 204.168.112.71 > e.usadotgov.net.172800 IN A 213.165.80.240 > f.usadotgov.net.172800 IN A 66.207.175.172 > g.usadotgov.net.172800 IN A 64.62.200.134 > > ;; Query time: 9 msec > ;; SERVER: 192.33.4.12#53(192.33.4.12) > ;; WHEN: Thu Dec 23 17:37:59 2010 > ;; MSG SIZE rcvd: 258 > > The glue records show a.usadotgov.net with an ip of 74.208.172.129. > > Next, using one of the authoritative name servers for usadotgov.net, > we resolve the a.usadotgov.net name: > > # dig a.usadotgov.net @DNSSEC7.DATAMTN.COM > > ; <<>> DiG 9.6.1-P3 <<>> a.usadotgov.net @DNSSEC7.DATAMTN.COM > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61276 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1 > 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;a.usadotgov.net. IN A > > ;; ANSWER SECTION: > a.usadotgov.net.86400 IN A 76.73.18.236 > > You can see that the ip address is incorrect for that hostname. This > is going to cause an issue where some responses for .gov addresses > will come from a non-authoritative source and should be taken care of > as soon as possible as this could potentially affect all .gov domains. No, 76.73.18.236 is authoritative for gov as is 74.208.172.129. It would appear that a.usadotgov.net is being moved / re-hosted. Discrepencies such as this are normal when this is happening. ; <<>> DiG 9.6.0-APPLE-P2 <<>> soa gov +norec @76.73.18.236 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1312 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;gov. IN SOA ;; ANSWER SECTION: gov.259200 IN SOA A.USADOTGOV.NET. support.datamtn.com. 1293146225 3600 900 1814400 86400 ;; AUTHORITY SECTION: gov.259200 IN NS F.USADOTGOV.NET. gov.259200 IN NS E.USADOTGOV.NET. gov.259200 IN NS A.USADOTGOV.NET. gov.259200 IN NS D.USADOTGOV.NET. gov.259200 IN NS G.USADOTGOV.NET. gov.259200 IN NS B.USADOTGOV.NET. gov.259200 IN NS C.USADOTGOV.NET. ;; Query time: 231 msec ;; SERVER: 76.73.18.236#53(76.73.18.236) ;; WHEN: Fri Dec 24 10:38:24 2010 ;; MSG SIZE rcvd: 201 Mark > -- > Andy Harrison > Lead Systems Engineer > Metrocast Cablevision > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Sprint data network contact?
I'm trying to find a contact for someone who might know something about the proxies running on Sprint's data network. Basically our Android app uses a local http server to serve content to the Android media player, i.e. listening via 127.0.0.1. Unfortunately, a system update that Sprint pushed last week seems to enforce a Sprint proxy (pd.vog.sprintpcs.com:8085) on all HTTP & RTSP traffic... including traffic to 127.0.0.1, which as you can imagine, predictably fails. The EVO is our most popular Android device amongst our subscribers, and we're rapidly losing subscribers because of this problem. This breaks streaming for many Android apps that have to use a local content server (for a variety of reasons, some for playing encrypted content like ourselves, others who need to maintain backwards compatibility with <2.2 Android which lacked RTSP streaming). I'm running into brick walls so far and hoping that someone in NANOG might know a responsible network engineer at Sprint who could help resolve the issue quickly? cheers, steve -- stephen lau | st...@grommit.com | http://whacked.net | @stevel
Re: Good MPLS/VPLS book?
On Dec 23, 2010, at 5:49 PM, Michael Helmeste wrote: > Does anyone have a favorite book or resource discussing MPLS and all > associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? > > I understand the basics of what MPLS is and how you create a circuit from > A to B but I'm afraid it still escapes me when trying to figure out how > someone would, say, create a multicast capable VPN with 5 edge points. > > Any pointers to a good way to reduce my level of ignorance on this subject > would be appreciated. Vendor literature doesn't bother me as long as the > concepts are there. > > Regards, >Michael H. > > Designing and Implementing IP/MPLS-Based Ethernet Layer 2 VPN Services: An Advanced Guide for VPLS and VLL (Paperback) Zhuo Xu I thought was pretty good.
Anyone have a contact for CANTV.NET
Anyone have a contact for CANTV.NET without using CANTV.NET mailserver which is hosed, at least for abuse, support, and ipadmin which all fail? TIA, Tom
RE: Good MPLS/VPLS book?
Looks like a good book to add to my bookshelf. Cisco's MPLS fundamentals is also a good book although I'm only halfway through it > From: sfou...@shortestpathfirst.net > To: mhelm...@uvic.ca; nanog@nanog.org > Subject: RE: Good MPLS/VPLS book? > Date: Thu, 23 Dec 2010 18:06:03 -0500 > > IMO the best book on the market is 'MPLS-Enabled Applications' by Ina Minei, > Julian Lucek. It has the best coverage all the things you mentioned plus > VPLS, P2MP LSP, draft-rosen and NG-VPN multicast architectures and the > explanations are clear and concise. > > I wrote a review of this book a while back: > > http://www.shortestpathfirst.net/2009/11/30/book-review-mpls-aplications/ > > This book is awesome. You won't regret buying it. > > Stefan Fouant > > > -Original Message- > > From: Michael Helmeste [mailto:mhelm...@uvic.ca] > > Sent: Thursday, December 23, 2010 5:49 PM > > To: nanog@nanog.org > > Subject: Good MPLS/VPLS book? > > > >Does anyone have a favorite book or resource discussing MPLS and all > > associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? > > > >I understand the basics of what MPLS is and how you create a circuit > > from > > A to B but I'm afraid it still escapes me when trying to figure out how > > someone would, say, create a multicast capable VPN with 5 edge points. > > > >Any pointers to a good way to reduce my level of ignorance on this > > subject would be appreciated. Vendor literature doesn't bother me as > > long > > as the concepts are there. > > > >Regards, > > Michael H. > > > > >
Re: IPv6 BGP table size comparisons
On 12/21/10 2:18 PM, Frank Bulk wrote: > There are 4,035 routes in the global IPv6 routing table. This is what one > provider passed on to me for routes (/48 or larger prefixes), extracted from > public route-view servers. > AT&T AS7018: 2,851 (70.7%) > Cogent AS174: 2,864 (71.0%) > GLBX AS3549: 3,706 (91.8%) > Hurricane Electric AS6939: 3,790 (93.9%) > Qwest AS209: 3,918 (97.1%) > TINET (formerly Tiscali) AS3257: 3,825 (94.8%) > Verizon AS701: 3,938 (97.6%) Sprint (AS1239) is sending 3,779 routes. ~Seth
Re: Good MPLS/VPLS book?
Thanks for the suggestions, all! Looks like I have some reading to do. On Thu, 23 Dec 2010 18:49:46 -0500 Dan Snyder wrote: > > > On Dec 23, 2010, at 5:49 PM, Michael Helmeste wrote: > > > Does anyone have a favorite book or resource discussing MPLS and all > > associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? > > > > I understand the basics of what MPLS is and how you create a circuit from > > A to B but I'm afraid it still escapes me when trying to figure out how > > someone would, say, create a multicast capable VPN with 5 edge points. > > > > Any pointers to a good way to reduce my level of ignorance on this subject > > would be appreciated. Vendor literature doesn't bother me as long as the > > concepts are there. > > > > Regards, > >Michael H. > > > > > > Designing and Implementing IP/MPLS-Based Ethernet Layer 2 VPN Services: An > Advanced Guide for VPLS and VLL (Paperback) > Zhuo Xu > > I thought was pretty good.
Re: IPv6 BGP table size comparisons
On Thu, Dec 23, 2010 at 20:37, Seth Mattinen wrote: > On 12/21/10 2:18 PM, Frank Bulk wrote: >> There are 4,035 routes in the global IPv6 routing table. This is what one >> provider passed on to me for routes (/48 or larger prefixes), extracted from >> public route-view servers. >> AT&T AS7018: 2,851 (70.7%) >> Cogent AS174: 2,864 (71.0%) >> GLBX AS3549: 3,706 (91.8%) >> Hurricane Electric AS6939: 3,790 (93.9%) >> Qwest AS209: 3,918 (97.1%) >> TINET (formerly Tiscali) AS3257: 3,825 (94.8%) >> Verizon AS701: 3,938 (97.6%) > > Sprint (AS1239) is sending 3,779 routes. I'm seeing the following that haven't been mentioned yet: Internet 2 is sending - 4037 QWest AS209 is sending - 3974
Re: IPv6 BGP table size comparisons
On 12/23/10 6:02 PM, Scott Taylor wrote: > On Thu, Dec 23, 2010 at 20:37, Seth Mattinen wrote: >> On 12/21/10 2:18 PM, Frank Bulk wrote: >>> There are 4,035 routes in the global IPv6 routing table. This is what one >>> provider passed on to me for routes (/48 or larger prefixes), extracted from >>> public route-view servers. >>> AT&T AS7018: 2,851 (70.7%) >>> Cogent AS174: 2,864 (71.0%) >>> GLBX AS3549: 3,706 (91.8%) >>> Hurricane Electric AS6939: 3,790 (93.9%) >>> Qwest AS209: 3,918 (97.1%) >>> TINET (formerly Tiscali) AS3257: 3,825 (94.8%) >>> Verizon AS701: 3,938 (97.6%) >> >> Sprint (AS1239) is sending 3,779 routes. > > I'm seeing the following that haven't been mentioned yet: > Internet 2 is sending - 4037 > QWest AS209 is sending - 3974 internap 14745 is sending 3985 Nokia backbone 1248 has 3967 in it. 14803's fib has 4007 active external routes in it. >
Re: Wake on LAN in the enterprise
On 12/13/10 8:32 AM, Jack Bates wrote: > On 12/13/2010 10:20 AM, Owen DeLong wrote: >> WOL is unfortunately terribly deficient in that the spec. never >> envisioned the possibility >> of a need for wake on WAN. >> >> Bottom line, it's a non-routeable layer 2 protocol. Your choices boil >> down to the >> helper address nightmare you describe or proxy servers on every subnet. >> > > I would suspect that proxy servers being the better deal, though my > experience with Cisco is that you may have to use ASR type gear to get a > nicer layout (similar to service providers) where you can backend > everything to a radius server (I'm still waiting to test this myself, > but IOS is really weak on DHCP support). assuming you don't mind burning an ip address per subnet you can do this with a static arp entry for an ethernet multicast address even if your l3 platform doesn't allow subnet directed multicast. on a firewall platform basied on linux I specifically worked around the deliberate lack of subnet directed broadcast by natting from the broadcast address of the target subnet to an rfc 1918 address on the subnet with a static arp entry pointing at a multicast address. it worked fine, exploited the fact that rewrite occurs before forwarding on linux and allowed the use of a pre-existing management tool that used subnet directed broadcasts. > > Jack >
RE: Some truth about Comcast - WikiLeaks style
Uhm, D-CATV is not IP just quite yet. Sometimes I wish that's the case, but it's still very much RF. There are several vendors that sell GPON solutions that support RF over fiber, and there's always IP TV. Frank -Original Message- From: Jay Ashworth [mailto:j...@baylink.com] Sent: Thursday, December 23, 2010 11:20 AM To: NANOG Subject: Re: Some truth about Comcast - WikiLeaks style And since D-CATV is pretty much delivered over IP these days *anyway*, it won't even be technically difficult for cable providers to hook up customers over such a backbone.
