Re: PBNAPs renumbering 6-Mar-02 (was: more info on SBC/Nap)
I assume the switch happened? In any case, there are no DNS servers listed for the in-addr records of these two blocks; is this by design? Adi On Thu, Feb 14, 2002 at 01:08:37PM -0500, renster wrote: Thanks Bill! Just one clarification - participants were told this would happen on 6-March. From the note sent out to participants on Monday: PBNAP-SF - 198.32.128.x will become: 206.223.120.x PBNAP-LA - 198.32.129.x will become: 206.223.121.x If you are a participant and didn't get a copy of the note with dial-in number for the maint. window drop me a line and I'll put you in touch with the folks at the NAP. Cheers, -ren At 06:21 PM 2/14/2002 +, [EMAIL PROTECTED] wrote: I've just been told that SBC/PacBell is in process of renumbering the PacBell exchanges in Oakland and LA. So you should not see either 198.32.128.0 or 198.32.129.0 in your traceroutes or from your peers as of 28 feb 2002. --bill
Re: genuity - any good?
On Fri, Apr 12, 2002 at 04:50:20PM -0700, Roy wrote: Registering is not bad, its just not beneficial. Given that the routes I want to announce are within my assigned range, why is it a good thing to register them? If the transit provider always add entries when I ask for them, it seems to be very little benefit.. have you asked them to add entries for prefixes that don't belong to you? Adi
Re: Selective DNS replies
On Wed, Apr 24, 2002 at 08:55:15PM +0100, Avleen Vig wrote: This subject has probably been talked to death, so I apologise in advance for bringing it up! Is there any DNS server currently availible that can reply to DNS lookups based on the source IP address? Yes, this would be for directing users to a 'local' server hosting www.example.org (or something similar). Yes, this is not the best way of doing it I know :-) Something more dynamic than Bind9 views? Adi
Re: Effective ways to deal with DDoS attacks?
In case no one has already posted it, you might check out the following document: http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf which talks about knobs for Cisco's RPF that will allow it to work with multihomed situations. There is also stuff in there about how to propogate a null route quickly for any _source_ prefix using IBGP (and no, an IGP like ISIS or OSPF won't work) and RPF. To back Jason up, Cisco's unicast RPF decides whether an interface is the best by doing a CEF lookup. Adi On Thu, May 02, 2002 at 10:16:55AM -0700, LeBlanc, Jason wrote: Thats how it we understood it to work (CEF lookup). It checks for a route in the table, obviously any real route would be in the CEF table. I may be wrong, but it doesn't actually send a packet to verify, the logical way to check would be by checking CEF, as anything the router knows about that is valid would be in CEF. If I'm misunderstanding, please do send more info. -Original Message- From: Mark Turpin [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 10:05 AM To: LeBlanc, Jason Cc: [EMAIL PROTECTED] Subject: Re: Effective ways to deal with DDoS attacks? On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this: snip There are some limitations as to where uRPF works, SONET only on GSRs for example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I think) regardless of interface type. Impact should be minimal, as it simply does a lookup in the CEF table, if the route isn't there it discards. Keep in mind this is NOT a filter, so the impact is much less, it is simply a CEF lookup, much more efficient than a filter. This will get rid of a HUGE percentage of spoofed packets that hit your network, and would also work pretty well if you are the source of an attack. There is some debate as to whether you must not have ANY RFC1918 space for this to work. We're trying to find this out (not a priority), if I get info I'll post. hmm... either you're being extremely vague, or you misunderstand how RPF works. http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secu r_c/scprt5/scdrpf.htm Its not checking cef to see if a route is there its making sure that a packet received on an interface came in on an interface that is the best return path to reach that packet. thereby explaining why multihomed customers will get borked in the event of using rpf. enjoy, -mark -- Support your local medical examiner--die strangely.
Re: Bogon list
On Tue, Jun 04, 2002 at 04:47:51PM -0400, Leo Bicknell wrote: In a message written on Tue, Jun 04, 2002 at 03:47:00PM -0400, Richard A Steenbergen wrote: Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers. I would say this the other way around, all exchange point blocks should be transited by someone. Back in the day, things like the mae-east FDDI were originated by a half dozen AS's. Why? If you had full routes, but didn't connect to the mae, you could traceroute but not ping it, and things of that nature. It confused people. Of course, the inconsistent announcements were also an issue. Am I right that I don't see a reason why IX blocks should be transited other than traceroute should work? I can think of a couple of reasons why the blocks SHOULDN'T be transitted by anyone. Adi
Re: CA Power
On Wed, Jul 10, 2002 at 06:19:39PM -0400, Richard A Steenbergen wrote: Hrm looks like I beat Sean Donelan... http://www.caiso.com/awe/systemstatus.html http://www.caiso.com/outlook.html Is it time for a rolling blackout again? Cal-ISO issues a Stage 2 emergency. Next targeted blackout block(s): 1.
Re: VoIP QOS best practices
On Mon, 10 Feb 2003 10:27:39 -0800 (PST), Bill Woodcock [EMAIL PROTECTED] said: Look, just do it, and you'll see that there aren't any problems in this area. For those looking to just do it, it's not very complicated or expensive to try -- and the quality is very, very good esp. if you have broadband. For an easy, step-by-step way to try it out over the public, non-QoS Internet, look at the steps at: http://www.pulver.com/fwd (yes, there are other free, public SIP servers, but I haven't found any with as much useful documentation and I'm not associated with pulver.com except for being an enthusiastic FWD user) FWIW, I purchased a Cisco ATA-186 and then a 7960 on eBay (after trying out MS Messenger and finding it lacking) and they just work. I also have used the same units to get a PSTN phone number routed over IP using www.iconnecthere.com -- and you can make it work behind NAT too (but I can assure you it's easier without NAT). I'm willing to play tech support via email if anyone has questions about getting started. Adi
Re: Automate router configs
On Thu, 11 Mar 2004 20:50:57 -0600, Jason Graun [EMAIL PROTECTED] said: Is anybody automating router/switch configs in any manner other then telnet scripts or Ciscoworks? I am just trying to get some ideas. are you talking about access routers or backbone/core/peering routers? - for core/backbone routers, use rancid (www.shrubbery.net) whatever your automation scheme, it might not be your primary tool, but it will save you one day Something that doesn't get mentioned on NANOG very much is automating/managing lots and lots of access customers -- ie DSL/T1/Frame etc.. If that interests you, then maybe something I used circa 1999 but I haven't really heard being used recently (but probably is) might give you some ideas (an interview question yesterday reminded me): - we had a Redback SMS 1000 that we could preconfigure ATM PVCs/Frame DLCIs/DS3 Channels for T1s on with all the Layer 2 stuff - all the Layer 3 stuff like routed networks, interface IP addresses, IP filters etc. could be assigned out of radius. I believe Redback had plans to introduce a cable blade for their SMS boxes - we took DSL/T1 orders entered into a web front end and had IP/PVC etc. configs stored in an SQL database and updated radius within a few minutes (Covad had (has?) a very nice XML-RPC backend that let us assign the PVCs to our customers etc.. MCI/Worldcom also allowed us to assign channels on a DS3, so our software did that and sent them email with the order) - the Redback had an excellent feature by which, upon receipt of a packet on a hitherto unbound PVC (a few weeks after we were setup the DSL/Frame layer-2 circuit would be installed), it would read the config from radius and bind the PVC - when a customer cancelled or didn't pay their bill, a script, triggered by certain fields that support/billing-folks could set in the web-frontend, would log into the Redback and unbind the circuit Since most frequent updates and config changes happened to access routers, this minimized the amount of mundane work a router-monkey had to do. I only hope that all ISPs selling such services are doing things in a nice, automated way. FWIW, my ISP was swallowed by a cable provider who was well subsidized by Cisco. And the rest, you can probably guess. amazed by how little has changed in the ISP world since 2000, Adi
Re: TCP/BGP vulnerability - easier than you think
On Wed, 21 Apr 2004 07:35:27 -0700, Michel Py [EMAIL PROTECTED] said: Insist that the peer uses ip verify unicast reverse-path on all interfaces, or similar command for other vendors. I sure hope there are no asymmetric paths on the Internet that will bite you when you turn on strict RPF on your peering interfaces /sarcasm Seriously, if you do turn RPF on on peering interfaces, please let your peers know (plea from circa 1999) Aditya
Re: Persistent DNS Zone Transfer Attempts from IP 128.232.0.31
On Sat, 26 Jun 2004 11:19:16 -0400, Jon R. Kibler [EMAIL PROTECTED] said: Greetings, Anyone know anything about IP 128.232.0.31? # host 128.232.0.31 31.0.232.128.in-addr.arpa domain name pointer dns-probe.srg.cl.cam.ac.uk. [...] Anyone know anything about this IP? Keep going, they make it pretty easy to figure out what is going on: dig txt dns-probe.srg.cl.cam.ac.uk ; DiG 8.3 txt dns-probe.srg.cl.cam.ac.uk ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; dns-probe.srg.cl.cam.ac.uk, type = TXT, class = IN ;; ANSWER SECTION: dns-probe.srg.cl.cam.ac.uk. 6H IN TXT pseudo IP address for machine doing research into DNS data dns-probe.srg.cl.cam.ac.uk. 6H IN TXT See http://www.cl.cam.ac.uk/Research/SRG/netos/adam/traffic.html for details ;; Total query time: 1134 msec ;; FROM: mighty.grot.org to SERVER: default -- 127.0.0.1 ;; WHEN: Mon Jun 28 13:42:19 2004 ;; MSG SIZE sent: 44 rcvd: 204
Re: CAT5 surge/lightning strike protection recommendations?
On Tue, 13 Sep 2005 20:24:51 +, R.P. Aditya [EMAIL PROTECTED] said: I have a bunch of cat5 buried about 1 ft below the surface connecting multiple buildings on a campus (short runs) and lightning strikes nearby have caused surges along one or more of the cables and burnt out switch ports. I would like to protect the switch ports -- there seem to be lots of products on the market. Anyone have recommendations (tested/practical is best :-)? The APC Protectnet PNET1 and PRM24 seem quite nice and not too expensive -- if they workpros? cons? Thanks to everyone who replied on- and off-list. The installation in question is in a condo development and was done by licensed electricians and the residents were lead to believe that it was code compliant. The cat5 cabling is double-sheathed with a moisture barrier. As you can well imagine, the residents are very cost-concious. My preference is that fiber be run in conduits, however even running cat5 in grounded conduit is a big hassle as it will involve cutting across pavement etc. (I fully appreciate the danger from potential difference between buildings and copper being a good conducter etc., but I had to ask a leading question in order to document the problem such that sufficient notice would be paid by the residents -- I believe I have that now). The short-term solution seems to be using the APC PNET1s/Tripplite DNET1/etc. in each unit and tying them to the water main as an inexpensive, immediate step while funds are allocated for conduit, labor etc.. Thanks, Adi
CAT5 surge/lightning strike protection recommendations?
I have a bunch of cat5 buried about 1 ft below the surface connecting multiple buildings on a campus (short runs) and lightning strikes nearby have caused surges along one or more of the cables and burnt out switch ports. I would like to protect the switch ports -- there seem to be lots of products on the market. Anyone have recommendations (tested/practical is best :-)? The APC Protectnet PNET1 and PRM24 seem quite nice and not too expensive -- if they workpros? cons? Thanks, Adi
