- Test - lists.nanog.org

verizon postmaster contact?
by Brian Russo 11 Aug '04

11 Aug '04

Can someone with verizon mail/postmaster group get in touch with me. thanks, - bri -- Recursivity. Call back if it happens again.

1 0

Testing procedures for new network implementation?
by Wayne Chow 11 Aug '04

11 Aug '04

Hi All We are in the process of planning for the upgrade of a 3Com network. The new infrastructure will be comprised of 3Com 4950s with XRN and a dozen stacks of 4400s. What are the best practices of testing the new implementation? Any advices or suggestions would be greatly appreciated. The only software that we have is the 3Com Network Director. Thank you in advance. Wayne Chow Network Administrator Faculty of Dentistry, University of Toronto

4 4

Legal intercept - 3550
by Stefan Baltus 11 Aug '04

11 Aug '04

Hi, We have a situation where we need to intercept certain IP traffic that is somewhere within a link of 300Mbit/s of traffic (GigabitEthernet). The setup that we built is as follows: router ^ | GE | fiber tap -------> cisco catalyst 3550 | | GE v switch The catalyst 3350 is receiving the traffic from router to switch and vice versa. Now, we'd like to filter all but certain IP's on the 3350 and switch this traffic to a FE port on that same 3550. Currently we've put the FE interface in SPAN mode, but that fills up the FE port completely (obviously). Is there any way to accomplish this? Regards, Stefan -- Stefan Baltus <stefan.baltus(a)xbn.nl> XB Networks B.V. Manager Engineering Televisieweg 2 telefoon: +31 36 5462400 1322 AC Almere fax: +31 36 5462424 The Netherlands

5 5

Verizon Data (T1) Rep?
by Jonathan M. Slivko 11 Aug '04

11 Aug '04

Hello, Can a Verizon Data (T1) Rep. please call/contact me off list ASAP? Thanks! -- Jonathan -- Jonathan M. Slivko Invisible Hand Networks, Inc. 670 Broadway, Suite 302 New York, NY 10012 Phone: (212) 226-1422 x601 Fax: (212) 202-7640 jslivko(a)invisiblehand.net

1 0

Are AOL's MXs mass rejecting anyone else's emails?
by Andrew Paprocki 11 Aug '04

11 Aug '04

We're currently getting this from AOL MX servers: 64.12.138.57 failed after I sent the message. Remote host said: 554-: (RLY:FA) http://postmaster.info.aol.com/errors/554rlyfa.html 554 TRANSACTION FAILED Yet, after viewing their alleged reason for rejecting the mail, we can find nothing wrong with our mail headers. Wondering if this is a bug on AOL's side or if anyone else has encountered/fixed this issue to stop the bouncing mail? -Andrew

1 0

Floorspace / Power Possibilities - location independant
by Micah McNelly 11 Aug '04

11 Aug '04

Guys/Gals, I'm currently digging for cheap floorspace / power / network with no specific geographical region in mind. If you know of any well managed facilities with very low per square foot cost and cheap power (no hamsters please) please respond to me offlist. Should be carrier neutral but have bandwidth available. Thanks, /m

1 0

Re: That MIT paper
by Joe Shen 11 Aug '04

11 Aug '04

Hi, >The paper doesn't pass any judgement on types of lookups, but obviously >not all DNS lookups are equal from the end user perspective. In our observation, looking for IP address consists 70% of our cache server load, MX consists of 14% and PTR only occupies 5%. And, on the other hand, the coarse analysis of our network traffic shows, Web traffic occupies only 8% while stream meadia occupies the most part of traffic. So, the authors the conclusion may be correct as viewing film online does not rely on DNS so much as browsing web pages. But, to my understanding a too short TTL will do harm to cache server performance esp. the amount of RR cached is so large that BIND have to wait for swapping I/O and re-fetching those timeout RR again. >"In our follow-up measurement study, [we found] that DNSBL related > DNS lookups at CSAIL in February 2004 account for 14% of all DNS > lookups. In comparison, DNSBL related traffic accounted for merely > 0.4% of all DNS lookups at CSAIL in December 2000." Is these work published or available publicly? Any work done with performance tuning with cache server? > 1. almost nobody has time to invest in reading this kind of paper. > 2. almost everybody is willing to form a strong opinion regardless of that. > 3. people from #2 use the paper they didn't read in #1 to justify an opinion. people rely on their experience, but science tries to find on basis of analysis. Usually, we met problems which is caused by people replace scientific conclusion with their experience. Joe ---- Introducing Spymac MailPro: http://www.spymac.com/mailpro/

