- Test - lists.nanog.org

192.169.0.0
by Randy Bush 05 Jun '05

05 Jun '05

route-views.oregon-ix.net>sh ip bg 192.169.0.0 BGP routing table entry for 192.169.0.0/16, version 51241382 Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer) Not advertised to any peer 14608 4323 209.161.175.4 from 209.161.175.4 (209.161.175.4) Origin IGP, localpref 100, valid, external, best Community: no-export 'cept they don't own it

5 11

Re: Battery Maint in LEC equipment
by Frank Coluccio 05 Jun '05

05 Jun '05

>>wasn't refering to their POPs. I was refering to the customer location. For about a year I've been in discussions with a private cable operator (PCO) who has been knocking himself out trying to optimize an approach that would enable him to provide generator backups in apartment buildings. He wants to match the incumbent's triple play offerings, and in particular, he saw the need to provide uninterrupted voice service during commercial power outages not only as an amenity that was needed to compete with the telco, but in order to qualify for lifeline service status, as well. The net effect of seeing what is happening in the FTTP space has given him license now to begin considering options based on the use of batteries, as well. Lifeline qualification and delivering non-stop service availability are two separate, yet related, areas of consideration from a regulatory persepective. I suppose its left to interpretation, but I'm wondering if the ILECs, by their use of a battery-replacement policy may be breaking the models of both. Frank A. Coluccio DTI Consulting Inc. 212-857-8150 Office 347-526-6788 Mobile On Sat Jun 4 23:56 , Sean Donelan sent: > >On Sun, 5 Jun 2005, W.D.McKinney wrote: >> >If you wanted to pay for it, some of the CLECs would add batteries. But >> >it wasn't part of the base package. >> >> All the AT&T pops usually have nice battery and gen sets. That's what I like. > >I wasn't refering to their POPs. I was refering to the customer location. > >I've been wondering when the building codes will be updated. Currently >the building codes require backup generators for elevators in high-rise >buildings, but not for the telecommunications room in high-rise building >(other than the fire alarm). Instead of pulling individual copper pairs >from a POP to the high-rise building, a CLEC may install a fiber mux in >the basement and break-down individual circuits locally to copper. When >the building looses power, so does the fiber mux. > >Of course, adding batteries to the fiber mux doesn't solve the problem of >PBXs or even modern pay telephones in office buildings not working when >power fails. > >Who replaces the battery in your cell phone when it expires? How about >the battery in your cordless phone? Or the battery in your smoke alarm? > >If you don't want to do it yourself, for a fee you can hire someone else >to do it for you. But then people would complain about the fee, and how >they could do it themselves for less.

1 0

Slight OT: NASA World Wind project looking for support from network operators.
by Matt Mills 05 Jun '05

05 Jun '05

http://worldwind.arc.nasa.gov World Wind lets you zoom from satellite altitude into any place on Earth. Leveraging Landsat satellite imagery and Shuttle Radar Topography Mission data, World Wind lets you experience Earth terrain in visually rich 3D, just as if you were really there. Virtually visit any place in the world. Look across the Andes, into the Grand Canyon, over the Alps, or along the African Sahara. A few example images: http://www.worldwindcentral.com/wiki/Image:Bluemarble.jpg http://www.worldwindcentral.com/wiki/Image:Srtm.jpg Or you can check some hotspots: http://www.worldwindcentral.com/hotspots/index.php?cat=top The reason I'm posting to this list, is that the project is currently in a bit of a bind. World wind is becoming so popular, that the small community of developers and regular users can no longer afford to sustain the ammount of bandwidth neccessary to deliver all of the satellite data to the client. We're also having bandwidth issues in being able to actually distribute the client software, due to the fact that it is around 188 MB. It is currently the 6th most popular project on sourceforge.net with almost a million downloads in the last 2 months alone. Nasa can no longer host the installation program on their network do to the immense bandwidth usage it creates. What I am asking for is sponsors that are willing to host pieces of the datasets on their network. 1. We currently do not have enough capacity to put all the data we have online and keep it there. 2. We'd also like to setup geographically diverse nodes to enable redunancy and lessen latency. If you are willing to help this project at all, please contact me. Just as a note, a full copy one of the datasets is around 120 Gigabytes (Although we're currently looking into placing partial datasets), and the only community run server tops out (currently) right now at around 15 megabits per second. NASA is also running a web cluster to serve satellite data that is using around 50-75 mbps. Thanks in advance for your support, Matt Mills, the World Wind Developers, and the WorldWindcentral.com Staff.

1 0

Re: Battery Maint in LEC equipment
by Frank Coluccio 05 Jun '05

05 Jun '05

