Re: maximum ipv4 bgp prefix length of /24 ?

[Robert Blayzor via NANOG]

On 9/29/23 03:34, Mark Tinka wrote:

RAM is not the issue... it's FIB.

If you pay me for FIB slots, I'm happy to install /32's to your heart's 
content .



And convergence times to process all that extra noise...

The line in the sand has been drawn; just say no to >/24 ...

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: maximum ipv4 bgp prefix length of /24 ?

[Robert Blayzor via NANOG]

Trolling NANOG on this subject?

Let me get my popcorn...

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/


On 9/28/23 17:25, VOLKAN SALİH wrote:

hello,

I believe, ISPs should also allow ipv4 prefixes with length between 
/25-/27 instead of limiting maximum length to /24..

NY Verizon FIOS IPv6 routing issue

[Robert Blayzor via NANOG]

Any Verizon IP engineers lurking on this list that can contact me about 
a recurring and chronic IPv6 routing issue in the upstate NY Verizon 
FIOS network. Getting feedback from several customers that have valid 
IPv6 PD from FIOS but routing is broken 2-3 hops out in Verizons 
network. This is causing major service issues with anyone that has IPv6 
enabled.


Happy to provide details or work the proper channels; if only you could 
easily find that information...


--
inoc.net!rblayzor
Email: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

VM hosting with full BGP feed

[Robert Blayzor via NANOG]

Looking for a VPS that can do a FreeBSD VM/Jail and can provide a full 
BGP route view.


Anyone know of some place that would do this? Please contact me off 
list, thank yuou.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Robert Blayzor via NANOG]

On 10/4/22 09:19, Mike Hammett wrote:
Sorta like in the IP world, if everyone did BCP38/84, amplification 
attacks wouldn't exist. Not everyone does, so...



Wouldn't exist? Maybe only in part, BCP38/84 does nothing for a majority 
of DDoS amp attacks. Most traffic is coming from legit/botted sources.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Aftermarket switches that were manufactured in any sort of quantity?

[Robert Blayzor via NANOG]

On 6/9/22 15:07, Saku Ytti wrote:

They're not really particularly cheap, they are 'market rate', you can
get 'market rate' from multiple suppliers, directly from manufacturers
too. They are only cheaper than most EU+US resellers, that's about it.



Are they "cheap" or is everyone else just "overpriced". ?  Thats the 
real question. Of course it all comes down what you're willing to pay 
for it.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Cogent RPKI invalid filtering

[Robert Blayzor via NANOG]

According to Cloudflares isbgpsafeyet.com, Cogent has been considered 
"safe" and is filtering invalids.


But I have found that to be untrue (mostly). It appears that some days 
they filter IPv4, sometimes not, and IPv6 invalids are always coming 
through. I know it's Cogent, but curious as to what others are seeing.




invalid.rpki.cloudflare.com has address 103.21.244.15
invalid.rpki.cloudflare.com has address 103.21.244.14
invalid.rpki.cloudflare.com has IPv6 address 2606:4700:7000::6715:f40e
invalid.rpki.cloudflare.com has IPv6 address 2606:4700:7000::6715:f40f



BGP routing table entry for 103.21.244.0/24
  174 13335, (aggregated by 13335 172.69.172.1)
  Origin IGP, metric 83040, localpref 100, valid, external, best, 
group-best, import-candidate

  Community: 174:21101 174:22012


BGP routing table entry for 2606:4700:7000::/48
  174 13335, (aggregated by 13335 172.69.172.1)
2001:550:2f01:: from 2001:550:2f01:: (66.28.1.115)
  Origin IGP, metric 83040, localpref 100, valid, external, best, 
group-best, import-candidate

  Received Path ID 0, Local Path ID 1, version 1272502628
  Community: 174:21101 174:22012


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Robert Blayzor via NANOG]

On 4/22/2021 9:30 AM, Tom Beecher wrote:
While I agree with the overall sentiment of your message, I am curious ; 
have there been any instances where an internet provider has been found 
liable (criminally or civilly) for willfully misrepresenting IP 
geolocation information?


