- Test - lists.nanog.org

Cisco mulls buying Nokia?
by Fergie (Paul Ferguson) 07 Aug '05

07 Aug '05

I had to check the date to make sure it wasn't really April 1st.... A Reuters newswire article, via Yahoo! News, reports that: [snip] Cisco Systems Inc. is considering buying the world's top mobile handset maker Nokia in a bid to gain its wireless infrastructure technology, the Business newspaper reported on Sunday. The paper, which did not reveal the source of its information, said U.S.-based Cisco had traditionally concentrated on acquisitions of niche technology players, but its Chief Executive John Chambers is believed to be interested in merging with a wireless infrastructure company. "Nokia has been identified as the most likely target," the paper said. Cisco, the largest maker of Internet equipment, is worth around $123 billion, while Nokia's market value is around $71 billion. The paper said Cisco's mainstay networking market was fast changing with the convergence of fixed-line and wireless networks, and Cisco needed a merger to acquire the technology to create intelligent wireless applications, which Finnish-based Nokia could provide. Cisco was not immediately available for comment. A Nokia spokeswoman in Helsinki declined to comment. [snip] http://news.yahoo.com/s/nm/20050807/bs_nm/telecoms_cisco_nokia_dc - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

RE: DACS Equipment
by Hannigan, Martin 07 Aug '05

07 Aug '05

> > > I have a number of mux DS-3s coming in - right now they drop straight > into aggregation routers. What I like to do is drop them into > a local DACS > and comb them out to DS-1s and then re-mux them back on to > internal DS-3s. > This will let me move circuits around digitally inside our equipment. You're looking for digital cross connect, for the most part. You should take a look at the Cisco line i.e. 15454 et. al. You can bring in ds3, groom on the backplane, and send out ds3. I've used the 15454 et. al. in production and for your stated purpose it's more economical than buying some big iron. You may also want to consider your physical layer architecture if you do this i.e. interconnecting vs. cross connecting so that you have test access where you need it. IIRC, the 15454 et. al. will do passive monitoring at a line level and will SNMP alert on outages down to the smallest mux' unit. Very nice for the IP NOC. -M<

1 0

RE: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
by Hannigan, Martin 07 Aug '05

07 Aug '05

> I think the EFF is missing the important part of the wish > list items. The punch list is law. If you are talking about the applicability of CALEA, that's different. > The > wish list items aren't for wiretaps, but defining as many things as > possible as "non-content." Its important for network > operators because > they will end up doing a lot more work digging through packets for > non-content information, and important for lawyers because it > lessens the > legal requirements for non-content information. What is the > "expectation > of privacy" of non-content information? ObNANOG: Archicture, operation, cost. CALEA doesn't dictate architecture. Political issues aside, and attempting to stick with operations as this is NANOG, the major issue for carriers regardless of size is that this that compliance is an expense. The cost of an implementation for a medium sized carrier is upwards of 1MM. Maintenance runs at ~200K per year for a similiar installation not coupling in legal and operations costs. That is IF you even get an order. The brunt of the work is at the tier1's. This is like DDOS. LEC's have to do it, but they frequently misinterpret the requirements and scale and end up spending money they never had to. Misinterpretation is a big problem for CALEA, technically speaking. -M<

2 1

RE: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
by Hannigan, Martin 07 Aug '05

07 Aug '05

> > > > On Sat, 6 Aug 2005, Matt Ghali wrote: > > > > > On Sat, 6 Aug 2005, Joshua Brady wrote: > > > > the FBI can call the NSA anytime they want without a tap order and > > get them to trigger ECHELON when your voice is apparant on any > > line. > > > > > > Not me, I wrapped my cellphone in tin foil. > > shiny side out one hopes? Seriously though, I'm not a > telco/phone person, > but I was once told that the phone switch equipment does the tap > 'automagically' to special ds-1 facilities inn LEA-land... > which means the > cell phone can be wrapped in anything you'd like. If the calls get > completed a copy is silently made to the right folks (not the > nsa, they > aren't LEA). Sort of. It has to be provisioned like any other service, (that's most of the X.25 portion that people were talking about) but it's a protocol(J-STD) enabled between the carrier and the LEA. It can be DS1, or it could be VPN. The capture is near real time content and data. -M<

1 0

Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
by sthaug＠nethelp.no 07 Aug '05

07 Aug '05

> > I'm sorry, but this is simply an unsupportable statement. What is > > required of routers is that the provider be able to configure the device > > to make copies of certain packets to a monitoring port. Assuming that > > the monitoring port is duly managed, how does this qualify as "insecure"? > > It qualifies as "insecure" because if that rather dubious assumption fails to > be true, you have a big problem. Then you'll have to conclude that a lot of managed switches are insecure since they include some form of packet mirroring capability. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
by sthaug＠nethelp.no 07 Aug '05

