July 2008 - Test - lists.nanog.org

weirdness with Extreme
by Andy Grosser 21 Jul '08

21 Jul '08

Has anyone else seen this kind of thing before? 2 Extreme Black Diamond 6804s (ExtremeWare 7.2.0b37) at the core (active/standby) start to fight over which of them is master for a particular VLAN. They go back and forth for maybe a minute, and for a brief period, the master switch seems to fight with itself over which will cede master status. The log messages indicate either high/low port count, or high/low priority, for that particular vlan. ESRP then forces access switches hanging off the cores to flush their forwarding databases. All activity takes place within a span of just over a minute, then dies. Extreme doesn't have anything to report yet. Just wondering if anyone has seen behavior like this in an Extreme environment. Thanks, Andy --- Andy Grosser andy [at] meniscus {dot} org ---

7 7

Re: connectivity to MSN
by Nick Shank 21 Jul '08

21 Jul '08

Everything should be up and running, and I haven't gotten a ticket to the contrary. A tracert works for me, but I'm behind the firewall, so it's of no use to anyone else. ~Nick -----Original Message----- >From: Matt Liotta <mliotta(a)r337.com> >Sent: Jul 21, 2008 7:56 AM >To: nanog(a)nanog.org >Subject: connectivity to MSN > >Anyone having problems with MSN? Depending on which AS I use the >traceroute dies in different places, but most of the time it dies in >AS 8075. However, MSN does seem accessible from XO and Comcast. > >-Matt >

1 0

connectivity to MSN
by Matt Liotta 21 Jul '08

21 Jul '08

Anyone having problems with MSN? Depending on which AS I use the traceroute dies in different places, but most of the time it dies in AS 8075. However, MSN does seem accessible from XO and Comcast. -Matt

2 1

Re: Force10 E300 vs. Juniper MX480
by Keith O'neill 21 Jul '08

21 Jul '08

Force 10 is fine. I do suggest he go with the dual cam cards over the regular cards. I am not sure what Chris is talking about but I have used Force 10 for a long time, E, C and S series and have found it very stable. It will do everything you want and then some. The E300 is a good bang for the buck. Sure Foundry might be cheaper but I hear more complaining about Foundry than any other platform. Chris you want to share what issues you have seen with Force 10. Keith ----- Original Message ----- From: "Chris Marlatt" <cmarlatt(a)rxsec.com> To: "Joe Abley" <jabley(a)ca.afilias.info> Cc: "nanog" <nanog(a)merit.edu> Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York Subject: Re: Force10 E300 vs. Juniper MX480 Joe Abley wrote: > Hi all, > > An acquaintance who runs an ISP with an M7i on its border is looking to > upgrade, because the M7i is starting to creak from all the flesh-tone > MPEGs his customers are sharing. (How times have changed. Back when I > was chasing packets, it was flesh-tone JPEGs.) > > He's looking at the MX480 and the E300. > > The MX480 is attractive because the M7i has been stable as a rock, and > he's familiar with JUNOS. > > The E300 is attractive because it's half the price of the MX480, and has > the potential to hold layer-2 cards as well as layer-3 ports which makes > the price per port much more reasonable than the MX480. But he has no > experience with Force10 at any ISO layer higher than 2. > > He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and > IPv6. There's no MPLS in the picture, for example. However, he's going > to want four or five full tables plus a moderate load of peering routes > in there. And maybe VRRP. > > Thoughts from people who have tried one or the other, or both? Or who > have faced this kind of problem, and came up with a different answer? > > Feel free to send mail off-list; I can summarise if there is interest. > > > Joe > I would avoid Force10 if at all possible. In the network I managed I've had some fairly surprising stability problems with their S series switches and feature problems (or lack there of) on their E series. Things you kind of scratch your head at and wonder what they were thinking. Juniper on the other hand is indeed a bit pricier but quite a stable platform. If he has to look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) for comparable models to the MX480. Regards, Chris

7 9

NMS for Carriers
by Adam Armstrong 21 Jul '08

21 Jul '08

