- NANOG - lists.nanog.org

Re: Upcoming change to SOA values in .com and .net zones
by Maarten Van Horenbeeck 08 Jan '04

08 Jan '04

Hi Frank, Thanks for your reply. > Yes, but we all know there are quite some non-compliant dns-servers out > there. Do they want to break the largest zone for a few days for all > non-compliant servers? The serial should not be of any importance except to the .com & .net slave nameservers. To my knowledge, these are all managed by Verisign, so this should just be a purely internal operation. I really don't see the problems here most of you are referring to. > Oh, wait, right, they don't care if they break stuff... I believe they have a pretty good business case for keeping it in a working state. Best regards, Maarten -- Maarten Van Horenbeeck maarten(a)daemon.be

1 0

RE: GSR, 7600, Juniper M?, oh my!
by Michel Py 07 Jan '04

07 Jan '04

>> Dan Armstrong wrote: >> GSRs are useless if you are doing any kind of >> aggregation. Their traffic shaping abilities >> are embarrassing. > Neil J. McRae > Historically yes, but no longer. The latest line of > GSR cards now give them much greater capability in > this area even though it was never designed as an > access box. There still is the issue of cost though. GSR line cards are not cheap. >> 7500 is the classic aggregator. They do the job >> quite well, actually. Based on cost right now, I >> would take 10 7500s over 1 7600 anyday. > If you are just aggregating E1/T1 then I'd agree, > but the minute you need DS-3/E3/STM-1/ATM/100BaseT/ > Gige aggregation then the 7600 is a far better > choice cost wise I would put 10mbps Ethernet and possibly DS3 in the same pool as E1/T1 though; this still remains in the realm of things a 7500 does fine. I'm not trying to defend the 7500 platform, it's obsolete all right. However, free is music to my ears. Michel.

5 4

RE: Anyone alive at ep.net
by Malayter, Christopher 07 Jan '04

07 Jan '04

For the record, that is simply NOT true: > From: hostmaster(a)ep.net > Date: December 30, 2003 11:30:57 AM CST > To: address-request(a)ep.net > Cc: mustang(a)fdfnet.net > Subject: nota.dal.net REGISTRATION TYPE (N)ew (M)odify (D)elete..:N > Site for connection........: NOTA > It was requested in 12/30/2003. Well past the 96 hour window. -Chris -----Original Message----- From: bill [mailto:bmanning@karoshi.com] Sent: Wednesday, January 07, 2004 3:17 PM To: Christopher.Malayter(a)tdstelecom.com Cc: bmanning(a)karoshi.com; Christopher.Malayter(a)tdstelecom.com; nanog(a)merit.edu Subject: Re: Anyone alive at ep.net > -----Original Message----- > From: bill [mailto:bmanning@karoshi.com] > Sent: Wednesday, January 07, 2004 12:25 PM > To: Christopher.Malayter(a)tdstelecom.com > Cc: nanog(a)merit.edu > Subject: Re: Anyone alive at ep.net > > > > I've been awaiting allocation of an IP from an IX that is allocated by > > ep.net. > > > > I've been recieving connection refused form the mailserver from several > > domains for over a week. > > --bill Ok for the NANOG folks. We found Christopher's request in the "questionable" spool, it was submitted less than 48 hours ago. The EP.NET turn time is listed at 96 hours. The gyrations on the EP.NET end are due to: - office relo - software upgrades (new OS) - spam mitigation processes His request will be processed in the normal window. There are still some issues w/ procmail/spamassasin tuning. --bill

1 0

Re: GSR, 7600, Juniper M?, oh my!
by Tom (UnitedLayer) 07 Jan '04

07 Jan '04

On Wed, 7 Jan 2004, Florian Weimer wrote: > Tom (UnitedLayer) wrote: > > Buying GSR's is probably the right replacement for 7500's if you want to > > stick with Cisco. > > But be careful when buying the linecards. Not all of them have > comparable forwarding performance to the 7500 if you do something else > than mere IP packet fowarding (e.g. ACLs or policy-based routing). Given that a GEIP in a 7500 can only do 200-300Mbps (packet load dependant), I hope the GSR can do better :) I have heard of instances where enabling inbound packet filtering or shaping on certain GigE cards would cause the cards to shutdown or reboot. I generally don't do shaping/etc on core gear, because its much easier to do it on my aggregation gear (2948G-L3/4908G-L3).

1 0

RE: GSR, 7600, Juniper M?, oh my!
by Jason Frisvold 07 Jan '04

07 Jan '04

