Help Request on Bonn/Germany
Hi anyone know a company in Bonn in Germany capable of working on a customer site to connect a cisco router? Thnkas Olivier
AW: Help Request on Bonn/Germany
How about Cisco? BR Philipp -Ursprüngliche Nachricht- Von: Olivier CALVANO [mailto:o.calv...@gmail.com] Gesendet: Donnerstag, 30. August 2012 11:23 An: NANOG list (nanog@nanog.org) Betreff: Help Request on Bonn/Germany Hi anyone know a company in Bonn in Germany capable of working on a customer site to connect a cisco router? Thnkas Olivier
Re: LSMSGCV: Your message to curtis.star...@granburyisd.org was blocked as spam - please reply to forward it
On Wed, Aug 29, 2012 at 09:33:18PM -0400, William Herrin wrote: The message from Curtis' mailer implies that it's not a blanket challenge. Maybe you just discovered a problem with your mail server that he can help you identify and fix. Perhaps there is or isn't a problem with the sender's mail server, but C/R is *never* the appropriate method for dealing with such: it's an inherently abusive, spamming approach that was thoroughly discredited a decade ago and should never be used. ---rsk
Regarding smaller prefix for hijack protection
Hello everyone! I tried looking on net but couldn't found direct answer, so thought to ask here for some advise. Is using /24 a must to protect (a bit) against route hijacking? We all remember case of YouTube 2008 and hijacking in Pakistan. At that time YouTube was using /22 and thus /24 (more specific) announcement took almost all of Google's traffic even when AS path was long. So Google's direct also likely sent packets to Pakistan. Later Google too used /24 (and I guess /25 too to effect some region of internet). Similar case I remember for issue reported between Altus and hijacking by someone connected to Cleaveland exchange when ISP was using /23 and spammer used /24. So can we conclude that one should always use /24 to make sure that they loose as little as possible traffic during prefix hijacking? Also, if one uses /22 and /24 - will both prefixes will show in Global routing table? I know /24 will be prefered but will ISP see /22 as well or it will pop up only when /24 is filtered? For one of IP's of Google.com, it seems it is coming from /16 and /24 http://bgp.he.net/ip/74.125.224.137 How can one print similar result from a route server like say Oregon route views or any ISP's server? I always /24 when looking for that IP. (in simple words - how bgp.he.net does this magic of popping both prefixes? I failed to do get same result from HE's route server) Thanks! -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+ https://plus.google.com/118280168625121532854
Re: Regarding smaller prefix for hijack protection
You might find your /24 routes filtered out at a lot of places that do have sensible route filtering But then yes, it'd protect you against the idiots who dont know bgp from a hole in the ground anyway and let whatever hijacking happen But I'd suggest do whatever such announcement if and only if you see a hijack, as a mitigation measure. On Thu, Aug 30, 2012 at 5:24 PM, Anurag Bhatia m...@anuragbhatia.com wrote: Hello everyone! I tried looking on net but couldn't found direct answer, so thought to ask here for some advise. Is using /24 a must to protect (a bit) against route hijacking? We all remember case of YouTube 2008 and hijacking in Pakistan. At that time YouTube was using /22 and thus /24 (more specific) announcement took almost all of Google's traffic even when AS path was long. So Google's direct also likely sent packets to Pakistan. Later Google too used /24 (and I guess /25 too to effect some region of internet). Similar case I remember for issue reported between Altus and hijacking by someone connected to Cleaveland exchange when ISP was using /23 and spammer used /24. So can we conclude that one should always use /24 to make sure that they loose as little as possible traffic during prefix hijacking? Also, if one uses /22 and /24 - will both prefixes will show in Global routing table? I know /24 will be prefered but will ISP see /22 as well or it will pop up only when /24 is filtered? For one of IP's of Google.com, it seems it is coming from /16 and /24 http://bgp.he.net/ip/74.125.224.137 How can one print similar result from a route server like say Oregon route views or any ISP's server? I always /24 when looking for that IP. (in simple words - how bgp.he.net does this magic of popping both prefixes? I failed to do get same result from HE's route server) Thanks! -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+ https://plus.google.com/118280168625121532854 -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Regarding smaller prefix for hijack protection
On Thu, 30 Aug 2012, Anurag Bhatia wrote: I tried looking on net but couldn't found direct answer, so thought to ask here for some advise. Is using /24 a must to protect (a bit) against route hijacking? We all remember case of YouTube 2008 and hijacking in Pakistan. At that time YouTube was using /22 and thus /24 (more specific) announcement took almost all of Google's traffic even when AS path was long. So Google's direct also likely sent packets to Pakistan. Later Google too used /24 (and I guess /25 too to effect some region of internet). Similar case I remember for issue reported between Altus and hijacking by someone connected to Cleaveland exchange when ISP was using /23 and spammer used /24. So can we conclude that one should always use /24 to make sure that they loose as little as possible traffic during prefix hijacking? As an exercise, grab a copy of the global routing table, convert all shorter than /24 networks into /24s and tell us, how big is your hijack-resistant global table now? How many networks will be unable to handle it because it overflows their routers route table capacity? In short, no...you/everyone should not announce all their space as /24s just in case someone tries to or accidentally hijacks some of their space. Your solution does not scale. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: LSMSGCV: Your message to curtis.star...@granburyisd.org was blocked as spam - please reply to forward it
On Thu, Aug 30, 2012 at 6:24 AM, Rich Kulawiec r...@gsp.org wrote: On Wed, Aug 29, 2012 at 09:33:18PM -0400, William Herrin wrote: The message from Curtis' mailer implies that it's not a blanket challenge. Maybe you just discovered a problem with your mail server that he can help you identify and fix. Perhaps there is or isn't a problem with the sender's mail server, but C/R is *never* the appropriate method for dealing with such: it's an inherently abusive, spamming approach that was thoroughly discredited a decade ago and should never be used. Rich, Auto-response (including vacation messages and spam challenges) is the pro-life/pro-choice debate of the email community. Pretty much everybody agrees that when they respond to list traffic they're doing the wrong thing. Beyond that the level of agreement drops off quickly. A minority hold the belief that autoresponse is always wrong and last I checked the RFCs still say that a message indicating undeliverability should be sent when a mailer can't deliver a message. At any rate, it's about as thoroughly discredited as the pro-choice movement. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
mac limit per VPLS domain
I'm wondering what would be the sane default MAC limit per VPLS domain as well as per port assuming the RSP can hold up to 512K MAC addresses please? I believe the answer would partly depend on the business model (like I can start with 2 MACs per port and 50 per domain and have customers to pay extra for additional MACs) as well as expected number of VPLS customers/domains Thank you
Re: mac limit per VPLS domain
Hi Adam, I think you're correct -- it depends on the business model. If your customers CE devices will be routers you can make the maximum number of macs correspondingly small, and if they will be switches, you'll have to determine what makes sense for each interface and domain. I think it is a great idea to have limits of some kind on both interfaces and domains, to avoid problems with misbehaving hardware or software bugs. HTHs, Dave On Aug 30, 2012, at 9:09 AM, Adam Vitkovsky wrote: I'm wondering what would be the sane default MAC limit per VPLS domain as well as per port assuming the RSP can hold up to 512K MAC addresses please? I believe the answer would partly depend on the business model (like I can start with 2 MACs per port and 50 per domain and have customers to pay extra for additional MACs) as well as expected number of VPLS customers/domains Thank you
Re: Regarding smaller prefix for hijack protection
Or better. Sign your prefixes and create ROAs to monitor any suspicious activity. There is an app for that: http://bgpmon.net Besides the normal service you can use also RPKI data to trigger alarms of possible hijacks http://www.labs.lacnic.net/rpkitools/looking_glass/ You can query periodically with a simple curl/wget to see if your prefix is valid or invalid (possibly hijacked), e.g. http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.7.84.0/23 Polluting the routing table to protect against hijacks should be the last option and against an attack that is happening, and not for just in case. Regards, /as On 30 Aug 2012, at 08:00, Suresh Ramasubramanian wrote: You might find your /24 routes filtered out at a lot of places that do have sensible route filtering But then yes, it'd protect you against the idiots who dont know bgp from a hole in the ground anyway and let whatever hijacking happen But I'd suggest do whatever such announcement if and only if you see a hijack, as a mitigation measure.
Graphing IPv6 traffic
Hi guys, Trying to generate graphs for ipv6 traffic going through an exchange point. Anyone got ideas? Thanks Sent from my iPad
Re: Regarding smaller prefix for hijack protection
On Thu, Aug 30, 2012 at 7:54 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Is using /24 a must to protect (a bit) against route hijacking? Hi Anurag, Not only is it _not_ a must, it doesn't work and it impairs your ability to detect the fault. In a route hijacking scenario, traffic for a particular prefix will flow to the site with the shortest AS path from the origin. Your /24 competes with their /24. Half the Internet, maybe more maybe less depending on how well connected each of you are, will be inaccessible to you. The fault presents as a partial outage: you can get to everything nearby but the further away the customer is, the worse chance he has of reaching you. Since there are lots of partial outages on the Internet and BGP hijacks are rare, your customer support team won't take the first couple calls seriously. I can reach it from our test ISP so the problem must lie with your ISP. Sorry. On the flip side, if you announce a covering route and someone hijacks with a /24, all traffic follows the most specific route: the hijacker. You detect this condition pretty much immediately, at which point you can collide him with a /24 announcement while contacting him and his peers to get the offending announcement killed. Also, if one uses /22 and /24 - will both prefixes will show in Global routing table? I know /24 will be prefered but will ISP see /22 as well or it will pop up only when /24 is filtered? Unless one of the transit providers is behaving badly or you use BGP communities to explicitly limit propagation of the announcement, all routers in the default-free zone (DFZ, aka Internet core) will see both the /22 and the /24 in their routing information base (RIB). When this is processed into the forwarding information base (FIB) only one next hop will be selected - the one from the /24. A number of very smart people have sought an algorithm to allow intermediate nodes to aggregate the /24 into the /22 without damaging the network (black holes). No such algorithm has been identified. As near as anyone can figure, only the source of the announcement can safely aggregate it. On the other hand, if you announce, say, the /24 via multiple ISPs most routers will only see the path to one of them (the closest one) at any given time. When a router reannounces the path to you via BGP to its peers, it only offers the path it selected as best for that particular prefix. A fair bit of traffic engineering is based on announcing a covering route to everybody (the /22 in your example) and then announcing a more specific (the /24) to a particular ISP peer with a set community strings attached that tells the ISP to only propagate the route to specific peers. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Graphing IPv6 traffic
Hello Joseph, If you have sFlow capable devices, you can generate ipv6 graphs. Take a Look at this: http://www.jasinska.de/talks/0610_sf...@euroix9.pdf Regards, Pablo Em 30-08-2012 08:41, Joseph Muga escreveu: Hi guys, Trying to generate graphs for ipv6 traffic going through an exchange point. Anyone got ideas? Thanks Sent from my iPad -- Pablo Costa pa...@nic.br +55 11 5509-3537 R 4063 +55 11 9449-6700 INOC-DBA: 22548*PAB NIC.br - http://nic.br/
Re: Regarding smaller prefix for hijack protection
On 30/08/12 12:54, Anurag Bhatia wrote: Is using /24 a must to protect (a bit) against route hijacking? Announcing your, say /19 as 32 /24s does not prevent someone from trying to hijack you, you will still get some disruption if someone tries, but you might limit the scope of their success or the scope of your perceived outage (which is why temporary shorter prefixes are announced in order to limit the effects of hijacks, including in the example you cited.) Far more useful to monitor and take evasive action in the event of a hijack. So can we conclude that one should always use /24 to make sure that they loose as little as possible traffic during prefix hijacking? There is not room for 4bn entries in the routing table. You deserved to be filtered off the net if you try this stunt ! Andy
Re: Graphing IPv6 traffic
Hi Joseph, There was a presentation on exactly this topic at AfPIF3 last week by Martin Levy of Hurricane Electric. See http://www.youtube.com/watch?v=UpuXcQpfrisfeature=sharelist=PLA8857C20BB1E1F83 and slides http://www.internetsociety.org/sites/default/files/images/AfPIF3_2012_IP_Flows_Martin_Levy_Hurricane%20Electric.pdf HTH joly On Thu, Aug 30, 2012 at 7:41 AM, Joseph Muga jpm...@tespok.co.ke wrote: Hi guys, Trying to generate graphs for ipv6 traffic going through an exchange point. Anyone got ideas? Thanks Sent from my iPad -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Level 3 BGP Advertisements
Matt Addison wrote the following on 8/29/2012 6:08 PM: Sent from my mobile device, so please excuse any horrible misspellings. On Aug 29, 2012, at 18:30, james machado hvgeekwt...@gmail.com wrote: On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS curtis.star...@granburyisd.org wrote: Sorry for the top post... Not necessarily a Level 3 problem but; We are announcing our /19 network as one block via BGP through ATT, not broken up into smaller announcements. Earlier in the year I started receiving complaints that some of our client systems were having problems connecting to different web sites. After much troubleshooting I noticed that in every instance the xlate in our Cisco ASA for the client's IP last octet was either a 0 or 255. Since I am announcing our network as a /19, the subnet mask is 255.255.224.0, that would make our network address x.x.192.0 and the broadcast x.x.223.255. So somewhere the /24 boundary addresses were being dropped. Just curious if anyone else has seen this before. some OS's by M and others as well as some devices have IP stacks which will not send or receive unicast packets ending in 0 or 255. have had casses where someone was doing subnets that included those in the DCHP scopes and the computers that received these addresses were black holes. james MSKB 281579 affects XP home and below. Good times anytime someone adds a .0 or .255 into an IP pool. It might be relevant to note that XP and below is simply respecting classful boundaries. This does not affect all .0 or .255 address, just class C addresses (192.0.0.0 through 223.255.255.255) that end with .0 or .255. If your IP range is 0.0.0.0 - 191.255.255.255 you are not affected (by this particular bug) by using .0 or .255 as the last octet unless the address is ALSO the last octet of the classful boundary for your subnet. In effect, these OS's simply enforce classful boundaries regardless of the subnet mask you have set. As the KB states, this bug affects supernets only. I'm not trying to defend MS (they can do that themselves), but your statement was misleading. We do, sometimes, use .0 and .255 addresses. Most clients work fine with them (including XP). However, I have personally seen a few networks where an administrator had blocked .0 and .255 addresses, causing problems for people on his network communicating to hosts that ended in .0 or .255. It has been years since I have seen an issue with a .0 or a .255 IP however. Given fears over IP shortages, even a couple percent of addresses wasted due to subnetting can be cause for adjusting network policy. I would not be surprised if folks who excluded .0 and .255 addresses from their assignable pools will re-evaluate that decision over the next few years. --Blake
Re: Level 3 BGP Advertisements
On Thu, Aug 30, 2012 at 11:50 AM, Blake Hudson bl...@ispn.net wrote: Matt Addison wrote the following on 8/29/2012 6:08 PM: Sent from my mobile device, so please excuse any horrible misspellings. On Aug 29, 2012, at 18:30, james machado hvgeekwt...@gmail.com wrote: On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS curtis.star...@granburyisd.org wrote: Sorry for the top post... Not necessarily a Level 3 problem but; We are announcing our /19 network as one block via BGP through ATT, not broken up into smaller announcements. Earlier in the year I started receiving complaints that some of our client systems were having problems connecting to different web sites. After much troubleshooting I noticed that in every instance the xlate in our Cisco ASA for the client's IP last octet was either a 0 or 255. Since I am announcing our network as a /19, the subnet mask is 255.255.224.0, that would make our network address x.x.192.0 and the broadcast x.x.223.255. So somewhere the /24 boundary addresses were being dropped. Just curious if anyone else has seen this before. some OS's by M and others as well as some devices have IP stacks which will not send or receive unicast packets ending in 0 or 255. have had casses where someone was doing subnets that included those in the DCHP scopes and the computers that received these addresses were black holes. james MSKB 281579 affects XP home and below. Good times anytime someone adds a .0 or .255 into an IP pool. It might be relevant to note that XP and below is simply respecting classful boundaries. This does not affect all .0 or .255 address, just class C addresses (192.0.0.0 through 223.255.255.255) that end with .0 or .255. If your IP range is 0.0.0.0 - 191.255.255.255 you are not affected (by this particular bug) by using .0 or .255 as the last octet unless the address is ALSO the last octet of the classful boundary for your subnet. In effect, these OS's simply enforce classful boundaries regardless of the subnet mask you have set. As the KB states, this bug affects supernets only. I'm not trying to defend MS (they can do that themselves), but your statement was misleading. I can distinctly remember having the issue in 10/8 address space with Win2k and WinXP We do, sometimes, use .0 and .255 addresses. Most clients work fine with them (including XP). However, I have personally seen a few networks where an administrator had blocked .0 and .255 addresses, causing problems for people on his network communicating to hosts that ended in .0 or .255. It has been years since I have seen an issue with a .0 or a .255 IP however. Given fears over IP shortages, even a couple percent of addresses wasted due to subnetting can be cause for adjusting network policy. I would not be surprised if folks who excluded .0 and .255 addresses from their assignable pools will re-evaluate that decision over the next few years. --Blake
RE: Level 3 BGP Advertisements
I remember it too... I had a ticket get escalated from our support group in about 2003 of a customer who could not get any internet access... they had XP and had been assigned a .0 IP out of a /23 we were using for a specific pop. That /23 came out of 64.0.0.0/8 so it was clearly a bit more blanket than a class based filter. They may have had some third party firewall software on their machine, I can't remember, but I know my solution was to be a bit disgusted and then exclude .255 and .0 from the pool. John
Re: Level 3 BGP Advertisements
On Thu, 30 Aug 2012, Blake Hudson wrote: these OS's simply enforce classful boundaries regardless of the subnet mask you have set. As the KB states, this bug affects supernets only. I'm not trying to defend MS (they can do that themselves), but your statement was misleading. Just for kicks, I tried using a .0.0/16 and .255.255/16 adress for stuff in IOS (configured it as loopback and tried to establish bgp sessions etc), that didn't work so well. I don't remember exactly what the problem was, but I did indeed run into problems. -- Mikael Abrahamssonemail: swm...@swm.pp.se
XO outage in NJ/NY?
Anyone heard anything about an XO fiber cut in northeast? We have had a bunch of issues with some DID's in NJ today and one of our carriers forwarded a a vague statement from XO: *XO Communications is currently experiencing a fiber-cut which is causing a service interruption for some markets in the east coast region. Users may experience DID failures for numbers in NY, NJ and other surrounding areas. They are working on fixing the issue but unfortunately have not provided an ETA at this time* Just curious how widespread the effect is and if anyone knows anything more about it thanks chris
Re: XO outage in NJ/NY?
I suggest subscribing to outages. They are chatting about such a fiber cut, and are generally the place to look for major outage level events like the below. -Blake On Thu, Aug 30, 2012 at 3:10 PM, chris tknch...@gmail.com wrote: Anyone heard anything about an XO fiber cut in northeast? We have had a bunch of issues with some DID's in NJ today and one of our carriers forwarded a a vague statement from XO: *XO Communications is currently experiencing a fiber-cut which is causing a service interruption for some markets in the east coast region. Users may experience DID failures for numbers in NY, NJ and other surrounding areas. They are working on fixing the issue but unfortunately have not provided an ETA at this time* Just curious how widespread the effect is and if anyone knows anything more about it thanks chris
Re: XO outage in NJ/NY?
For anyone not already familiar, go sign up at: https://puck.nether.net/mailman/listinfo/outages On Thu, Aug 30, 2012 at 1:13 PM, Blake Dunlap iki...@gmail.com wrote: I suggest subscribing to outages. They are chatting about such a fiber cut, and are generally the place to look for major outage level events like the below. -Blake On Thu, Aug 30, 2012 at 3:10 PM, chris tknch...@gmail.com wrote: Anyone heard anything about an XO fiber cut in northeast? We have had a bunch of issues with some DID's in NJ today and one of our carriers forwarded a a vague statement from XO: *XO Communications is currently experiencing a fiber-cut which is causing a service interruption for some markets in the east coast region. Users may experience DID failures for numbers in NY, NJ and other surrounding areas. They are working on fixing the issue but unfortunately have not provided an ETA at this time* Just curious how widespread the effect is and if anyone knows anything more about it thanks chris -- -george william herbert george.herb...@gmail.com
Re: XO outage in NJ/NY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/30/2012 01:10 PM, chris wrote: Anyone heard anything about an XO fiber cut in northeast? We have had a bunch of issues with some DID's in NJ today and one of our carriers forwarded a a vague statement from XO: *XO Communications is currently experiencing a fiber-cut which is causing a service interruption for some markets in the east coast region. Users may experience DID failures for numbers in NY, NJ and other surrounding areas. They are working on fixing the issue but unfortunately have not provided an ETA at this time* Just curious how widespread the effect is and if anyone knows anything more about it thanks chris - http://tracker.outages.org/reports/view/29 regards, /virendra -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlA/0kEACgkQ3HuimOHfh+FNNgD+K2UBkKIr14f5moV/8W5J47f/ yuESX7szffFFb6pqa6AA/30kMggu1MEvxkOsfW7ebbf5SzmCItZqUx+I9AZpd1ME =WF+9 -END PGP SIGNATURE-
Re: Regarding smaller prefix for hijack protection
On Thu, Aug 30, 2012 at 8:41 AM, William Herrin b...@herrin.us wrote: On Thu, Aug 30, 2012 at 7:54 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Is using /24 a must to protect (a bit) against route hijacking? Hi Anurag, Not only is it _not_ a must, it doesn't work and it impairs your ability to detect the fault. In a route hijacking scenario, traffic for a particular prefix will flow to the site with the shortest AS path from the origin. Your /24 competes with their /24. Half the Internet, maybe more maybe less depending on how well connected each of you are, will be inaccessible to you. Preventively there seems to be no utility to this. Reactively, after a hijacking starts, has anyone tried announcing both (say) /24s for the block and (say) 2x /25s for it as well, to get more-specific under the hijacker? Yes, a lot of places will filter and ignore, but those that don't ... (Yes, sign your prefixes now, on general principles) -- -george william herbert george.herb...@gmail.com