How could there be? Isn't geolocation data just a "best guess" where the 
endpoint may be? Technically you could route an IP (at least a /24) 
almost anywhere. What about anycast prefixes?

Re: OOB management options @ 60 Hudson & 1 Summer

[Robert Blayzor via NANOG]

On 4/15/21 6:14 PM, Matthew Crocker wrote:

I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer




I'm in both locations as well. We have a 10MB static IP connection for 
them and I think it's like $50/mo. Depends on how "out of band" you want 
it to be.


I also think Markley @ 1 summer offers something similar.

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Zayo or HE for IP transit

[Robert Blayzor via NANOG]

On 4/19/21 5:30 PM, James Lumby wrote:
What is the current experience with Zayo or HE?  I’m looking at possibly 
adding one of them into a mix of cogent and a mix from my datacenter.  
Would be using BGP full routes.  Any experiences would be appreciated.



Well AFAIK Zayo is not filtering invalid ROA's from their network. So if 
tht matters to you, take that into consideration.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Spectrum Routing Contact

[Robert Blayzor]

I was wondering if someone from Spectrum engineering could hit me out of 
band. We have a customer in one of our data centers that is having some 
strange routing issues through Cogent and Spectrum AS's 7843 & 12271. 
Was wondering if someone could share some insight BGP looking glass type 
info with me so we can figure this out.


TIA

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Cogent Layer 2

[Robert Blayzor]

On 10/14/20 1:56 PM, Shawn L via NANOG wrote:
> When I last spoke to them, it sounded like they were using a bunch of
> LAG groups based on ip address because they _really_ wanted to know how
> many ip addresses we had and what kind of traffic we would be expecting
> (eyeball networks, big data transport, etc).


Not why IP addresses are even an issue on an a "Layer 2" service. But
then again, this is Cogent we're talking about here.

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: cloud automation BGP

[Robert Blayzor]

Back in the day there was Cyclops...

https://cyclops.netsec.colostate.edu/

Not sure it's still a thing, doesn't look like it's been updated in a while.


On 9/27/2020 11:52 AM, Dmitry Sherman wrote:

Hello guys,

Can you recommend software or cloud based solution which monitors if a 
prefix is advertised to a peer (via his Looking Glass for example) & if 
traffic is passing thru an interface and if one of them is false it 
announce this prefix via other upstream providers & remove blackholes?

Re: Centurylink having a bad morning?

[Robert Blayzor]

On 8/30/20 8:14 AM, Drew Weaver via NANOG wrote:
> Woke up this morning to a bunch of reports of issues with connectivity
> had to shut down some Level3/CTL connections to get it to return to normal.



Just to confirm we're seeing this on AS3356 and not AS209, correct?


We have links to both and shut down AS3356 which seems to have cleared
"most" of the problems.


-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Cogent sales reps who actually respond

[Robert Blayzor]

On 9/16/19 9:30 AM, Jon Sands wrote:
> The last time I dealt with them, it took a little over 3 months to get
> them to turn up basic BGP service. To top it off the sales rep was fired
> in the middle of our deployment. Cogent seems to have higher rep
> turnover than anything else I've dealt with. Buckle up and have fun!


They are truly ridiculous to deal with. Turning up a new 10G dual stack
link with BGP. At turn-up time they tell us we have to order BGP for
IPv6 separately. So you order a circuit with IPv4+IPv6 w/ BGP, but it
doesn't click to them you need it for both AF's? Assuming (wrong) that
maybe they can do both over AF's over the same session, NOPE!...

To top it off, they refuse to enable something as simple as TTL security
on your BGP peering session... but "Oh you can do MD5". Wait, what?

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Partial vs Full tables

[Robert Blayzor]

On 6/10/20 6:01 PM, Baldur Norddahl wrote:
> Am I correct in assuming loose mode RPF only drops packets from
> unannounced address space in the global routing table? And the downside
> of doing so is that sometimes we do receive packets from that address
> space, usually back scatter from traceroute or other ICMP messages.
> 
> Currently about 25% of the routable address space is not advertised in
> the DFZ. Loose mode RPF could filter this. Is there any data on how much
> traffic actually arrives from this space?
> 


