September 2009 - Test - lists.nanog.org

[NANOG-announce] Lightning talks open for NANOG 47
by David Meyer 15 Sep '09

15 Sep '09

Just a reminder: Lightning talks are open for NANOG 47. Looking forward to your submissions. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Re: Repeated Blacklisting / IP reputation
by JC Dill 15 Sep '09

15 Sep '09

John Curran wrote: > On Sep 8, 2009, at 2:18 PM, JC Dill wrote: > > > It seems simple and obvious that ARIN, RIPE, et. al. should > > determine the blacklist state of a reclaimed IP group and ensure > > that the IP group is usable before re-allocating it. > > > > When IPs are reclaimed, first check to see if the reclaimed IPs are > > on any readily checked RBL or private blacklist of major ISPs, > > corporations, universities, etc. If so, work with those groups to > > get the blocks removed *prior* to reissuing the IPs to a new > > entity. Before releasing the IPs to a new entity, double check that > > they are not being blocked (that any promises to remove them from > > a blacklist were actually fulfilled). Hold the IPs until you have > > determined that they aren't overly encumbered with prior blacklist > > blocks due to poor behavior of the previous entity. (The same > > should be done before allocating out of a new IP block, such as > > when you release the first set of IPs in a new /8.) > > In this case, it's not the RBL's that are the issue; the address > block in question isn't on them. It's the ISP's and other firms > using manual copies rather than actually following best practices. It's not that hard to make a list of the major ISPs, corporations, universities (entities with a large number of users), find willing contacts inside each organization (individual or role addresses you can email, and see if the email bounces, and who will reply if the email is received) and run some automated tests to see if the IPs are being blocked. In your follow-up email to me, you said you check "dozens" of RBLs - that is clearly insufficient - probably by an order of magnitude - of the entities you should check with. The number should be "hundreds". A reasonably cluefull intern can provide you with a suitable list in short order, probably less than 1 day, and find suitable contacts inside each organization in a similar time frame - it might take a week total to build a list of ~500 entities and associated email addresses. Because of employee turn-over the list will need to be updated, ~1-10 old addresses purged and replaced with new ones on a monthly basis. > > Why isn't this being done now? > > > > Issuing reclaimed IPs is a lot like selling a used car, except that > > the buyer has no way to "examine" the state of the IPs you will > > issue them beforehand. Therefore it's up to you (ARIN, RIPE, et. > > al.) to ensure that they are "just as good" as any other IP block. > > It is shoddy business to take someone's money and then sneakily > > give them tainted (used) goods and expect them to deal with > > cleaning up the mess that the prior owner made, especially when you > > charge the same rate for untainted goods! > > Not applicable in this case, as noted above. What do you mean, "not applicable"? You take the money and issue IPs. There is no way for the "buyer" to know before hand if the IPs are "tainted" (used) or new. It is up to you (ARIN) to ensure that the goods (IPs) are suitable for the intended use. My analogy is entirely applicable, and I'm amazed you think otherwise. > So, back to the question: could someone explain why they've got > copies of the RBL's in their network which don't get updated on any > reasonable refresh interval? (weekly? monthly?) The "why" really isn't at issue - it happens and it's going to keep happening. The question is what are you (ARIN) going to do about it? Give me the serenity to accept the things I cannot change, The courage to change the things I can, And the wisdom to know the difference. You (ARIN et. al.) don't have any ability to change the why. What you can change is how you go about determining if an IP block is suitable for reallocation or not, and what steps you take to repair IP blocks that aren't suitable for reallocation. jc - posted to NANOG since John indicated that he thought his reply to me was going to NANOG as well.

13 15

Dedicated Route Reflectors
by Serge Vautour 14 Sep '09

14 Sep '09

Hello, We're in the process of planning for an MPLS network that will use BGP for signaling between PEs. This will be a BGP free Core (i.e. no BGP on the P routers). What are folks doing for iBGP in this case? Full Mesh? Full Mesh the Main POP PEs and Route Reflect to some outlining PEs? Are folks using dedicated/centralized Route Reflectors (redundant of course)? What about using some of the P routers as the Centralized Route Reflectors? The boxes aren't doing much from a Control Plane perspective, why not use them as Route Reflectors. Any comments would be appreciated. Thanks, Serge __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/

5 4

Verizon Wireless (AS22394) network engineering contact needed
by David Ulevitch 14 Sep '09

14 Sep '09

I'm having some trouble reaching a capable network engineer who runs Verizon Wireless (AS22394). The contact on the ARIN address space I have issues with does indeed pick up the phone but is not someone who is aware of what BGP is. Additionally, VZW is not listed on the NOC contacts page hosted by our friend Jared. If someone could put me in touch with a warm body, I'd be much obliged. Thanks, David

2 1

[NANOG-announce] NANOG SC Nominations
by Betty Burke 14 Sep '09

14 Sep '09

Last Call!! SC Candidate nominations close midnight EST 9-14-09 Current Candidates posted at http://nanog.org/governance/elections/2009elections/2009sc_candidates.php Send those additional nominations to nominations(a)nanog.org! Look forward to seeing you in Dearborn, Michigan, October 18-21, 2009 for NANOG47!!! Betty Merit Network Inc. NANOG Community Project Manager NANOG47 Sponsorship opportunities still available, information found at http://nanog.org/meetings/nanog47/sponsorships.php _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Rack Space in Chicago area
by John Palmer 14 Sep '09

14 Sep '09

