The BGP Visibility Scanner
Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs: *http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here: *http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra
RE: Variety, On The Media, don't understand the Internet
On May 14, 2013, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: But when traffic from a cahe server flows directly into an ISP's intranet to end users, it doesn't really make use of the Internet nor does it cost the ISP transit capacity. Compare this to a small ISP in a city where there are no cache servers. Reaching netfix involves using paid transit to reach the nearest point where Netflix has a cache server. So traffic truly travels on the internet. We're a small ISP and we reach lot of content via peering just fine. Lot of these contents that you speak of (Netflix, Akamai, et al) have open peering policies and are present in more exchange points than anybody else. james
Re: The BGP Visibility Scanner
Pretty nice. Thanks! I don't suppose there is any straight text version of all this info is there ? -- Jason Hellenthal IST Services Professional Inbox: jhellent...@dataix.net JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu andra.l...@imdea.org wrote: Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs: *http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here: *http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra
Re: Variety, On The Media, don't understand the Internet
On Tue, May 14, 2013 at 09:14:56PM -0400, Jean-Francois Mezei wrote: On 13-05-14 20:55, Patrick W. Gilmore wrote: Since when is peering not part of the Internet? Yes, one car argue that an device with an IP address routable from the internet is part of the internet. But when traffic from a cahe server flows directly into an ISP's intranet to end users, it doesn't really make use of the Internet nor does it cost the ISP transit capacity. So it's only on the Internet if it uses a provider's transit capacity? So if ISP1 and ISP2 are customers of ISP3 (and ISP3 is the only provider-to-provider connection for ISP1 and ISP2), then traffic between a customer of ISP1 and a customer of ISP2 is on the Internet? What if ISP1 and ISP2 then setup a private peering connection? Is traffic between ISP1 and ISP2 still on the Internet, or is that reserved for traffic over paid transit? And if that's still on the Internet, what happens if ISP1 then buys IPS2? Does the traffic between them cease to be on the Internet now that it's the same company? And, if you define on the Internet to mean goes over paid transit, then the only traffic that is on the Internet is traffic to ISPs who have paid transit. Traffic between end customers of two Tier 1 providers (defined as providers who don't pay for any transit for the purposes of this message) would never be on the Internet? (I assume transit, if that's your threshold, is transit paid for by a provider. End user connections are essentially paid transit, even though it's not typically called that, especially at the lower end.) The point is: I don't think you definition works. Could post exactly what your definition of on the Internet is (as opposed to just enumerating examples of things you think are on the internet and things you think are not on the Internet)? -- Brett
CDN server log
Hi, Anyone knows of any public CDN server log trace. I am looking for object popularity, hit rate information, ... Thanks, Djamel
Re: The BGP Visibility Scanner
Hi Jason, Thank you for your email! We are glad to hear that you like the work! At the moment, you can only query the webpage and retrieve the LVPs per origin AS. We haven't yet considered giving the option of downloading the complete report. We are now working on a new version of the tool, and we will try to integrate your suggestion, thank you! If you have any other suggestions or requests, don't hesitate to let us know! Best regards, Andra On 05/15/2013 03:00 PM, Jason Hellenthal wrote: Pretty nice. Thanks! I don't suppose there is any straight text version of all this info is there ? /-- / /*Jason Hellenthal*/ IST Services Professional Inbox: /jhellent...@dataix.net mailto:jhellent...@dataix.net/ JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu andra.l...@imdea.org mailto:andra.l...@imdea.org wrote: Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs: *http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here: *http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra
Re: The BGP Visibility Scanner
On 5/15/13 3:00 PM, Jason Hellenthal wrote: Pretty nice. Thanks! I don't suppose there is any straight text version of all this info is there ? At the RIPE NCC we are publishing aggregated dumps from our collective of 12 RIS route collectors every 8 hours. For each prefix we list the origin AS and the number of peers (on all collectors) which observe the prefix. If you are happy to do your own post-processing, set your own boundaries on what to consider limited visibility prefixes, have a look at the IPv4 and IPv6 table dumps at http://www.ris.ripe.net/dumps/ Note that the fact that not all RIS peers give us a full BGP table blurs the counts somewhat. Prefixes which are globally visible may (today) have anywhere between 96 and 110 peers announcing the prefix to the RIS route collectors. -- Rene -- Jason Hellenthal IST Services Professional Inbox: jhellent...@dataix.net JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu andra.l...@imdea.org wrote: Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs:*http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here:*http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here:https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra
Re: The BGP Visibility Scanner
Awesome! Thank you to you as well! -- Jason Hellenthal IST Services Professional Inbox: jhellent...@dataix.net JJH48-ARIN On May 15, 2013, at 11:01, Rene Wilhelm wilh...@ripe.net wrote: On 5/15/13 3:00 PM, Jason Hellenthal wrote: Pretty nice. Thanks! I don't suppose there is any straight text version of all this info is there ? At the RIPE NCC we are publishing aggregated dumps from our collective of 12 RIS route collectors every 8 hours. For each prefix we list the origin AS and the number of peers (on all collectors) which observe the prefix. If you are happy to do your own post-processing, set your own boundaries on what to consider limited visibility prefixes, have a look at the IPv4 and IPv6 table dumps at http://www.ris.ripe.net/dumps/ Note that the fact that not all RIS peers give us a full BGP table blurs the counts somewhat. Prefixes which are globally visible may (today) have anywhere between 96 and 110 peers announcing the prefix to the RIS route collectors. -- Rene -- Jason Hellenthal IST Services Professional Inbox: jhellent...@dataix.net JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu andra.l...@imdea.org wrote: Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs:*http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here:*http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here:https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra
Borrow request (Chicago): Cat 4900M copper interface(s)
Hello all, I'll spare you the details, but we are in need of some means to temporarily get a copper interface on at least one of our 4900M switches to narrow down a network performance issue. Does anyone have a 4900M half card with copper ports, or a Cisco TwinGig X2 adapter in the Chicago area? We would love to borrow one or two for a few days until we can locate and resolve this issue. Ryan
Re: ISIS and OSPF together
On Sun, May 12, 2013 at 6:41 PM, Glen Kent glen.k...@gmail.com wrote: I would like to understand the scenarios wherein the service provider/network admin might run both ISIS and OSPF together inside their network. Is this something that really happens out there? One scenario that i can think of when somebody might run the 2 protocols ISIS and OSPF together for a brief period is when the admin is migrating from one IGP to the other. The other instance would be when say OSPF is used to manage the OOB network and the ISIS is used for network reachability. Is there any other scenario? There is still equipment around which doesn't support ISIS but support OSPF. Getting such boxes into a network which is using ISIS might lead to running both protocols together. -- SY, Jen Linkova aka Furry
Re: Variety, On The Media, don't understand the Internet
On 13-05-15 06:24, ja...@towardex.com wrote: We're a small ISP and we reach lot of content via peering just fine. Lot of these contents that you speak of (Netflix, Akamai, et al) have open peering policies and are present in more exchange points than anybody else. Not all ISPs are fortunate enough to be in a town where there is an active exchange with Netflix/Akamai/Google presence. For instance, Montréal just recently oopened a peering exchange. While this will eventually allow local ISPs to peer with the big content providers, until this happens, small ISPs have to get that content via paid transit links. Toronto has local content available via peering so smaller ISPs can benefit from that. But not every city has that chance. Netflix's policy does require a minimum amount of traffic before an ISP can deploy an Open Connect appliance. So smaller ISPs are at a disadvantage if they are located in a city without CDN presence.
Re: Variety, On The Media, don't understand the Internet
On Wed, May 15, 2013 at 11:46 AM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: On 13-05-15 06:24, ja...@towardex.com wrote: We're a small ISP and we reach lot of content via peering just fine. Lot of these contents that you speak of (Netflix, Akamai, et al) have open peering policies and are present in more exchange points than anybody else. Not all ISPs are fortunate enough to be in a town where there is an active exchange with Netflix/Akamai/Google presence. For instance, Montréal just recently oopened a peering exchange. While this will eventually allow local ISPs to peer with the big content providers, until this happens, small ISPs have to get that content via paid transit links. or via some cooperative arrangement with another IX participant, no? Toronto has local content available via peering so smaller ISPs can benefit from that. But not every city has that chance. Netflix's policy does require a minimum amount of traffic before an ISP can deploy an Open Connect appliance. So smaller ISPs are at a disadvantage if they are located in a city without CDN presence.
Re: Variety, On The Media, don't understand the Internet
On 13-05-15 09:02, Brett Frankenberger wrote: So it's only on the Internet if it uses a provider's transit capacity? I made the statement in a context of the internet is crumbling under the Netflix load. There have been many media reports over the years of the internet unable to cope with the explosion of traffic. When a content provider delivers content at an ISP's doorstep, it basically bypasses the internet (the big cloud). I am fully aware that it is still technically the internet. But the load is not on the internet but rathers localised to particular individual networks within the internet. The point here is that the internet (as a whole) has adapted to the likes of Netflix and Youtube who are able to deliver huge amounts of data without the internet crumbling.
Re: Variety, On The Media, don't understand the Internet
On Wed, May 15, 2013 at 12:59 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: On 13-05-15 09:02, Brett Frankenberger wrote: So it's only on the Internet if it uses a provider's transit capacity? I made the statement in a context of the internet is crumbling under the Netflix load. There have been many media reports over the years of is it? it seems ok so far... the internet unable to cope with the explosion of traffic. 'internet doom, news at 11' ? i don't think there's as much of a problem as news folk want us all to believe. I also bet that as problems arise, folk route around them with better/closer/cheaper peering, no?
Re: Variety, On The Media, don't understand the Internet
On Wed, 15 May 2013 11:46:36 -0400, Jean-Francois Mezei said: Not all ISPs are fortunate enough to be in a town where there is an active exchange with Netflix/Akamai/Google presence. For instance, Montréal just recently oopened a peering exchange. While this will eventually allow local ISPs to peer with the big content providers, until this happens, small ISPs have to get that content via paid transit links. AS1312 isn't particularly large (2 /16s, 30K students, 8K fac/staff), and Akamai was more than willing to drop a cache unit in our machine room. And Google was happy to meet us at the upstream end of our link to the outside world - but I half-suspect that was just because we make their IPv6 stats look good :) pgpM7hKTqpYzr.pgp Description: PGP signature
RE: Variety, On The Media, don't understand the Internet
Not all ISPs are fortunate enough to be in a town where there is an active exchange with Netflix/Akamai/Google presence. For instance, Montréal just recently oopened a peering exchange. While this will eventually allow local ISPs to peer with the big content providers, until this happens, small ISPs have to get that content via paid transit links. lolwut? Montreal isn't a small town, just not developed on peering side. What's the cost of upgrading your IP transit in Montreal or getting a 10G wave to Toronto for peering w/ content nowadays? Not very much. james
RE: Looking for Netflow analysis package
I'd also suggest looking at NetFlow Auditor: http://www.netflowauditor.com/ I think it will do all of those except AS path analysis. Another good option might also be the InterNAP FCP, which does all of that PLUS optimizes routing based on the data (can also be deployed in a preview mode): http://www.internap.com/business-internet-connectivity-services/route-optimi zation-flow-control/ Good luck, -Scott -Original Message- From: Erik Sundberg [mailto:esundb...@nitelusa.com] Sent: Tuesday, May 14, 2013 7:00 PM To: nanog@nanog.org Subject: Looking for Netflow analysis package Does anyone know of a netflow collector that will do the following. *Graph/List Destination Networks By Top AS *Graph/List Destination Networks By Top IP Address *AS Path Analysis *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) We will be using this to help us decide who to Peer with and what transit Providers to look at. I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy. I also found AS-Stats https://neon1.net/as-stats/ look promising from the power point on their page. Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: Variety, On The Media, don't understand the Internet
On May 15, 2013, at 09:59 , Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: On 13-05-15 09:02, Brett Frankenberger wrote: So it's only on the Internet if it uses a provider's transit capacity? All of this is leading me to the following conclusion: If we, as network engineers can't agree on the nature and definition of the internet, how can we possibly expect the media to understand it? Owen
Re: Looking for Netflow analysis package
I can vouch for the FCP. I haven't used their newer platforms but the device worked very well. On Wed, May 15, 2013 at 10:50 AM, Scott Berkman sc...@sberkman.net wrote: I'd also suggest looking at NetFlow Auditor: http://www.netflowauditor.com/ I think it will do all of those except AS path analysis. Another good option might also be the InterNAP FCP, which does all of that PLUS optimizes routing based on the data (can also be deployed in a preview mode): http://www.internap.com/business-internet-connectivity-services/route-optimi zation-flow-control/ Good luck, -Scott -Original Message- From: Erik Sundberg [mailto:esundb...@nitelusa.com] Sent: Tuesday, May 14, 2013 7:00 PM To: nanog@nanog.org Subject: Looking for Netflow analysis package Does anyone know of a netflow collector that will do the following. *Graph/List Destination Networks By Top AS *Graph/List Destination Networks By Top IP Address *AS Path Analysis *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) We will be using this to help us decide who to Peer with and what transit Providers to look at. I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy. I also found AS-Stats https://neon1.net/as-stats/ look promising from the power point on their page. Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: Variety, On The Media, don't understand the Internet
On 13-05-15 14:07, Owen DeLong wrote: If we, as network engineers can't agree on the nature and definition of the internet, how can we possibly expect the media to understand it? When someone cuts a cable in the meditarenean, the media doesn't say the internet has crawled to a snail's pace, it says internet connections in the middle east are very slow. If DNS servers at Comcast fail, one doesn't say the internet has suffered a failure. Generally , if one uses the expression the internet, it would generally mean the generic term which encompasses the whole internet. So you can state Syria is disconnected from the internet. If root servers went down around the world, then one could state that the internet has suffered a failure.
Spamcop Blacklist
Anyone- We are having a bit of trouble with spamcop blocking 2 of our MTAs with IPs of 208.65.145.71 and 208.65.145.66. We have yet to receive any samples of the spam and do not seem to be able to submit for removal as it appears someone has attempted to do this for us and basically used up all our our requests for a period of time. Does anyone have a contact over at spamcop that might be able to assist us in removing these MTAs before this becomes a large issue or us and our customers? Below is the Bounce message we are receiving. Bounce message 554 Service unavailable; Client host [pXXcXXoXXX.mxlogic.net] blocked by bl.spamcop.net Just to let everyone know, we do vigorously monitor outbound spam traffic and take seriously any reports of spam from our network. If someone can get us a sample of what spamcop is see this would also help! Any help is greatly appreciated. Thanks, -- Clinton Popovich Linux Systems Administrator McAfee 9781 S. Meridian Blvd., Suite 400, Englewood, CO 80112 USA
Re: Spamcop Blacklist
This is probably much more appropriate over on mailop; please see: http://chilli.nosignal.org/mailman/listinfo/mailop I don't recall offhand is any Spamcop personnel hang out there, but it's plausible to think they might. ---rsk
Re: ISIS and OSPF together
Sent from my iPhone On May 12, 2013, at 1:41 AM, Glen Kent glen.k...@gmail.com wrote: The other instance would be when say OSPF is used to manage the OOB network and the ISIS is used for network reachability. Is there any other scenario? Yes, in virtualization world , where people no more want to waste their links that form loops, there are scenarios where you may have a TRILL deployment that runs over IS-IS while you have OSPF running side by side. -Jay
Re: Network Engineering Stack Exchange site in Area51 (fwd)
Now it's public :) The new Network Engineering Stack Exchange site is now open to the public! After just 8 days in private beta, we've already got 451 users who have asked 99 questions and written 258 answers. We're off to a good start, and it's time to unleash this baby on the public and see if it flies. (Sorry; mixed metaphor.) Tell all your friends, blog about it, tweet about it, and write the URL (http://networkengineering.stackexchange.com) in chalk on the sidewalk in front of your neighbor's house. Or paint. No, never mind, better use chalk. Most importantly, go to the site now and start earning reputation and badges! We'll see you there! Right now! http://networkengineering.stackexchange.com -- that is the URL again http://networkengineering.stackexchange.com -- it has not changed in the last 10 microseconds All the best, The Stack Exchange Team On Tue, May 7, 2013 at 4:44 PM, Yang Yu yang.yu.l...@gmail.com wrote: Network Engineering QA site - Area 51 - Stack Exchange just started private beta. http://networkengineering.stackexchange.com/ If anyone needs a private beta invitation, feel free to email me offlist. Thanks. On Tue, Apr 30, 2013 at 7:40 PM, Simon Lyall si...@darkmere.gen.nz wrote: The proposal currently needs just 13 more committers with 200+ SE points on any site... http://area51.stackexchange.com/proposals/52519/network-engineering The SE site proposal for 'network engineering' is so close to going into Beta. It's up to 441 committers, and is currently 7th overall, (of 800+ proposals,) on the hottest proposal list. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ To stay awake all night adds a day to your life - Stilgar | eMT.