Loose mode RPF will essentially drop traffic received on the interface
if the router does not have any route for. (will not match a default or
a discard route, at least in IOS-XR)

As Bill has pointed out, this may drop traffic from some peering
networks that are not in the global routing table. Though one could
argue that if a packet needs to be fragged it's typically closer to the
edges rather than the transit/peering links.

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Partial vs Full tables

[Robert Blayzor]

On 6/4/20 11:00 PM, James Breeden wrote:
> And before I get asked why not just run full tables, I'm looking at
> regional approaches to being able to use smaller, less powerful routers
> (or even layer3 switches) to run some areas of the network where we can
> benefit from summarization and full tables are really overkill. 


One caveat that may or may not play into this is if you use uRPF (loose)
on your transit links.

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: CGNAT Solutions

[Robert Blayzor]

On 4/29/20 10:29 AM, Mikael Abrahamsson wrote:
> There are some numbers in there for instance talking about 1024 ports
> per subscriber as a good number. In presentations I have seen over time,
> people typically talk about 512-4096 as being a good number for the bulk
> port allocation size.


So as a happy medium of about 2048 ports per subscriber, that's roughly
a 32:1 NAT/IP over-subscription ?

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: CGNAT Solutions

[Robert Blayzor]

On 4/28/20 11:01 PM, Brandon Martin wrote:
> Depending on how many IPs you need to reclaim and what your target
> IP:subscriber ratio is, you may be able to eliminate the need for a lot
> of logging by assigning a range of TCP/UDP ports to a single inside IP
> so that the TCP/UDP port number implies a specific subscriber.
> 
> You can't get rid of all the state tracking without also having the CPE
> know which ports to use (in which case you might as well use LW4o6 or
> MAP), but at least you can get it down to where you really only need to
> log (or block and dole out public IPs as needed) port-less protocols.


I'm wondering if there are any real world examples of this, namely in
the realm of subscriber to IP and range of ports required, etc.  ie: Is
is a range of 1000 ports enough for one residential subscriber? How
about SMB where no global IP is required.

One would think a 1000 ports would be enough, but if you have a dozen
devices at home all browsing and doing various things, and with IOT,
etc, maybe not?


-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Disney+ Geolocation issues

[Robert Blayzor]

On 11/13/19 9:49 AM, Matthew Huff wrote:
> It’s not about optimization, it’s about the contract with the content 
> providers. The agreement is to restrict content by geographical regions 
> mainly for marketing purposes. They block VPN access to keep people from 
> bypassing those restrictions. It’s true of all the streaming providers.


Build a better mousetrap, because it's clearly not working. We still get
tons of people calling into first level support asking why ESPN+ doesn't
work and that ESPN told them to call their ISP's, which can do NOTHING
to fix the problem.

Guessing Disney stole a page from that book...

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Disney+ Geolocation issues

[Robert Blayzor]

On 11/12/19 5:28 PM, Michael Crapse wrote:
> Myself and a few other ISPs are having our eyeballs complain about
> disney+ saying that they're on a VPN. Does anyone have any idea, or who
> to contact regarding this issue?
> This is most likely improper geolocation databases. Anyone have an idea
> who they use?
> 


Same boat here. ARIN ISP with all valid SWIP clearly showing stateside
USA. So who knows what Disney+ is doing to block their viewers. Seems
rather silly to block viewing based on the connecting IP address.
Wouldn't you base it on the authorized viewer who is logged in and using
the service? I mean, that's what they are paying for. I get the whole
CDN steering thing, but the error message message sent back to the
viewer should not be to "call your ISP". Now you have support desks
taking thousands of worthless calls

ESPN+ is guilty of the same garbage

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: BGP prefix filter list

[Robert Blayzor]

On 5/30/19 1:48 PM, William Herrin wrote:
> 1. What happens to the packets when the /24 gets filtered from one
> source (in favor of an aggregate) but not from the other? 
> 
> 2. In exchange for this liability, did you gain any capacity in your router?