Ours dropped about 70% ... And it's been steady ever since.. we've added a large number of modems since that time as well... Look into 'no cable-arp' as well ... Basically, it prevents arp broadcasts and that also had a major impact on the cpu utilization of our CMTS's.. Jason Frisvold Backbone Engineering Supervisor Penteledata > -----Original Message----- > From: Tarko Tikan [mailto:tarko@lanparty.ee] > Sent: Wednesday, January 07, 2004 2:55 PM > To: nanog(a)merit.edu > Subject: Re: GSR, 7600, Juniper M?, oh my! > > > hello! > > > The G1 processors, so far, have proven to be wonderful... We only have > > experience with them running in the 7200 uBR chassis, but they've shown > > a huge reduction in CPU utilization... > > what is huge reduction for you? we upgraded from npe-400 to npe-g1 on > ubr7200 and processor usage decreased 20-30%. And we are pushing about > 100Mbps traffic from GigE to cable and about 20-30Mbps from cable to GigE. > > -- > tarko

1 0

Anyone alive at ep.net
by Malayter, Christopher 07 Jan '04

07 Jan '04

I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. If anyone from ep.net could email me with our allocation request, thanks are in order. Thanks ahead of time, -Chris

4 5

MLPPP Problem with Cisco 7513
by Richard J. Sears 07 Jan '04

07 Jan '04

I am hoping someone can shed some light on an interesting problem we are having - When we set up a customer for MLPPP, things tend to go well for a period of time. Then - all of a sudden - we will begin to have problems with our multilink bundles (generally only one at a time) and the only fix is to reload our 7513. This problem happens on both of our 7513 routers from time-to-time. Once we reload - the problem will stay gone for as long as several months, or in the last case only about 12 hours. Once we see the problem, it is apparent only in one direction. For example the customer can push the full capacity of their circuits to us, but they cannot pull anything above about 300k back to them on a two-T1 bundle. This is the same every single time we have the problem. We have changed multilink bundles, tried different types of switching and route caching, turning on and off fragmentation - the only thing that solves the problem is reloading the entire router. We can pull the T1s from the multilink bundle and each individual T1 works great. No line errors, no crc errors - nothing. No errors are apparent while in MLPPP mode either. No throttles or anything similar. We have had this problem in the past and it was recommended that we upgrade the code on our 7513s. We are currently running version 12.2(13)T5 on both our 7513 as well as the customers router. Upgrading the code did not solve the problem. I have been unable to locate a Cisco bug defining this type of problem for any version of their code. This particular customer's T1s are both terminated on the same VIP (we are running DMLP) but are terminated on separate PAs and hence separate CT3s. We have noticed the problem even with T1 bundles on the exact same PA and CT3. We are not doing multi-chassis DMLP. dCEF is enable on both routers, however the problem remains the same even after disable dCEF. Here are configs and router info: interface Multilink6 description Eastgate Mall (s2/1/0/8:0 and s2/0/0/12:0) [20291] ip address 207.158.1.133 255.255.255.252 no cdp enable ppp multilink ppp multilink interleave multilink-group 6 interface Serial2/0/0/12:0 description Eastgate Mall #2 no ip address encapsulation ppp no fair-queue ppp multilink multilink-group 6 interface Serial2/1/0/8:0 description Eastgate Mall #1 no ip address encapsulation ppp no fair-queue ppp multilink multilink-group 6 AR04#sh diag 2 Slot 2: Physical slot 2, ~physical slot 0xD, logical slot 2, CBus 0 Microcode Status 0x4 Master Enable, LED, WCS Loaded Board is analyzed Pending I/O Status: None EEPROM format version 1 VIP2 R5K controller, HW rev 2.02, board revision D0 Serial number: 17953368 Part number: 73-2167-05 Test history: 0x00 RMA number: 00-00-00 Flags: cisco 7000 board; 7500 compatible EEPROM contents (hex): 0x20: 01 1E 02 02 01 11 F2 58 49 08 77 05 00 00 00 00 0x30: 68 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Slot database information: Flags: 0x4 Insertion time: 0x41C8 (1d08h ago) Controller Memory Size: 32 MBytes DRAM, 4096 KBytes SRAM PA Bay 0 Information: CT3 single wide PA, 1 port EEPROM format version 1 HW rev 1.00, Board revision A0 Serial number: 17814822 Part number: 73-3037-01 PA Bay 1 Information: CT3 single wide PA, 1 port EEPROM format version 1 HW rev 1.00, Board revision A0 Serial number: 09725065 Part number: 73-3037-01 --Boot log begin-- Cisco Internetwork Operating System Software IOS (tm) VIP Software (SVIP-DW-M), Version 12.2(13)T5, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Wed 28-May-03 21:57 by nmasa Image text-base: 0x60010930, data-base: 0x604C0000 AR04#sh ver Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-JSV-M), Version 12.2(13)T5, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Wed 28-May-03 22:00 by nmasa Image text-base: 0x60010948, data-base: 0x61F0A000 ROM: System Bootstrap, Version 11.1(8)CA1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) AR04 uptime is 1 day, 8 hours, 24 minutes System returned to ROM by reload at 09:45:48 UTC Tue Dec 23 2003 System image file is "slot0:rsp-jsv-mz.122-13.T5.bin" cisco RSP4 (R5000) processor with 262144K/2072K bytes of memory. R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last reset from power-on G.703/E1 software, Version 1.0. G.703/JT2 software, Version 1.0. X.25 software, Version 3.0.0. SuperLAT software (copyright 1990 by Meridian Technology Corp). Bridging software. TN3270 Emulation software. Primary Rate ISDN software, Version 1.1. Chassis Interface. 3 VIP2 R5K controllers (2 FastEthernet)(6 Channelized T3). 2 FastEthernet/IEEE 802.3 interface(s) 168 Serial network interface(s) 6 Channelized T3 port(s) 123K bytes of non-volatile configuration memory. 20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K). 8192K bytes of Flash internal SIMM (Sector size 256K). Slave in slot 7 is running Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-DW-M), Version 12.2(13)T5, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Wed 28-May-03 22:33 by nmasa Slave: Loaded from system Slave: cisco RSP4 (R5000) processor with 262144K bytes of memory. Configuration register is 0x2102 Any help would be greatly appreciated. ****************************************** Richard J. Sears Vice President American Digital Network ---------------------------------------------------- rsears(a)adnc.com http://www.adnc.com ---------------------------------------------------- 858.576.4272 - Phone 858.427.2401 - Fax ---------------------------------------------------- I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."