I may be in need of rack space in the Chicago area - the closer to downtown, the better. I have need for about 24U of space and enough AC for 4 - 2U servers, 3 - 1U servers, 2 hubs and a 3640 router. Would need connectivity (100MB ethernet) and someone that can do a BGP session with us for 3 network blocks. Timeframe would be end of year, early January. Please contact me off-list at this address. Thanks John Palmer American Webmasters, Inc.

1 0

OT: CLEC Mailing List
by Richey 14 Sep '09

14 Sep '09

I am looking for a CLEC related mailing list. I looked through the archives and it looks like ISP-CLEC is dead. Does anyone know of a mailing list that picked up the slack? Richey

4 3

Re: Repeated Blacklisting / IP reputation
by Tom Pipes 14 Sep '09

14 Sep '09

I am amazed with the amount of thoughtful comments I have seen, both on and off list. It really illustrates that people are willing to try to help out, but there is an overall lack of clear direction on how to improve things. Most of us seem to adopt that which has always just worked for us. Don't get me wrong, I'm sure there are a lot of improvements/mods going on with RBL operators in terms of the technology and how they choose who to block. I'm also certain that most of the carriers are doing their best to follow RFCs, use e-mail filtering, and perform deep packet inspection to keep themselves off of the lists. AND there seems to be some technologies that were meant to work, and cause their own sets of problems (example: allowing the end user to choose what is considered spam and blacklisting based on that). As was said before, it's not the "WHY" but rather how can we fix it if it's broke. The large debate seems to revolve around responsibility, or lack thereof. In our case, we are the small operator who sits in the sidelines hoping that someone larger than us, or more influential has an opinion. We participate in lists, hoping to make a difference and contribute, knowing that in a lot of cases, our opinion is just that: an opinion. I suppose that could spark a debate about joining organizations (who shall go nameless here), power to the people, etc. It seems as though a potential solution *may* revolve around ARIN/IANA having the ability to communicate an authoritative list of reassigned IP blocks back to the carriers. This could serve as a signal to remove a block from the RBL, but I'm sure there will be downfalls with doing this as well. In my specific case, I am left with a legacy block that I have to accept is going to be problematic. Simply contacting RBL operators is just not doing the trick. Most of the e-mails include links or at least an error code, but some carriers just seem to be blocking without an error, or even worse, an ACL... We will continue to remove these blocks as necessary, reassign IPs from other blocks where absolutely necessary, and ultimately hope the problem resolves itself over time. Thanks again for the very thoughtful and insightful comments, they are greatly appreciated. Regards, --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes(a)t6mail.com ----- Original Message ----- From: "Tom Pipes" <tom.pipes(a)t6mail.com> To: nanog(a)nanog.org Sent: Tuesday, September 8, 2009 9:57:58 AM GMT -06:00 US/Canada Central Subject: Repeated Blacklisting / IP reputation Greetings, We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This block has been cursed (for lack of a better word) since we obtained it. It seems like every customer we have added has had repeated issues with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, etc). I understand there is a process to getting removed, but it seems as if these IPs had been used and abused by the previous owner. We have done our best to ensure these blocks conform to RFC standards, including the proper use of reverse DNS pointers. I can resolve the issue very easily by moving these customers over to our other direct assigned 66.254.192.0/19 block. In the last year I have done this numerous times and have had no further issues with them. My question: Is there some way to clear the reputation of these blocks up, or start over to prevent the amount of time we are spending with each customer troubleshooting unnecessary RBL and reputation blacklisting? I have used every opportunity to use the automated removal links from the SMTP rejections, and worked with the RBL operators directly. Most of what I get are cynical responses and promises that it will be fixed. If there is any question, we perform inbound and outbound scanning of all e-mail, even though we know that this appears to be something more relating to the block itself. Does anyone have any suggestions as to how we can clear this issue up? Comments on or off list welcome. Thanks, --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes(a)t6mail.com

13 13

Advertising BGP-4 from two islands
by Francois Menard 13 Sep '09

13 Sep '09

I have an opportunity to launch services in a remote marke, where I cannot extend my backbone to. However, this market is big enough that I can afford to put a Cisco 7201 over there and peer in BGP-4. Do you have any advice as to what may happen if I advertise different blocks from the same AS number, from two different locations, one of which I do not have my own transport facilities to... F.

3 2

Re: Advertising BGP-4 from two islands
by Fouant, Stefan 12 Sep '09

12 Sep '09

This is considered a normal and accepted practice, and there are many companies out there that do just this sort of thing. From the perpective of everyone else outside your AS everything will be perfectly fine. The only thing you'll need to be aware of is that your islands will not be able to see each others routes due to AS Path loop prevention mechanisms inherent in BGP, since they will see routes received with your AS in the AS Path and will assume some type of loop is taking place. You can get around this by configuring AS loop support on your routers. My apologies for the top-posting, I'm using my BB. Stefan Fouant Neustar, Inc. / Principal Engineer 46000 Center Oak Plaza Sterling, VA 20166 Office: +1.571.434.5656 ▫ Mobile: +1.202.210.2075 ▫ GPG ID: 0xB5E3803D ▫ stefan.fouant(a)neustar.biz ----- Original Message ----- From: Francois Menard <francois(a)menards.ca> To: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Sat Sep 12 21:35:00 2009 Subject: Advertising BGP-4 from two islands I have an opportunity to launch services in a remote marke, where I cannot extend my backbone to. However, this market is big enough that I can afford to put a Cisco 7201 over there and peer in BGP-4. Do you have any advice as to what may happen if I advertise different blocks from the same AS number, from two different locations, one of which I do not have my own transport facilities to... F.

1 0