It was my understanding that the argument for filtering at your own
edge, routes which you receive that has an aggregate covering route and
a /24 more specific prefix.

For a single multi-homed network with two transit ISP's it won't make
much of a difference unless you are strapped for outbound bandwidth.
Filter away, because you have a covering aggregate route.

I'm not saying this will work for ALL networks of any size, but for
organizations with just a couple of transit links and not much TE going
on, it would be a perfectly viable option rather than overloading your
TCAM due to budget constraints...

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: BGP prefix filter list

[Robert Blayzor]

On 5/30/19 12:54 PM, William Herrin wrote:
> It's permissible to announce to your transits with a private AS which
> they remove before passing the announcement to the wider Internet. As a
> result, the announcement from each provider will have that provider's
> origin AS when you see it even though it's actually from a downstream
> multihomed customer.


If you were a multi-homed customer the route would still originate from
two different AS's, both of your upstream ISP's. If it's the same ISP,
then that would not apply. But then again, if it were the same ISP they
could filter the more specific and learn downstream customer routes
either by IGP, filtering or tagging the /24 with no-export.


-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: BGP prefix filter list

[Robert Blayzor]

On 5/24/19 2:22 PM, William Herrin wrote:
> Get it? I announce the /24 via both so that you can reach me when there
> is a problem with one or the other. If you drop the /24, you break the
> Internet when my connection to CenturyLink is inoperable. Good job!


It would be dropped only if the origin-as was the same. Your AS and your
carriers aggregate announcement would be from two different origin AS.
At least that's the gist of it...

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: BGP prefix filter list

[Robert Blayzor]

On 5/15/19 2:52 PM, Mike Hammett wrote:
> You can't do uRPF if you're not taking full routes.
> 
> You also have a more limited set of information for analytics if you
> don't have full routes.


Or instead of uRPF (loose) on transit links, just take a BOGON feed?

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

NYC to Albany - Wavelength service

[Robert Blayzor]

Anyone know of any carriers offering DWDM wavelength paths between NYC and 
Albany, NY? (Not OTU2 or OTU4). Looking for carrier to carry color (alien 
wave). Please contact me off list.

Thanks

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://inoc.net/~rblayzor/

Re: Cogent BCP-38

[Robert Blayzor]

> On 29 August 2017 at 03:38, Robert Blayzor <rblayzor.b...@inoc.net> wrote:
> 
>> Well not completely useless. BCP will still drop BOGONs at the edge before 
>> they leak into your network.
> 
> Assuming you don't use them in your own infra. And cost of RPF is lot
> higher than cost of ACL. Them being entirely static entities they
> should be in your edgeACL. The only real justification for loose RPF
> is source based blackholing.
> 
> -- 
>  ++ytti


Well, if you are using public IP addresses for infra you are violating your 
RIR’s policy more than likely. And if you’re using RFC1918 space in your global 
routing table, then thats another fiasco you’ll have to deal with. Managing 
ACL’s for customer routes has far more overhead (and cost, ie: time, human 
error, etc) than to just use RPF on an edge port. I believe the OP was talking 
about multi-homed, in that case if run a tight ship in your network RPF loose 
is probably a good choice. It at least gives you an easy way to not accept 
total trash at the edge. 

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://inoc.net/~rblayzor/

Re: Cogent BCP-38

[Robert Blayzor]

> On Aug 17, 2017, at 9:11 AM, William Herrin  wrote:
> 
> Doesn't loose mode URPF allow packets from anything that exists in the
> routing table regardless of source? Seems just about worthless. You're
> allowing the site to spoof anything in the routing table which is NOT
> BCP38.


Well not completely useless. BCP will still drop BOGONs at the edge before they 
leak into your network.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://inoc.net/~rblayzor/

Re: BGP Route Reflector - Route Server, Router, etc

[Robert Blayzor]

On Jan 12, 2017, at 5:59 PM, James Bensley  wrote:
> 
> The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are
> deploying these in production and its increasing in popularity.


+1 here on the CSR1000v, works very well.

However, I’d have to give another +1 to XRv because RPL is more flexible and 
easier to manage than route-maps in IOS.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu

Re: Programmable SFP+ Transcievers

[Robert Blayzor via NANOG]

On Jan 18, 2016, at 2:02 PM, Colton Conor  wrote:
> 
> What options are out there for re-programmable SFP and SFP+ transceivers?
> So far I have found both
> https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html and
> http://solid-optics.com/tools/multi-fiber-tool/so-multi-fiber-tool-id1768.html
> Is there anything else out there? Any opinions on these two companies?
> 
> 
> I believe they both require you to use their SFPs in order to program them,
> but I could be wrong.


Another choice out there as well. I’ve not yet tried their SmartCoder, but have 
been using their transceivers for years. They have been great.

http://integraoptics.com/SmartCoder.html


--
Robert
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu

Re: Level3 routing issues

[Robert Blayzor via NANOG]

On Jul 28, 2015, at 8:54 PM, Matt Hoppes mhop...@indigowireless.com wrote:
 
 Is anyone seeing packet loss or routing issues on the Level3 network on the 
 east coast right now?
 
 


We’ve seen a slew of problems going west out of Level3 in NYC the last couple 
of nights. Last night was particularly bad to the point we had to shut our 
Level3 BGP sessions down to route around the issue. 

--
Robert
inoc.net!rblayzor
Jabber: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu

Re: Anycast provider for SMTP?

[Robert Blayzor via NANOG]

On Jun 15, 2015, at 1:50 PM, Joe Hamelin j...@nethead.com wrote:
 
 I have a mail system where there are two MX hosts, one in the US and one in
 Europe.  Both have a DNS MX record metric of 10 so a bastardized
 round-robin takes place.  This does not work so well when one site goes
 down.   My solution will be to place a load balancer in a hosting site
 (virtual, of course) and have it provide HA.  But what about HA for the
 LB?  At first glance anycasting would seem to be a great idea but there is
 a problem of broken sessions when routes change.
 
 Have any of you seen something like this work in the wild?


F5 GTM? Depending on what your DNS volume is you could probably get away with a 
couple of virtual appliances…

--
Robert
inoc.net!rblayzor
Jabber: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu

Re: Recommended 1Gb SFP for ~115km?

[Robert Blayzor]

On Aug 4, 2010, at 12:27 PM, Abello, Vinny wrote:
 Thanks for the input, Justin. I'm familiar with Transition Networks and have
 used their solutions in other scenarios (as well as MRV). I'm aware of the
 fiber characteristics being a major factor of the link budget and
 dispersion, etc. I am waiting on measurements from the company who is
 finishing the splicing of the fiber for us so I know what I have to work
 with.


If you're fine with 3rd party optics, FluxLight has BIDI SFP's that will reach 
up to 120km.

http://www.fluxlightinc.com/prod.php?id=309


They show up as Cisco SFP's right in the switch/router.  I've had good luck 
with the 40  80km ones in the past.

-- 
Robert Blayzor
INOC, LLC
rblay...@inoc.net
http://www.inoc.net/~rblayzor/

Re: IPv6 transits (Was: Cogent input)

[Robert Blayzor]

On Jun 14, 2009, at 6:04 PM, Jeroen Massar wrote:

For people trying to find the list, check:
http://www.sixxs.net/faq/connectivity/?faq=ipv6transit




Since when has Level3 offered native IPv6?  I nag our rep  SE's just  
about every month on when and right now AFAIK it's still just tunnels.


--
Robert Blayzor, BOFH
INOC, LLC
rblay...@inoc.net
http://www.inoc.net/~rblayzor/

Why word on fiber outages in NY?

[Robert Blayzor]

Anyone have the exact news or information of whats going on in NYC  
with a rather large fiber cut?  I keep hearing that there was some  
large Con-Ed electrical vault that caught fire and burned up a ton of  
CavTel and Level3 fiber.  I believe this happened sometime Sunday  
morning around 3:40 EDT.  At that time I saw some CavTel dark fiber go  
away and Level3 DIA circuits just drop off...


Level3 has been less than useful on giving updates rather than saying  
extensive fiber damage in the NY metro area, no ETA.  I've heard  
that the damage is so extensive it will be several days before anyone  
is allowed in to work on the fiber.