See UTOPIA's Standby Power RFB <sic>: Invitation to submit sealed bids for stationary and transportable generators RFB 2005GEN-004 June 2, 2005 http://www.utopianet.org/contracts/RFPs/pdfs/RFB_2005GEN-004.pdf --- Frank A. Coluccio DTI Consulting Inc. 212-857-8150 Office 347-526-6788 Mobile On Sat Jun 4 23:02 , Sean Donelan sent: > >On Sat, 4 Jun 2005, David Lesher wrote: >> Have any NANOG'ers [NANOGites? NANOGees?] run into this? Again, this >> is LEC owned, LEC maintained, equipment....Do you provide generator >> power for such in your space? > >Generally, the ILECs were the only ones that did this. I've had multiple >CLECs (Brooks, MFS, WilTel, etc) install fibermux cabinets, none of them >provided any backup batteries by default. They used local building power, >and we had to make sure they were connected to our backup generator. > >If you wanted to pay for it, some of the CLECs would add batteries. But >it wasn't part of the base package.

1 0

Battery Maint in LEC equipment
by David Lesher 05 Jun '05

05 Jun '05

Background: Verizontal is pushing their FIOS PON offering to residences. It will put IP access, 'cable' TV and POTS phone on glass. They then cut down your copper drop. But midst the VoIP E911 dustup, the issue of backup power has arisen. The FIOS box needs local power, and a small gel-cell good for say 5 hours. The *subscriber* must buy and install new ones as needed. Some pholks are dubious how well that will work... Foreground: There's one report that Verizontal, in ex-NuNuts territory, is also not maintaining batteries in their on-premises DS-3 -> n DS-1's mux's. Only if you get a full DS-3 will they bother. Question: Have any NANOG'ers [NANOGites? NANOGees?] run into this? Again, this is LEC owned, LEC maintained, equipment....Do you provide generator power for such in your space? -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

4 3

OT: NOC Display's
by Spencer Wood 04 Jun '05

04 Jun '05

This is kind of off topic, so please feel free to delete if you want <grin>.. Anyway, in our NOC we current have two LCD projectors displaying outputs from two different computers. On one of the display's, I would like to be able to take 4 VGA outputs from 4 workstations, and display it on the screen (aka: Hollywood square style). Does anyone have any recommendations for an inexpensive device that will take care of this? I have found some nice devices in the 10k price range, which needless to say is a little outside the budget. Security companies sell these devices for Video for around $500, so I'm figure someone should have a VGA version of the device. Thanks! Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.644.5422/Fax: 614.887.4021/Cell: 614.774.3123 *************************************************************

8 7

OT: Israeli industrial espionage Trojan horse snort sigs
by Gadi Evron 04 Jun '05

04 Jun '05

I spent a bit of time thinking about this, and decided this is not off topic due to high interest and worry from list subscribers. Although I am looking wearily at Randy Bush, so I decided to mark it as OT: and max not send such things next time, although this is a rather rare case (publicly anyway). Matt Jonkman over at Bleeding-Snort wrote and released snort signatures, in cooperation with Joe Stewart at lurhq and myself at IL-CERT. I am sure many organizations would be interested in those. Let's hope non of you ever get to see these triggered. http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/Stable/VIRUS/TROJAN_Hotwor… alert tcp $EXTERNAL_NET any -> $HOME_NET 2any(msg:"BLEEDING-EDGE VIRUS Hotword Trojan in Transit"; content:"|63 6f 6d 66 69 64 65 6e 74 69 61 6c 20 64 6f 63 75 6d 65 6e 74 20 28 57 6f 72 64 29 20 66 72 6f 6d 20 44 69 67 69 44 6f 63 00 43 4d 20 25 73 20|"; flow:established,from_server; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001959; rev:1;) alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BLEEDING-EDGE VIRUS Hotword Trojan inbound via http"; content:"|63 6f 6d 66 69 64 65 6e 74 69 61 6c 20 64 6f 63 75 6d 65 6e 74 20 28 57 6f 72 64 29 20 66 72 6f 6d 20 44 69 67 69 44 6f 63 00 43 4d 20 25 73 20|"; flow:established,from_server; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001960; rev:1;) alert tcp any any -> $EXTERNAL_NET 21 (msg:"BLEEDING-EDGE VIRUS Hotword Trojan -- Possible File Upload CHJO"; content:"STOR __"; content:"-CHJO.DRV"; within:100; nocase; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001961; rev:1;) alert tcp any any -> $EXTERNAL_NET 21 (msg:"BLEEDING-EDGE VIRUS Hotword Trojan -- Possible File Upload CFXP"; content:"STOR __"; content:"-CFXP.DRV"; within:100; nocase; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001962; rev:1;) alert tcp any any -> $EXTERNAL_NET 21 (msg:"BLEEDING-EDGE VIRUS Hotword Trojan -- Possible FTP File Request pspv.exe"; content:"SIZE pspv.exe"; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001963; rev:1;) alert tcp any any -> $EXTERNAL_NET 21 (msg:"BLEEDING-EDGE VIRUS Hotword Trojan -- Possible FTP File Request .tea"; content:"LIST "; content:".tea"; nnocase; within:50; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001964; rev:1;) alert tcp any any -> $EXTERNAL_NET 21 (msg:"BLEEDING-EDGE VIRUS Hotword Trojan -- Possible FTP File Status Upload ___"; content:"|53 54 4f 52 20 5f 5f 5f 0d 0a|"; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001965; rev:1;) alert tcp any any -> $EXTERNAL_NET 21 (msg:"BLEEDING-EDGE VIRUS Hotword Trojan -- Possible FTP File Status Check ___"; content:"|53 49 5a 45 20 5f 5f 5f 0d 0a|"; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.hotwo…; reference:url,securityresponse.symantec.com/avcenter/venc/data/trojan.rona.…; sid:2001966; rev:1;) Gadi Evron.