Hi All, We're kicking off a project to find a new NMS and I thought you guys might have some helpful advice. We're a smallish telco (on an island, infact) so we have a very wide range of kit to monitor, from servers to routers to dslams and all that dirty voice stuff. Which software are you guys using? Any obvious gotchas with the various solutions? We're looking at EMC Smarts first. Anyone got any comments to make on that? Thanks in advance! adam.

2 1

RE: Cisco vs Adtran vs Juniper
by Paul Stewart 21 Jul '08

21 Jul '08

Thanks guys so far for the responses.... Adtran has a 5 year warranty and support for free as of today - I'm not aware of this changing but we've had a number of other companies change that policy in the past couple of years after purchasing a LOT of gear from them (Motorola, Redline come to mind among others). Cisco has "lifetime hardware warranty" on some of their gear but nobody has ever been able to tell me what that *really* means and how you would ever get it covered if you did NOT have Smartnet coverage...;) UC500's - nice boxes ... pure cost issues around this one. You need to add a 24 port switch if you want some form of density at additional cost... makes it 3X the Adtran price so gets a lot of attention here... Keep it coming guys.. appreciate it... Paul -----Original Message----- From: Smith, Steve B [mailto:ss4414@att.com] Sent: Friday, July 18, 2008 11:44 AM To: Chris Heighway; Paul Stewart Cc: nanog Subject: RE: Cisco vs Adtran vs Juniper And remember Adtran has a 5 year warranty and support for free. -----Original Message----- From: Chris Heighway [mailto:heighway@gmail.com] Sent: Friday, July 18, 2008 10:22 AM To: Paul Stewart Cc: nanog Subject: Re: Cisco vs Adtran vs Juniper On your last note Cisco also offers a all-in-one with all the features you talked about and more. They are called UC500's. _Chris On Fri, Jul 18, 2008 at 10:18 AM, Paul Stewart <pstewart(a)nexicomgroup.net> wrote: > Hi there.. > > I'm looking for some constructive feedback on **real world** > experiences please... > > We're primarily a Cisco shop today - our core and distribution are all > Cisco driven and will continue to be (won't change that so not worth > discussing today). > > My question is oriented towards two other markets primarily: > > Security Devices > Remote Office/Customer Site Devices > > Let me elaborate a bit more... > > Security - today, we've been deploying Cisco ASA boxes (was PIX before > that) with pretty good success. However, in comparison to Juniper the > Cisco boxes are *really* expensive - at least to us anyways. Juniper > has nice products so I'm looking at proposing a solution internally to > move towards the Juniper security appliances. Feedback from folks on > them vs Cisco ASA?? > > Remote Office/Customer Site Devices - today, we do a lot of "managed > routers" to customer sites. Again, cost driven, I'm being pushed > towards looking at Adtran devices for customer sites that we maintain. > I have nothing against Adtran but haven't viewed them to date as being > in the same "arena" as Cisco/Juniper etc.. these routers are mainly > providing basic firewalling/NAT and some very small VPN activity at > times. > > To take this one step further, some of our voice folks are really > enjoying the Adtran boxes as it offers an "all in one solution" which > is a router, firewall, "voice" box (many options - PRI handoff, T1, > FXS/FXO) and in some of their boxes 24 POE switch ports as well. This > is kinda cool I'll admit but the approach in the past has been to drop > in a Cisco router, Adtran for voice applications, and then Cisco POE > switches if required. This is very costly compared to Adtran's all in > one approach.... so am I being stubborn on this or is the Adtran > products in this case in the same league?? I had some terrible track > record with Adtran a number of years ago so my back gets up when their > name is mentioned...;) > > Any feedback would be very appreciated - we're going to have meetings > internally in the next while to decide which product lines fit with > which service offerings the best.... > > Thanks, > > Paul > > > > > > > ---------------------------------------------------------------------- > ------ > > "The information transmitted is intended only for the person or entity > to which it is addressed and contains confidential and/or privileged material. > If you received this in error, please contact the sender immediately > and then destroy this transmission, including all attachments, without > copying, distributing or disclosing same. Thank you." > > ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

3 3

Re: Savvis Related Routing Issue
by Brendan Mannella 19 Jul '08

19 Jul '08

My setup is fairly simple, i dont really know where to look... M7i border routers, one with a Fast-E to Mizma and GLBX and one with Sprint Fast-E, they both run IBGP with BI4k (jetCore), out to L2s. I have seen this issue across both the Mzima link and the GLBX link, the only common thing with them is they are on the same router and 4 port PIC card, and they both travel via a L2 MPLS link to Ashburn, VA via the same transport provider. Brendan ----- Original Message ----- From: "Daniel Senie" <dts(a)senie.com> To: "Brendan Mannella" <bmannella(a)teraswitch.com> Sent: Saturday, July 19, 2008 10:53:12 PM GMT -05:00 US/Canada Eastern Subject: Re: Savvis Related Routing Issue The fact that changing the target IP address by one changes things makes me think you may have a multi-wire trunking setup between some Ethernet switches, and that trunking is spreading load based on hashing IP addresses. Look close to home, or in your link to your upstream as likely places for this. Might not be your issue, but I've seen this kind of thing before, and found the issue in switch-to-switch trunking or the equivalent in multi-circuit load balancing between routers (e.g. multiple T1's between two routers, where ML-PPP should have been used, and wasn't). At 10:36 PM 7/19/2008, you wrote: >Hello, > >I am seeing a really weird routing issue. I have customers who are >having trouble connecting to hosts on the internet. The common item >seems to be Savvis. > >orange:~>traceroute mail.tecumsehherald.com >traceroute to mail.tecumsehherald.com (64.14.74.42) >1 204.16.245.97 (204.16.245.97) 0.580 ms 0.800 ms 1.020 ms >2 204.16.241.225 (204.16.241.225) 0.496 ms 0.478 ms 0.699 ms >3 64.209.102.233 (64.209.102.233) 7.177 ms 7.420 ms 7.417 ms >4 te1-3-10g.ar2.DCA3.gblx.net (67.17.108.145) 7.630 ms 7.870 ms 8.105 ms >5 * * * >6 * * * > >Hop 5 is a Savvis router. > >Now if i go to Global Crossings looking glass and run a trace from >their DC router to the same host, it makes it. > >1 64.214.14.161 (64.214.14.161) 0.457 ms 0.429 ms >2 te7-1-10G.ar2.DCA3.gblx.net (67.17.109.34) 1.401 ms 1.658 ms >3 savvis-1.ar2.DCA3.gblx.net (64.212.107.26) 1.567 ms 1.339 ms >4 ber1-tenge-2-1.virginiaequinix.savvis.net (204.70.193.6) 1.586 ms 1.511 ms >5 cr1-tengig0-7-2-0.washington.savvis.net (204.70.197.242) 2.367 ms 2.547 ms >6 cr1-pos-0-0-0-0.boston.savvis.net (204.70.193.177) 15.163 ms 15.836 ms >7 hr1-pos-1-0-0.Waltham2bo2.savvis.net (208.172.51.66) 11.702 ms 11.780 ms >8 csr1-ve242.Waltham1bo1.savvis.net (64.14.70.19) 12.202 ms 11.728 ms >9 64.14.67.130 (64.14.67.130) 11.570 ms 11.592 ms >10 ns2.s426.sureserver.com (64.14.74.42) 11.811 ms 11.927 ms > >Now to top it all of, if i run a trace to the 64.14.74.41, instead >of 64.14.74.42 it works... > >agg1.pit#traceroute 64.14.74.41 >Type Control-c to abort >Tracing the route to IP node 64.14.74.41 from 1 to 30 hops > >1 <1 ms <1 ms <1 ms 204.16.241.225 >2 7 ms 7 ms 6 ms 64.209.102.233 >3 7 ms 6 ms 6 ms te1-3-10g.ar2.DCA3.gblx.net [67.17.108.145] >4 6 ms 6 ms 6 ms savvis-1.ar2.DCA3.gblx.net [64.212.107.26] >5 45 ms 6 ms 7 ms ber1-tenge-2-1.virginiaequinix.savvis.net [204.70.193.6] >6 14 ms 14 ms 15 ms cr1-tengig0-7-2-0.washington.savvis.net [204.70.197.242] >7 21 ms 22 ms 23 ms cr1-pos-0-0-0-0.boston.savvis.net [204.70.193.177] >8 20 ms 19 ms 20 ms hr1-pos-1-0-0.Waltham2bo2.savvis.net [208.172.51.66] >9 19 ms 20 ms 19 ms csr1-ve242.Waltham1bo1.savvis.net [64.14.70.19] >10 20 ms 19 ms 19 ms 64.14.67.130 >11 20 ms 20 ms 20 ms s426.sureserver.com [64.14.74.41] > >Does anyone have and ideas? > >Thanks, > >Brendan

1 0

Re: Ubiquity<->Mzima routing loop
by Guy_Shields＠Stream.Com 19 Jul '08

19 Jul '08

No, a true routing loop will transit several hops and end back up at the same routers. A bouncing route between 2 routers is usually a directly connected route on an interface that goes down thereby "pulling" the route with out a nail down route it will send unkown route back out its default gateway. ----- Original Message ----- From: "Paul Wall" [pauldotwall(a)gmail.com] Sent: 07/18/2008 10:25 PM AST To: Guy Shields Cc: nanog <nanog(a)merit.edu> Subject: Re: Ubiquity<->Mzima routing loop Isn't that what a routing loop is, when it loops back out to the transit/interface from which it entered? Paul On Fri, Jul 18, 2008 at 7:07 PM, <Guy_Shields(a)stream.com> wrote: > This is not a routing loop. It is simply a route that was not tied down via a static route to NULL with a weight of 254. > > > ----- Original Message ----- > From: "Paul Wall" [pauldotwall(a)gmail.com] > Sent: 07/18/2008 06:57 PM AST > To: "William Pitcock" <nenolod(a)systeminplace.net> > Cc: nanog(a)merit.edu > Subject: Re: Ubiquity<->Mzima routing loop > > > > I'd like to rip on Mzima as much as the next guy, but I'm not sure how > they could "fix" this routing loop, shy of some creative ACLs. > > You should try contacting Ubiquity, as this traceroute looks like an > issue on their (Mzima's customer's) side. > > Paul Wall > > On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock > <nenolod(a)systeminplace.net> wrote: >> Hi, >> >> Can someone at Ubiquity or Mzima fix this routing loop: >> >> traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte >> packets >> 1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms >> 2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms >> 15.964 ms >> 3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858 >> ms 14.838 ms >> 4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms >> 16.497 ms >> 5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763 >> ms 14.745 ms >> 6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms >> 8.758 ms >> 7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * * >> 8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms >> 4.381 ms >> 9 * * * >> 10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms >> 4.914 ms >> 11 * * * >> 12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms >> 14.438 ms >> 13 * * * >> 14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms >> 3.770 ms >> 15 * * * >> 16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms >> 13.897 ms >> 17 * * * >> 18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms >> 8.668 ms >> 19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms >> 20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms >> 8.545 ms >> 21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms >> 22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms >> 8.913 ms >> 23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms * >> 24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms >> 15.736 ms >> 25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092 >> ms >> 26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms >> 10.752 ms >> 27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336 >> ms * >> 28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms >> 3.823 ms >> 29 * * * >> 30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms >> 13.019 ms >> >> Thanks! >> >> William >> >> >> > >

2 1

Savvis Related Routing Issue
by Brendan Mannella 19 Jul '08

19 Jul '08

Hello, I am seeing a really weird routing issue. I have customers who are having trouble connecting to hosts on the internet. The common item seems to be Savvis. orange:~>traceroute mail.tecumsehherald.com traceroute to mail.tecumsehherald.com (64.14.74.42) 1 204.16.245.97 (204.16.245.97) 0.580 ms 0.800 ms 1.020 ms 2 204.16.241.225 (204.16.241.225) 0.496 ms 0.478 ms 0.699 ms 3 64.209.102.233 (64.209.102.233) 7.177 ms 7.420 ms 7.417 ms 4 te1-3-10g.ar2.DCA3.gblx.net (67.17.108.145) 7.630 ms 7.870 ms 8.105 ms 5 * * * 6 * * * Hop 5 is a Savvis router. Now if i go to Global Crossings looking glass and run a trace from their DC router to the same host, it makes it. 1 64.214.14.161 (64.214.14.161) 0.457 ms 0.429 ms 2 te7-1-10G.ar2.DCA3.gblx.net (67.17.109.34) 1.401 ms 1.658 ms 3 savvis-1.ar2.DCA3.gblx.net (64.212.107.26) 1.567 ms 1.339 ms 4 ber1-tenge-2-1.virginiaequinix.savvis.net (204.70.193.6) 1.586 ms 1.511 ms 5 cr1-tengig0-7-2-0.washington.savvis.net (204.70.197.242) 2.367 ms 2.547 ms 6 cr1-pos-0-0-0-0.boston.savvis.net (204.70.193.177) 15.163 ms 15.836 ms 7 hr1-pos-1-0-0.Waltham2bo2.savvis.net (208.172.51.66) 11.702 ms 11.780 ms 8 csr1-ve242.Waltham1bo1.savvis.net (64.14.70.19) 12.202 ms 11.728 ms 9 64.14.67.130 (64.14.67.130) 11.570 ms 11.592 ms 10 ns2.s426.sureserver.com (64.14.74.42) 11.811 ms 11.927 ms Now to top it all of, if i run a trace to the 64.14.74.41, instead of 64.14.74.42 it works... agg1.pit#traceroute 64.14.74.41 Type Control-c to abort Tracing the route to IP node 64.14.74.41 from 1 to 30 hops 1 <1 ms <1 ms <1 ms 204.16.241.225 2 7 ms 7 ms 6 ms 64.209.102.233 3 7 ms 6 ms 6 ms te1-3-10g.ar2.DCA3.gblx.net [67.17.108.145] 4 6 ms 6 ms 6 ms savvis-1.ar2.DCA3.gblx.net [64.212.107.26] 5 45 ms 6 ms 7 ms ber1-tenge-2-1.virginiaequinix.savvis.net [204.70.193.6] 6 14 ms 14 ms 15 ms cr1-tengig0-7-2-0.washington.savvis.net [204.70.197.242] 7 21 ms 22 ms 23 ms cr1-pos-0-0-0-0.boston.savvis.net [204.70.193.177] 8 20 ms 19 ms 20 ms hr1-pos-1-0-0.Waltham2bo2.savvis.net [208.172.51.66] 9 19 ms 20 ms 19 ms csr1-ve242.Waltham1bo1.savvis.net [64.14.70.19] 10 20 ms 19 ms 19 ms 64.14.67.130 11 20 ms 20 ms 20 ms s426.sureserver.com [64.14.74.41] Does anyone have and ideas? Thanks, Brendan

1 0

Bogon Filter Update Request
by Stan Barber 19 Jul '08

19 Jul '08

Greetings NANOGers, Yes, I know it has been many years since I have been more than a lurker here on the NANOG list. It is gratifying to see the group continue to facilitate discussions among those that "get it done" in keeping the Internet up and running. Recently, I have moved back into a more operational role and I hope to renew my involvement here as I settle back in. So, to the point of my note: Bogon filter updates! I want to tell you that I am very appreciative of those operators out there that follow the changes in status of IP space and keep there BOGON filters updated. Unfortunately, it appears that there are many that are not doing this regularly. I have been working on getting BOGON filter updates for the 174/8 space (IANA allocated this to ARIN back in February) with upwards of 35 providers (some of the Tier 1 providers are among these) over the last several weeks. Please help me (and others who are getting allocations) by reviewing your BOGON filters and insure you are really filtering out BOGONs and not space that is allocated. If you need a pointer, the authorataive list is maintained at http://www.iana.org/assignments/ipv4-address-space. Thanks for your attention and I hope to see some of you at an upcoming NANOG meeting. Stan Barber sob(a)academ.com (called "the other SOB on the Internet" by Scott Bradner many years ago in his first column for Network World magazine)

2 1