I've been trying to search news and information, but nothing.  I've  
heard this is huge outage for Level3 in the New York/Northeast area.   
Anyone have anything to share?


--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/

NYC - 60 Hudson Problems?

[Robert Blayzor]

On this cheerful Monday morning around 3:40 EDT I'm seeing a few  
different service outages from Albany into NYC to 60 Hudson.  Our  
Level3 internet connection has gone down (again) and still down as of  
this time, and also noticing some dark fiber facilities we have going  
into 60 Husdon also have LoS.  Anyone know whats up?  We have tickets  
in with Level3 another the other dark fiber provider, but it's been  
pretty quiet..


--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/

Re: [NANOG] Fiber Cut at 60 Hudson

[Robert Blayzor]

On May 27, 2008, at 2:47 PM, Bill McGonigle wrote:
I've also heard contradictory information from Level3 reps on some  
of the above, so I'm not asserting any accuracy for it; so just FYI.


Maybe they finally got to looking into your problem and unplugged  
the fiber labeled 'Vermont' by accident. ;)




That's about what we experienced.  After about 45 hours they finally  
managed to bring our service back up. :-/  Our problem is that when it  
did come back up (assuming on the protect side of the ring) our first  
hop latency to Level3 was through the roof, so we decided to keep our  
BGP peer shutdown until things completely cleared up.  Unfortunately  
for us I think there is a lot of legacy pre-Level3 network between  
us in Albany and 60 Hudson/111 8th in NYC... a lot of stuff that  
probably isn't well documented or maintained. (thus, the 40+ hour  
outage)


--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/

Re: peter lothberg's mother slashdotted

[Robert Blayzor]

Jeff Kell wrote:

If we continue along orders of magnitude, sure it's foreseeable.

* 30 years ago, 300 baud was the bomb :-)
*  3000 baud was roughly 2400bps days
* 3 baud gets us to ~28.8k
*30 baud was about 2 ISDN lines (2x128k)
*   300 baud is about typical cable these days (3m)



Well using your logic, then it's partially true that 40G is not any time 
soon.  Especially considering fiber is in less than 1% of homes.  Lets 
not forget that all of the above has been established on existing 
facilities that have been in homes for 30-50+ years.


You say 30 years ago, and lets roughly estimate it's four to five years 
between those technologies above, which gets us to today.  It's going to 
take at least another 5 years to consider FTTP the norm at say 30M, 
maybe sooner with technologies with DOCSIS 2.0, etc.  So...


30MIs Today +4/5 years
300M   Is Today +8/10 years
3G Is Today +12/15 years
30GIs Today +16/20 years

If it's sooner all the better.  Keeping in mind, installations like 
Verizon FiOS don't run dedicated strands of glass to each home, they use 
PON.  So achieving anywhere near 40G on even the existing stuff they're 
running into homes may not be possible for quite some time...


PS -- baud != bps

-Robert

Re: peter lothberg's mother slashdotted

[Robert Blayzor]

micky coughes wrote:
I can see that *everybody* is missing the point on Peter's exercise.  
Clearly this is to show to the telcos of the world that you can upgrade 
to a native IP infrastructure and absorb the existing transport into the 
router with a minimal effort.  There was a post here from someone that 
was there that explained how simple it was.   This is HUGE!  This has 
the potential to completely disrupt telco transport dinosaur groups 
*and* reshape the future.  Taking it to his mom's house is just a poke 
in the telco eye, he is making fun of them.  This then begs the question 
why can they do it between their facilities?  If one guy can do it to a 
*house* it must not be that hard.  However, telcos with transport groups 
of 1000s can't pull this off, this little project states volumes.



There may be some telco's out there that don't know these types of 
technologies are out there.  But for many, they are quiet aware.  The 
fact is 10G seems a lot more economically feasible right now.  Maybe if 
40G, OC768 WDM line cards didn't cost over a quarter million dollars 
each there would be more deployments of it.  The rate and cost of 
facility upgrades are far surpassing the means to make the ROI models work.


-Robert