1 0

Re: URPF on small BGP-enabled customers?
by christian.macnevin＠uk.bnpparibas.com 03 Jun '05

03 Jun '05

I guess it's been a while since I've played with it, but isn't this pretty well what happens with uRPF anyhow? The asymmetric routing problem is illustrated ascii stylee below. AS1 / ASYOU - AS-OTHERGUY \ / CUSTOMER Say somebody in AS1 wants traffic from your customer. The request comes in through you, and to your customer. For whatever reason (internet exchange peering is more attractive to the customer, whatever - the point is, ignore the AS-path, because the customer has fiddled with their traffic - ie: always follow the money) their return traffic is going via AS-OTHERGUY. Their shortest path to AS1 is through you, so they throw the return traffic your way. Of course, your routing table resolves the best path for all customer routes to AS-CUSTOMER, so it drops all traffic coming in from AS-OTHERGUY. I don't think your solution would fix that, as AS-OTHERGUY's announcements would have a longer AS-path than your direct peering with the customer. (I reserve the right to be totally wrong and have completely misunderstood all mechanisms involved, btw ;) ) Internet nanog-list(a)nrg4u.com - 03/06/2005 14:58 To: Christian MACNEVIN cc: christopher.morrow, will, nanog Subject: Re: URPF on small BGP-enabled customers? christian.macnevin(a)uk.bnpparibas.com wrote: > At an old transit provider I was at, we had a pig of a time dealing with > uRPF. It doesn't like asymmetric routing at all, which is commonplace when > you've got customers homed at exchange points for one. This is why I say there should be a feature that will work like a dynamic ACL but is fed from BGP. All the prefixes you learn from customer A via BGP are put into an automatic ACL, default is deny. Then you apply this dynamic ACL to the interface the customer is connected to. Of course it still doesn't work if you send traffic from prefixes you don't announce but for 70-80% of the cases it's a big step forward in automation. This also gets rid of any differences between ACL on the forwarding plane and on the routing protocol plane. All prefix filters are defined in BGP configuration. Forwarding layer follows and never gets out of sync again. Random example syntax: router bgp 65500 neighbor 192.168.2.2 remote-as 65501 neighbor 192.168.2.2 dynamic ACL 10001 receive #put received prefixes here neighbor 192.168.2.2 prefix-list CUST65501 ... #usual stuff #only this one is controlled ip prefix-list extended CUST65501 permit ip 172.16.0.0/16 any permit ip 10.0.0.0/8 any #ACL on interface follows BGP received prefixes interface f0/0/0 ip access-group 10001 in #same as in BGP neighbor config And Voila! Problem automagically solved. -- Andre This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ********************************************************************************************** BNP Paribas Private Bank London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority.

5 4

URPF on small BGP-enabled customers?
by will＠loopfree.net 03 Jun '05

03 Jun '05

I am in the process of turning up a new transit connection with SprintLink. My network is a multi-homed stub AS and I only announce 5 prefixes. Having the bright idea to incrementally move some traffic onto the new line I didn't announce all 5 immediately and I localpref'd ^1239$ to get some outbound traffic moving -- and the result is of course that they drop any of my outbound traffic sourced from prefixes I'm not announcing yet. This really smells like URPF but of course nobody at Sprint has even confirmed that they are actually dropping packets. This is new to me, but I haven't bought any new transit in the past 18 months -- is this common practice on multihomed BGP customers now? I could force things to work by always advertising all my prefixes out to them with the obvious downside of living in fear of my outbound traffic being dropped if I ever need to withdraw any of them. If they're paranoid enough to manually filter my BGP announcements it's not much more work to manually filter my source addresses too (nevermind the fact that I already do it myself, but...) I'm working through the SprintLink noc/support process but I'm surprised this hasn't happened to any of their other customers before now. Am I missing something obvious here? -- -Will :: AD6XL Orton :: http://www.loopfree.net/

5 4

OT: ISP recommendations in Ontario
by Bill Thompson 03 Jun '05

03 Jun '05

I'm looking for recommendations on an ISP with a clue in Ontario, Canada. We need a static IP DSL or T1 in Concord. Please reply off-list. Thanks, -- Bill Thompson BillT(a)Mahagonny.com

1 0