2 1

BellSouth: please stop advertising 209.152.54.0/23
by Jon Snyder 10 Aug '04

10 Aug '04

BellSouth is advertising 209.152.54.0/23, which is part of 209.152.32.0/19 owned by someone else who isn't a BellSouth customer. If anyone from BellSouth is listening, can you please make this stop? Or if you have a working contact at BellSouth please let me know. The number for their NOC listed at http://puck.nether.net/netops/ is not working and emails and phone calls to all of the contacts listed in their ARIN entries have gone unanswered. Here's some relevant routeviews data: route-views.oregon-ix.net>sh ip bgp 209.152.54.0 BGP routing table entry for 209.152.54.0/23, version 30041418 Paths: (14 available, best #7, table Default-IP-Routing-Table) Not advertised to any peer 3292 6939 6389 6198 195.249.0.135 from 195.249.0.135 (195.249.0.135) Origin IGP, localpref 100, valid, external Community: 3292:1107 3292:1905 7500 2516 7911 6389 6198 202.249.2.86 from 202.249.2.86 (202.12.27.99) Origin IGP, localpref 100, valid, external 3277 13062 25462 6320 8001 6389 6198 194.85.4.55 from 194.85.4.55 (194.85.4.55) Origin IGP, localpref 100, valid, external Community: 3277:13062 3277:65301 3277:65307 6461 6389 6198 209.249.254.19 from 209.249.254.19 (209.249.254.19) Origin IGP, metric 3203, localpref 100, valid, external Community: 6461:5997 16150 13237 174 6389 6198 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 13237:44088 13237:46881 16150:65320 16150:65324 12956 6389 6198 213.140.32.146 from 213.140.32.146 (213.140.32.146) Origin IGP, localpref 100, valid, external Community: 12956:20024 12956:28310 12956:28311 8001 6389 6198 209.123.12.51 from 209.123.12.51 (209.123.12.51) Origin IGP, localpref 100, valid, external, best Community: 6389:20103 6389:30132 6389:46198 8001:2000 8001:2006 3333 6320 8001 6389 6198 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 7660 2516 7911 6389 6198 203.181.248.233 from 203.181.248.233 (203.181.248.13) Origin IGP, localpref 100, valid, external 6939 6389 6198 216.218.252.152 from 216.218.252.152 (216.218.252.152) Origin IGP, localpref 100, valid, external 7911 6389 6198 64.200.151.12 from 64.200.151.12 (64.200.151.12) Origin IGP, localpref 100, valid, external Community: 6389:20103 6389:30132 6389:46198 7911:999 7911:7206 11608 3491 6389 6198 207.246.129.14 from 207.246.129.14 (207.246.129.14) Origin IGP, localpref 100, valid, external Community: 11608:1006 11608:5504 7911 6389 6198 64.200.95.239 from 64.200.95.239 (64.200.95.239) Origin IGP, localpref 100, valid, external Community: 6389:20103 6389:30132 6389:46198 7911:999 7911:7206 6939 6389 6198 216.218.252.145 from 216.218.252.145 (216.218.252.145) Origin IGP, localpref 100, valid, external Thanks, ---------- Jon Snyder

4 3

BGP Redistribution question
by D Train 10 Aug '04

10 Aug '04

While looking into a routing issue, I found that one of my routers wasn't passing one of my static routes, being redist into ospf into bgp, and not sure as to why. It has been a while since I have worked with BGP, so I am a little rusty. The solution was for me to add the following BGP network statement... network 10.86.8.0 mask 255.255.248.0. If statics are being redist info ospf, and ospf is basically being redist into bgp, why did I have to have the network statement. Why didn't it put it into BGP and pass it along? Here is the scenario: Router A: ip route 10.86.8.0 255.255.248.0 10.86.138.14 ATL--CR6513A#ping 10.86.138.14 success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms ATL -CR6513A#sh ip route 10.86.8.0 Routing entry for 10.86.8.0/21 Known via "static", distance 1, metric 0 Redistributing via ospf 1 Advertised by ospf 1 subnets bgp 2 Routing Descriptor Blocks: * 10.86.138.14 Route metric is 0, traffic share count is 1 ATL-CR6513A#sh ip ospf data ext 10.86.8.0 OSPF Router with ID (10.86.194.5) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 898 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.86.8.0 (External Network Number ) Advertising Router: 10.86.194.2 LS Seq Number: 80000D87 Checksum: 0x3D49 Length: 36 Network Mask: /21 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 LS age: 554 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.86.8.0 (External Network Number ) Advertising Router: 10.86.194.5 LS Seq Number: 80000D87 Checksum: 0x2B58 Length: 36 Network Mask: /21 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 ATL-CR6513A#sh ip bgp 10.86.8.0 BGP routing table entry for 10.86.0.0/16, version 1078065 Paths: (2 available, best #2, table Default-IP-Routing-Table) Multipath: eBGP Advertised to non peer-group peers: 10.1.2.9 1, (aggregated by 1 10.1.254.253) 10.1.2.9 from 10.1.2.9 (10.1.254.253) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, multipath 1, (aggregated by 1 10.1.254.252) 10.1.2.1 from 10.1.2.1 (10.1.254.252) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, multipath, best router ospf 1 redistribute static subnets router bgp 2 no synchronization network x.x.x.x network y.y.y.y network 10.86.8.0 mask 255.255.248.0 ***had to be added for this to work, but wasn't present before hand*** redistribute connected route-map OSPF-Links redistribute ospf 1 route-map WW-OSPF-Routes neighbor 10.1.2.1 remote-as 1 neighbor 10.1.2.1 advertisement-interval 1 neighbor 10.1.2.9 remote-as 1 neighbor 10.1.2.9 advertisement-interval 1 maximum-paths 2 no auto-summary route-map WW-OSPF-Routes permit 10 set metric-type internal This is I was seeing on my Upstream Core router: ATL -CR12406A#sh ip route 10.86.8.0 Routing entry for 10.86.0.0/16 Known via "bgp 1", distance 200, metric 0, type locally generated Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 AS Hops 0, BGP network version This is what I was seeing after I add the network statement: GAATL-WW1-CR12406A#sh ip bgp 10.86.8.0 BGP routing table entry for 10.86.8.0/21, version 2210556 Paths: (2 available, best #2, Advertisements suppressed by an aggregate.) Multipath: eBGP iBGP Not advertised to any peer 2 10.1.2.2 from 10.1.2.2 (10.86.194.5) Origin IGP, metric 0, localpref 100, valid, external, multipath 2 10.1.2.6 from 10.1.2.6 (10.86.194.2) Origin IGP, metric 0, localpref 100, valid, external, multipath, best __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

2 1

Re: that MIT paper again
by Paul Vixie 10 Aug '04

10 Aug '04

i wrote: > wrt the mit paper on why small ttl's are harmless, i recommend that > y'all actually read it, the whole thing, plus some of the references, > rather than assuming that the abstract is well supported by the body. > > http://nms.lcs.mit.edu/papers/dns-imw2001.html here's what i've learned by watching nanog's reaction to this paper, and by re-reading the paper itself. 1. almost nobody has time to invest in reading this kind of paper. 2. almost everybody is willing to form a strong opinion regardless of that. 3. people from #2 use the paper they didn't read in #1 to justify an opinion. 4. folks who need academic credit will write strong self-consistent papers. 5. those papers do not have to be inclusive or objective to get published. 6. on the internet, many folks by nature "think locally and act globally". 7. #6 includes manufacturers, operators, endusers, spammers, and researchers. 8. the confluence of bad science and disinterested operators is disheartening. 9. good "actual policy" must often fly in the face of "accepted mantra". we now return control of your television set to you.

2 1