Re: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320
* Andy Davidson: OpenBGPd is therefore dropping the sessions when this update is received. Unideal if this attribute is learned on multiple upstreams... The impact today is fairly limited as there are relatively few bgp speakers honouring the 4-byte ASN protocol extension rules, but as code that support these features creeps around the internet, the next time this happens the impact could be much greater, so we need to understand which implementation of which BGP software caused this illegal origination. Uhm, shouldn't you just ignore invalid AS4_PATH attributes, instead of dropping the session? It's a transient, optional attribute, so you can't rely on your peers to filter it. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: _65000_ in as-path - paging 8544, 16229, 37958
On 10 Dec 2008, at 16:20, Patrick W. Gilmore wrote: On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote: Marshall Eubanks wrote: Is there some reason why 65000 is especially problematic ? 65000 and above are private as numbers and should not be seen in the global table. 64512 above. Indeed, the reference is RFC 1930 section 10, which says: 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Joe
Re: Net Mgmt Tools and supporting OS
Hi Vitto, The tools you use depend massively on the kind of network you're building. Things I'd look at would be RANCID, Cricket + genrtrconfig, Cacti, jffnms, mon from kernel.org, Nagios, ZenOSS, OpenNMS and my own NMS, Observer (http://www.observer.org). You'll find lots of help with all of these tools from the mailling lists and forums related to them. Good Luck! adam.
Tools and toys
Vitto, If you want access to NMS tools and tutorials, here is a great resource to delve into, to equip yourself with the appropriate tools Jay Murphy IP Network Specialist NMD of Health ITSD - IP Network Operations We move the information that moves your world. http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html ===Right here. x Hi Vitto, The tools you use depend massively on the kind of network you're building. Things I'd look at would be RANCID, Cricket + genrtrconfig, Cacti, jffnms, mon from kernel.org, Nagios, ZenOSS, OpenNMS and my own NMS, Observer (http://www.observer.org). You'll find lots of help with all of these tools from the mailling lists and forums related to them. Good Luck! adam. Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
Re: Net Mgmt Tools and supporting OS
Adam Armstrong wrote: Things I'd look at would be RANCID, Cricket + genrtrconfig, Cacti, jffnms, mon from kernel.org, Nagios, ZenOSS, OpenNMS and my own NMS, Observer (http://www.observer.org). I may have meant http://www.project-observer.org :) adam.
RE: Net Mgmt Tools and supporting OS
Vitto, If you want access to NMS tools and tutorials, here is a great resource to delve into, to equip yourself with the appropriate tools Jay Murphy IP Network Specialist NMD of Health ITSD - IP Network Operations We move the information that moves your world. http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html ===Right here. -Original Message- From: Scott Berkman [mailto:scott.berk...@reignmaker.net] Sent: Tuesday, December 09, 2008 4:38 PM To: 'vitto malitani'; nanog@nanog.org Subject: RE: Net Mgmt Tools and supporting OS I'd recommend ZenOSS (http://www.zenoss.com) based on your low cost requirement and my own experiences. What Linux distro you use and rather you need to pay for support depends on your level of *nix experience and comfort. Most Linux based software packages like ZenOSS or Groundwork will also tell you what some of their favorite distros are based on how they distribute the software and what guides they have if they don't just come right out and say it. Good Luck, -Scott -Original Message- From: vitto malitani [mailto:vmalit...@gmail.com] Sent: Tuesday, December 09, 2008 12:18 PM To: nanog@nanog.org Subject: Net Mgmt Tools and supporting OS I am fairly new user of nanog mail list so I am not sure if the question below is appropriate for this list. If not, please excuse it. - I am building a new low-budget customer WAN/LAN network and need some ideas for network management tools. I've seen couple of email threads regarding all sort of net goodies. However, since I haven't used them all, I am not sure which OS would be the most appropriate for these aps? Can anyone share their ideas in regards of apps and supporting platforms? I would be most comfortable with free distribution of linux, but I am not sure which distro supports most of the tools? Is the paid OS required for all these tools, like RedHat Server or SuSe or Windows platforms? Thanks much, Vitto __ This inbound email has been scanned by the MessageLabs Email Security System. __ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
Re: Netblock reassigned from Chile to US ISP...
Robert Tarrall wrote: 1) www.google.com is in Spanish Contact Google. 2) Web pages are slow - am assuming this is due to folks like Akamai sending them to content caches in Chile though I haven't tested it myself... God knows web pages are slow isn't particularly specific but I'm assuming an OC-3 with 3 DSL subscribers on it will be reasonably free of congestion and I know the upstream is competent. Again. Akamai is helpful. Contact them. 3) End-user unable to complete an online e-commerce transaction due to a fraud-prevention service thinking he was a Chilean user trying to buy something with a US-based credit card. There's no fast fix for this, but have you talked to MaxMind about chaning the Geo location ? They'll implent it fast and it's in their DB within a week, max 2, but it'll take 2 months at least, before it makes the internet turn-around. I've ranges, that were originally in Denmark, UK and Germany (we're in Ireland) and after half a year and actively submitting data to MaxMind, that actually ok. I've not had the necessity to contact Google or Akamai. However, the ecommerce issue is a bit worse, because there's some of'em out there, like one of the biggest hosters in the states, that have 2 year old data. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968
Re: _65000_ in as-path - paging 8544, 16229, 37958
On Thu, Dec 11, 2008 at 08:44:28AM -0500, Joe Abley wrote: On 10 Dec 2008, at 16:20, Patrick W. Gilmore wrote: On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote: 65000 and above are private as numbers and should not be seen in the global table. 64512 above. Indeed, the reference is RFC 1930 section 10, which says: 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 the recently published RFC5398 sets aside a few more to add to the permanent ASN bogon list. 64496-64511Reserved for use in documentation and sample code 65536-65551 is reserved for same, for those playing in the 32-bit space. -- bill
Re: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320
On Thu, Dec 11, 2008 at 01:28:46PM +0100, bj...@mork.no wrote: No you can't rely on that. But still, RFC4271 doesn't seemt to allow ignoring it. Which must be a bug in the RFC, or my reading of it. Hopefully the latter. Great if someone could correct the interpretation below. IMHO, an optional transitive attribute with the partial bit set should not cause session tear-down, since the attribute is forwarded across one or more routers not handling it and therefore not filtering it. However, RFC4271 does not make such an exception for optional + transitive + partial AFAICS: [. copy/paste deleted .] Which basically means that you can take down every RFC-compliant 4-byte ASN honouring router today by injecting a bogus AS4_PATH attribute into the mostly 2-byte-ASN-only Internet... Or did I miss something? I certainly hope I did. this was brought up in the IETF IDR mailing list today. i've attached the response from that thread that addresses your reading of the RFC. -- bill ---BeginMessage--- Hi Kaliraj, There are well-known correctness problems with simply discarding an UPDATE. This gets discussed on the list every few years, every time some implementation bug crops up which causes a lot of NOTIFICATIONS. To date, the WG has resisted the temptation to compromise the protocol's correctness. You do have a good point that optional transitives are especially problematic; however, the correctness problem still exists if you start dropping UPDATEs, so this would seem to be a case of cutting off the patient's head to cure the flu. Now that you bring it up though, the text from RFC 4271 you quote is kind of bizarre: If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value). Can anyone offer an explanation of what it's supposed to mean that the attribute MUST be discarded given that the section also says that you're going to send a NOTIFICATION and tear down the entire session? Seems as though the clause the attribute MUST be discarded should itself be discarded. --John On Dec 11, 2008, at 9:11 AM, Kaliraj Vairavakkalai wrote: RFC-4271: section 6.3 UPDATE Message Error Handling - Please consider Changing this text: If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value). To: If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the update MUST be discarded, and a warning logged locally containing details like the attribute (type, length, and value), peer-address, as-path (may help in determining the originator of the malformed-attribute) etc. Motivation behind the suggestion: - This suggestion is focused on error-handling of optional transitive attributes recognized by a BGP speaker receiving them. Because any errors in the semantics of the optional-transitive-attribute will be caught by a BGP-speaker which could be far away from the place of origination of the error(as the speaker who don't recognize the opt-trans-attribute will just propagate them to their peers), it may be good idea to be more-lenient in the way the error is handled. i.e. I feel tearing down the BGP session with the immediate neighbor must be avoided. Because this affects the session between two BGP speakers neither of whom are-responsible-for(originated) the malformed-optional-transitive-attribute. ___ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr ---End Message---
Re: Netblock reassigned from Chile to US ISP...
Martin List-Petersen wrote: - Contact Google. Somebody from Google replied off-list. Sounds like Google maybe had this updated even before he looked at it. - Again. Akamai is helpful. Contact them. Somebody from Akamai replied off-list and they're looking into it. - 3) End-user unable to complete an online e-commerce transaction - due to a fraud-prevention service thinking he was a Chilean user - trying to buy something with a US-based credit card. - - There's no fast fix for this, but have you talked to MaxMind about - chaning the Geo location ? They'll implent it fast and it's in their - DB within a week, max 2, but it'll take 2 months at least, before it MaxMind was the first place I checked; they already had the correct info when I looked. IP2Location don't have the right info, but they think it's a Speakeasy.net IP in Washington DC which probably won't be a problem. No idea about Digital Element yet. Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks who pull ARIN assignments regularly will have it. Those who care but don't check ARIN regularly may want to see if they think it's in Chile, and change it to Denver, Colorado if so. - However, the ecommerce issue is a bit worse, because there's some - of'em out there, like one of the biggest hosters in the states, that - have 2 year old data. Yeah, it's those types that I'm hoping to locate as well... Google and Akamai were immediately noticed by the test users, and have also responded very quickly (thanks, guys), but ideally we'd like to be proactive and get as many of these updated *before* the real customers hit the network and start having problems. -Robert.-
Re: Netblock reassigned from Chile to US ISP...
try being illiterate and living in japan :) my gripe is the significant sites that put up the kanji page, offer no language choice, and you got there from the US url. you're trapped. and i can not tunnel out of it via my westin or ashburn racks, as my address blocks are registered to my home address here in japan. sense of humor required. younger brain desired, so i can learn japanese. randy
Re: Netblock reassigned from Chile to US ISP...
On Dec 11, 2008, at 10:44 PM, Robert Tarrall wrote: ... Yeah, it's those types that I'm hoping to locate as well... Google and Akamai were immediately noticed by the test users, and have also responded very quickly (thanks, guys), but ideally we'd like to be proactive and get as many of these updated *before* the real customers hit the network and start having problems. Agreed, and I expect that we're be seeing more dynamic and more granular movement of IPv4 blocks over the next few years. Services that purport to provide useful information about IP block utilization geography had best plan accordingly. /John [my personal view only]
DDOS - How much is too much?
Hi, I have a client who prior to me settled into a non-carrier-neutral facility. They were approached this week for DoS/DDoS protection which they could buy in X Mb/s, 2xX Mb/s or 4xX Mb/s scrubbing solutions. Maybe I've been out of the running my larger Managed Server Hosting Company too long, but wasn't the non-elegant solutions something ISPs just did? Was it only DoS, and when it comes to DDoS they tell you its just too much to handle. And blocking how many netblocks does an ISP consider too many before it tells the client there is only so much it can do for them? Do people tell/give clients their own solutions? (Like Zebra boxes that'll inject BGP into their site) They wanted me to come up with 3 reasons FOR the service, 3 against, and what I felt was a fair market value for this. I just need to know if people still did that type of stuff for each other or if everything costs nowadays Thanks, Tuc/TBOH