3 2

RE: GSR, 7600, Juniper M?, oh my!
by Drew Weaver 07 Jan '04

07 Jan '04

On Wed, 7 Jan 2004, Michel Py wrote: > not trying to defend the 7500 platform, it's obsolete all right. > However, free is music to my ears. What about longer term maintenance issues? Is the 7500 not scheduled for EOL from Cisco 'soon' ? So, purchasing 7500 bits that might be dropped by 'normal' Cisco support in 1 year versus purchasing some other hardware that will be in support longer might pay out in the longer term? --- Well technically buying a used 7500 doesn't entitle you to run IOS on it, so you need to re-license the Ebay Special and that usually costs close to what a new 7500 would cost. Anyway, on to the reason for my post. I've heard conflicting reports, is a 7206 faster at packet switching than a 7507? Some people tell me it is a better router, some people tell me it isn't. Feh. -Drew

2 1

RE: GSR, 7600, Juniper M?, oh my!
by Burns, Keith 07 Jan '04

07 Jan '04

If you are after copper aggregation and broadband user feature support, you might also want to take a look at the Cisco10000. Not sure of its POS capabilities, but depending on your density, might be cheaper $/port than the 7600. Heard mixed reports on the E-series from Juniper (software mainly, so it does depend on what you try and do with it), but if you want line rate ACLs, QoS etc, hard to go past the M-series (spec. M10i, M7i). OT: love the doilly comments on the 7500. I'll have to ask Mum to make me a few... Keith Burns Principal Network Architect ICG Telecommunications IP Ph: 303-414-5385 Cell: 303-912-3777 "The dogs may bark, but the caravan rolls on...." > -----Original Message----- > From: neil(a)DOMINO.ORG [mailto:neil@DOMINO.ORG] > Sent: Wednesday, January 07, 2004 1:27 AM > To: ras(a)e-gerbil.net > Cc: bcm(a)inkline.com; nanog(a)merit.edu > Subject: Re: GSR, 7600, Juniper M?, oh my! > > > > > 7500s? In 2004? Throw those things in the trash where they > belong. It's > > always amazing to me how many people will cling to obsolete > things for > > years just because it is what they know. > > Don't agree with this. For E1/T1 access these boxes are fine. Yes > they are long in the tooth but they are quite capable. I > wouldn't spend > a huge amount of time or money trying to make them do > anything else though. > > > Even a Juniper M5 will do 16 OC3's with line rate filtering and > > forwarding. There are probably a dozen design > considerations based on > > requirements you haven't described, but if you're doing > primarily sonet, > > 7600 isn't really the way to go. > > Depends on what "primarily sonet" means. > > Regards, > Neil. >

1 0

remember ORBL.ORG?
by Mark Jeftovic 07 Jan '04

07 Jan '04

If anyone has any legacy mailhubs sitting around that used to use it, better check it out. It was a harmless until yesterday, when the domain was snagged by Pool.com and parked with wildcard DNS. -mark -- Mark Jeftovic <markjr(a)easydns.com> Co-founder, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(416)-535-0237

1 0