07 Aug '05

> but every feature has its cost in complexity and resources to build > and maintain. resources are finite and complexity has super-linear > cost. so i would much prefer that the vendors concentrate on the > features *i* want <g>. and i am quite skeptical of features which > non-paying non-customers want. Agreed. However, in this case it matches a fature I've wanted for years. Being able to mirror packets to a different port is pretty common for managed switches, and is rather useful sometimes in tracking abuse and similar. I *want* the same capability for my routers. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design fo r In ternet Services
by Fergie (Paul Ferguson) 07 Aug '05

07 Aug '05

I realize that CALEA is primarily geared towards traditional wiretapping (esp. pen register), but given the machinations of other organaizations (which have also mobilzed law enforcement) such as the MPAA and the RIAA, one might also surmise that this also seems to be desired for not just VoIP services.... - ferg -- sjk <sjk(a)dredel.com> wrote: We all pay the bill with higher equipment costs, the maintenance of configurations, and possible storage costs. CALEA was bound to include VoIP services - given the definition telecom carrier in the act; however, as I recall -- and I may be wrong -- when CALEA was first passed the carriers were given tax breaks and subsidies to implement changes. Is such financial help being offered today? --sjk -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Why some of us are IPv6 holdouts (Was: /8 end user assignment?)
by Michael Loftis 06 Aug '05

06 Aug '05

--On August 5, 2005 11:13:13 AM +0200 Iljitsch van Beijnum <iljitsch(a)muada.com> wrote: > Is there any particular reason why a service over IPv6 couldn't be load > balanced by putting a good number of AAAA records in the DNS? Since most > IPv6-capable browsers have decent support for trying multiple addresses, > the problem of having a server be unavailable but still be in the DNS > wouldn't be as bad as in IPv4. Two things. First it would be just as bad. The problem isn't whether-or-not browsers try multiple addresses, teh problem is load is not distributed in a predictable manner. The other part of the problem is that it takes many many seconds for a browser to figure out that a server is down. Finally I personally don't want to expose all of my back end web servers to every joe schmoe. Yes our customers if they were inventive enough could figure it out (or just ask if they had a reason to need to know them) but I worry less about them. Security through obscurity? Not really...View it as limiting your exposure. It's like putting a locked door behind a gate, at the back of a building, instead of the front. If you've got the key to use it (port 80 HTTP request) it'll work, but it's easier to just use the open front door. Plus noones liable to lock the front door up from the inside on you ;) > Obviously when people running these services refuse to consider IPv6 > because they can't load balance doesn't provide much incentive to load > balance vendors to upgrade their stuff. I'd guess rather the opposite if these same people are mentioning this to their VARs and the equipment manufacturers. Mostly I use LVS based stuff for load balancing which means I'm more or less IPv6 ready. The problem is it's another set of firewall rules and address space I have to maintain, document, account for, filter (for bad guys, or abusers), etc. There's a huge knock-on-effect on all manner of things that you might not expect to need to think about IPv6 offhand. Like log processors. I don't know about you but I don't have humans or chimps reading my logs for suspicious activity and producing summary reports of traffic, I've got automated processes. I'm not willing to wager that every one of those programs is ready yet. As for the 'map inbound ipv6 to ipv4' argument...ok...but depending on the setup, you'll lose a lot of your accounting and tracking features on the end hosts because everything will appear to come from the mapped address. Depending, obviously, on how you're implementing your load balancing. I'm just speaking for the few cases that I've deployed in this manner, not for anyone else, that doesn't mean what I'm saying doesn't apply for anyone else (it probably does). All of that will require some set of workarounds to make sure you know where traffic came from/was going to. Maybe I'm more concerned about what (potentially bad) things happen on my networks. Maybe not. Either way, that issue alone means a LOT of other software than the web server, load balancer, and routers need to understand (or speak) IPv6. There's a huge ecosystem of software here. A lot of it hasn't been written in such a way that it takes into account any other addressing/networking scheme than IPv4.

2 2

Fiber cut in SJ
by George William Herbert 06 Aug '05

06 Aug '05

So... is mail not getting in/out from Nanog right now, or is the fairly major fiber cut in San Jose not newsworthy on the operational list anymore....? -george william herbert gherbert(a)retro.com / gherbert(a)taos.com / gherbert(a)webex.com

2 1

Re: Fiber cut in SJ
by William Petrisko 06 Aug '05

06 Aug '05

> ----- Forwarded message from George William Herbert <gherbert(a)retro.com> ----- > > So... is mail not getting in/out from Nanog right now, > or is the fairly major fiber cut in San Jose not newsworthy > on the operational list anymore....? Should be :) L3 fiber cut in SJC/Sunnyvale area, 552 pairs, ETR 4:45 GMT. bill

1 0