Re: Programmers with network engineering skills
Joe Greco wrote: The ideal world contains a mix of techniques. Yes and copying parts of relevant code of an MTA could be one. You cannot just blindly leave it to the MTA to decide what's valid. Along that path lies madness. How do you pass the address to the MTA? Don't do it as a system() call unless you want someone to own your box with a semicolon. Well, the whole world can pass whatever it wants to an MTA, it's supposed to be listening on internet facing port 25 all the time, that's it's mean reason of existence. An MTA is particularly well suited to take any kind of abuse, because that's exactly what it's expecting. Unless in cases such as Owen mentioned I'd say it's a pretty good solution. The madness to me lies in making your own email validating code... Greetings, Jeroen -- Earthquake Magnitude: 4.5 Date: Tuesday, March 13, 2012 04:15:05 UTC Location: Dominican Republic region Latitude: 19.3644; Longitude: -68.0645 Depth: 19.20 km
Re: Shim6, was: Re: filtering /48 is going to be necessary
William Herrin wrote: When I ran the numbers a few years ago, a route had a global cost impact in the neighborhood of $8000/year. It's tough to make a case that folks who need multihoming's reliability can't afford to put that much into the system. The cost for bloated DFZ routing table is not so small and is paid by all the players, including those who use DFZ but do not multihome. Hi, http://bill.herrin.us/network/bgpcost.html If you believe there's an error in my methodology, feel free to take issue with it. Your estimate on the number of routers in DFZ: somewhere between 120,000 and 180,000 with the consensus number near 150,000 is a result of high cost of routers and is inappropriate to estimate global cost of a routing table entry. Because DFZ capable routers are so expensive, the actual number of routers is so limited. If the number of routes in DFZ is, say, 100, many routers and hosts will be default free. Often overlooked is that multihoming through multi-addressing could solve IP mobility too. Not. What is often overlooked is the fact that they are orthogonal problems. I respectfully disagree. My statement is based on my experience to implement locator/ID separation system with multi-address TCP and IP mobility. They need separate mechanisms and separate coding. Current mobility efforts have gone down a blind alley of relays from a home server and handoffs from one network to the next. And in all fairness, with TCP tightly bound to a particular IP address pair there aren't a whole lot of other options. Nevertheless, it's badly suboptimal. Latency and routing inefficiency rapidly increases with distance from the home node among other major problems. That is a mobility issue of triangle elimination having nothing to do with TCP. But suppose you had a TCP protocol that wasn't statically bound to the IP address by the application layer. Suppose each side of the connection referenced each other by name, TCP expected to spread packets across multiple local and remote addresses, and suppose TCP, down at layer 4, expected to generate calls to the DNS any time it wasn't sure what addresses it should be talking to. Ignoring that DNS does not work so fast, TCP becomes it wasn't sure what addresses it should be talking to only after a long timeout. And if the node gets even moderately good at predicting when it will lose availability for each network it connects to and/or when to ask the DNS again instead of continuing to try the known IP addresses you can What? A node asks DNS IP addresses of its peer, because the node is changing its IP addresses? The only end to end way to handle multiple addresses is to let applications handle them explicitly. For connection-oriented protocols, that's nonsense. Pick an appropriate mapping function and you can handle multiple layer 3 addresses just fine at layer 4. It will require the applications perform reverse mapping function, when they require raw IP addresses. For connectionless protocols, maybe. I'm afraid you are unaware of connected UDP. However, I'm not convinced that can't be reliably accomplished with a hinting process where the application tells layer 4 its best guess of which send()'s succeeded or failed and lets layer 4 figure out the resulting gory details of address selection. That's annoying, which is partly why shim6 failed. It's a lot easier for UDP-based applications directly manage multiple IP addresses. Masataka Ohta
HSBC - Canada / US Contact off list
Hi Can someone from HSBC (specially Canada) who is involved in network operation contact me off-list. Some of our customers which get IP address from specific network blocks, could not reach hsbc.ca. follow-up with internet banking staff, customer support, and .., did not point us to the right person. Thnx smime.p7s Description: S/MIME cryptographic signature
Re: Programmers with network engineering skills
On 13 March 2012 06:50, Jeroen van Aart jer...@mompl.net wrote: Unless in cases such as Owen mentioned I'd say it's a pretty good solution. The madness to me lies in making your own email validating code... Not forgetting Lett's Law Aled
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 13, 2:21 am, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: William Herrin wrote: When I ran the numbers a few years ago, a route had a global cost impact in the neighborhood of $8000/year. It's tough to make a case that folks who need multihoming's reliability can't afford to put that much into the system. The cost for bloated DFZ routing table is not so small and is paid by all the players, including those who use DFZ but do not multihome. Hi, http://bill.herrin.us/network/bgpcost.html If you believe there's an error in my methodology, feel free to take issue with it. Your estimate on the number of routers in DFZ: somewhere between 120,000 and 180,000 with the consensus number near 150,000 is a result of high cost of routers and is inappropriate to estimate global cost of a routing table entry. Because DFZ capable routers are so expensive, the actual number of routers is so limited. If the number of routes in DFZ is, say, 100, many routers and hosts will be default free For quite some time, a sub-$2000 PC running Linux/BSD has been able to cope with DFZ table sizes and handle enough packets per second to saturate two or more if the prevalent LAN interfaces of the day. The reason current routers in the core are so expensive is because of the 40 gigabit interfaces, custom ASICs to handle billions of PPS, esoteric features, and lack of competition. The fact that long-haul fiber is very expensive to run limits the number of DFZ routers more than anything else. Why not take a default route and simplify life when you're at the end of a single coax link? If your lucky enough to have access to fiber from multiple providers, the cost of a router which can handle a full table is not a major concern compared with your monthly recurring charges. -- RPM
Re: Shim6, was: Re: filtering /48 is going to be necessary
Ryan Malayter wrote: If the number of routes in DFZ is, say, 100, many routers and hosts will be default free For quite some time, a sub-$2000 PC running Linux/BSD has been able to cope with DFZ table sizes and handle enough packets per second to saturate two or more if the prevalent LAN interfaces of the day. What if, you run windows? The reason current routers in the core are so expensive is because of the 40 gigabit interfaces, custom ASICs to handle billions of PPS, esoteric features, and lack of competition. The point of http://bill.herrin.us/network/bgpcost.html was that routers are more expensive because of bloated routing table. If you deny it, you must deny its conclusion. The fact that long-haul fiber is very expensive to run limits the number of DFZ routers more than anything else. Given that global routing table is bloated because of site multihoming, where the site uses multiple ISPs within a city, costs of long-haul fiber is irrelevant. Why not take a default route and simplify life when you're at the end of a single coax link? That's fine. If your lucky enough to have access to fiber from multiple providers, the cost of a router which can handle a full table is not a major concern compared with your monthly recurring charges. As it costs less than $100 per month to have fiber from a local ISP, having them from multiple ISPs costs a lot less is negligible compared to having routers with a so bloated routing table. Masataka Ohta
Re: Programmers with network engineering skills
The ideal world contains a mix of techniques. You cannot just blindly leave it to the MTA to decide what's valid. Along that path lies madness. How do you pass the address to the MTA? Don't do it as a system() call unless you want someone to own your box with a semicolon. Only if you don't properly quote/escape the arguments you are passing. That's a great theory that's been a disaster in practice, as properly is difficult and mistakes often turn into exploits. That's not to say that you're not right, obviously you are, but that is kind of more of a sign of the scope of the problem than anything else. In an ideal world, it wouldn't be an issue. In reality, the set of allowed characters for e-mail addresses should probably have been a bit more controlled... ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Shim6, was: Re: filtering /48 is going to be necessary
In a message written on Tue, Mar 13, 2012 at 02:19:00PM +1100, Geoff Huston wrote: On 13/03/2012, at 2:31 AM, Leo Bicknell wrote: It was never clear to me that even if it worked 100% as advertised that it would be cheaper / better in the global sense. I think that's asking too much of the IETF Leo - Shim6 went through much the same process as most of the IETF work these days: bubble of thought, BOF sanity check, requirements work, protocol prototyping, technology specification. I think you took my statement a bit too literally, as if I wanted a proof that shim6 would be cheaper than building larger routers. That would be asking way too much. However, shim6 for me never even passed the theoretical smell test economically. To make routers handle more DFZ routes basically means putting more memory in routers. It may be super fancy super expensive fast TCAM to handle the job, but at the end of the day it's pretty much just more memory, which means more money. There's a wild range of estimates as to how many DFZ routers there are out there, but it seems like the low end is 50,000 and the high end is 500,000. A lot of ram and a lot of money for sure, but as far as we can tell a tractable problem even with a growth rate much higher than we have now. Compare and contrast with shim6, even if you assume it does everything it was billed to do. First, it assumes we migrate everyone to IPv6, because it's not an IPv4 solution. Second, it assumes we update well, basically every since device with an IP stack. I'm guessing we're north of 5 billion IP devices in the world, and wouldn't be surprised if the number isn't more like 10 billion. Third, because it is a software solution, it will have to be patched/maintained/ported _forever_. I'm hard pressed in my head to rationalize how maintaining software for the next 50 years on a few billion or so boxes is cheaper in the global sense than adding memory to perhaps half a million routers. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpnVPiZxAff6.pgp Description: PGP signature
Regex validation, was Re: Programmers with network engineering skills
On Mon, Mar 12, 2012 at 9:18 PM, Mark Andrews ma...@isc.org wrote: Only if you don't properly quote/escape the arguments you are passing. You're using your OS wrong if you are quoting/escaping the arguments. You do not need a shell involved to use fork() + exec() + wait(), as the shell is not involved (assuming Unix; I also suspect libc has a nice packaged function for this that is not insecure like system(), but it's not all that hard to roll your own). In Perl, use the multi-argument form of system(), not the single argument version(). In both cases you should clear the environment as well prior to the exec()/system() unless you know nobody can play with LD_PRELOAD, IFS, etc. This is one of my pet peeves about programming - programmers calling out to insecure functions when secure alternatives are available. The same goes for SQL statements - if you need to quote things to prevent SQL injection, you're using your SQL database wrong. Look up prepared statements. Generally, it's very bad practice to dynamically build SQL strings. It's also very common practice, hence why so many applications have SQL injection vulnerabilities. It's the Perl/PHP equivalent of the buffer overflow that simply wouldn't exist if developers, instead of trying to figure out how to quote everything, simply used prepared statements and placeholders. As for checking for bogus email addresses, read the RFC and code it right. That's not with a too-simple regex, nor is it with a complex regex. You need a parser, which is the right tool for the job. Regex is not. But there is value in not passing utter garbage to another program (it has a tendency to clog mail queues, if for no other reason) - just make sure you do it right. I might add that the same goes for names. People don't just have a first name and a last name - some people just have one name, some people have three or four names, some people have surnames with spaces, hypens, or apostrophes (remember what I said about SQL?!), etc. Yet most systems I see assume people have two names with no spaces, apostrophies, hyphens, etc. Big mistake. And don't get me started on addresses, which might have one address line, two address lines, even 5 address lines, to say nothing that international addresses may or may not put the street part first. It's certainly not easily regex-able. Okay, I'll step off the soap box and let the next person holler about how I was wrong about all this!
Re: Programmers with network engineering skills
I may add that when I reached the point of having my 'AT cagnazzo.name'
address rejected by the form, I was already pretty angry because the
form had a sign, all written in UPPER CASE LETTERS, saying that the form
did not support other browsers than Internet Explorer.
:=)
C.
On 3/12/12 7:43 PM, Owen DeLong wrote:
I think this proves one thing...
Given enough monkeys with typewriters, you will, in fact, not
get Shakespeare, but, instead, regular expressions for Shakespeare's
email address.
Owen
On Mar 12, 2012, at 3:09 PM, Paul Graydon wrote:
On 03/12/2012 09:46 AM, Tei wrote:
On 12 March 2012 09:59, Carlos Martinez-Cagnazzocarlosm3...@gmail.com
wrote:
Hey!
On 3/8/12 8:24 PM, Lamar Owen wrote:
On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
...
(16) The default gateway's IP address is always 192.168.0.1
(17) The user portion of E-mail addresses never contain special
characters like - + $ ~ . ,, [, ]
I've just had my ' xx AT cagnazzo.name' email address rejected by a web
form saying that 'it is not a valid email address'. So I guess point
(17) can be extended to say that 'no email address shall end in anything
different that .com, .net or the local ccTLD'
:=)
Carlos
Yea, I don't even know how programmers can get that wrong. The regex
is not even hard or anything.
(?:[a-z0-9!#$%'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%'*+/=?^_`{|}~-]+)*|(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*)@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
It's supposedly a lot harder than that. Try this for strict RFC822
compliance (from http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html):
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t]
)+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\0
31]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+
(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z
|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:\r\n)
?[ \t])*)*\(?:(?:\r\n)?[ \t])*(?:@(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:\
r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t]
)+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+
|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t
]))*(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031
]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?
:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\(?:(?:\r\n)?[ \t])*)|(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?
:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[
\t])*(?:[^()
@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|
(?:[^\\r\\]|\\.|(?:(?:\r\n)?[ \t]))*(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[
\t]
)*(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\
.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[
\t])*(?
:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()@,;:\\.\[\]
\000-
\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*(?:(?:\r\n)?[ \t])*)*\(?:(?:\r\n)?[
\t])*(?:@(?:[^()@,;
:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
Email Integration / Account Migration
Hi : If there is anyone out there that has experience with migrating Email from one ISP to another at the retail level using products such as the True Switch product from ESAYA, and would be willing to share some thoughts/experiences, could you please contact me off list ? Thanks mike
CISCO ASA Botnet Traffic Filter contact off-list
Hi, Does anyone have a contact at CISCO that deals with their ASA botnet filtering software? I'm having trouble finding out why our network is listed. Thanks, Jeff
Re: Shim6, was: Re: filtering /48 is going to be necessary
2012/3/13 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: William Herrin wrote: http://bill.herrin.us/network/bgpcost.html If you believe there's an error in my methodology, feel free to take issue with it. Your estimate on the number of routers in DFZ: somewhere between 120,000 and 180,000 with the consensus number near 150,000 is a result of high cost of routers and is inappropriate to estimate global cost of a routing table entry. Hi, Please elaborate. In what way is the average cost of routers carrying the DFZ table an inappropriate variable in estimating the cost of the routing system? Because DFZ capable routers are so expensive, the actual number of routers is so limited. If the number of routes in DFZ is, say, 100, many routers and hosts will be default free. If wishes were horses, beggars would ride. The number of routes in the DFZ isn't 100 and is trending north, not south. Often overlooked is that multihoming through multi-addressing could solve IP mobility too. Not. What is often overlooked is the fact that they are orthogonal problems. I respectfully disagree. My statement is based on my experience to implement locator/ID separation system with multi-address TCP and IP mobility. They need separate mechanisms and separate coding. I've been an IRTF RRG participant and in my day job I build backend systems for mobile messaging devices used in some very challenging and very global IP and non-IP environments. If we're done touting our respective qualifications to hold an opinion, let's get back to vetting the idea itself. Current mobility efforts have gone down a blind alley of relays from a home server and handoffs from one network to the next. And in all fairness, with TCP tightly bound to a particular IP address pair there aren't a whole lot of other options. Nevertheless, it's badly suboptimal. Latency and routing inefficiency rapidly increases with distance from the home node among other major problems. That is a mobility issue of triangle elimination having nothing to do with TCP. Au contraire. Triangle elimination is a problem because the IP address can't change with session survivability. But that's because TCP and UDP require it. If A follows from B and B follows from C then A follows from C: TCP is at fault. But suppose you had a TCP protocol that wasn't statically bound to the IP address by the application layer. Suppose each side of the connection referenced each other by name, TCP expected to spread packets across multiple local and remote addresses, and suppose TCP, down at layer 4, expected to generate calls to the DNS any time it wasn't sure what addresses it should be talking to. Ignoring that DNS does not work so fast, TCP becomes it wasn't sure what addresses it should be talking to only after a long timeout. Says who? Our hypothetical TCP can become unsure as soon as the first retransmission if we want it to. It can even become unsure when handed a packet to send after a long delay with no traffic. There's little delay kicking off the recheck either way. And if the node gets even moderately good at predicting when it will lose availability for each network it connects to and/or when to ask the DNS again instead of continuing to try the known IP addresses you can What? A node asks DNS IP addresses of its peer, because the node is changing its IP addresses? A re-verify by name lookup kicks off in a side thread any time the target threshold for a certainty heuristic is hit. Inputs into that heuristic include things like the TTL expiration of the prior lookup, the time since successful communication with the peer and the time spent retrying since the last successful communication with the peer. If you have any communication with the peer on any address pair, he can tell you what addresses should still be on your try-me list. If there's a reasonable chance that you've lost communication with the peer, then you ask the DNS server for the peer's latest information. The only end to end way to handle multiple addresses is to let applications handle them explicitly. For connection-oriented protocols, that's nonsense. Pick an appropriate mapping function and you can handle multiple layer 3 addresses just fine at layer 4. It will require the applications perform reverse mapping function, when they require raw IP addresses. No. The application passes the IP address in a string the same way it passes a name. The layer 4 protocol figures out how it's going to map that to a name. It could do a reverse mapping. It could connect to the raw IP and request that the peer provide a name. There are several other strategies which could be used independently or as a group. But you avoid using them at the application level. Keep that operation under layer 4's control. For connectionless protocols, maybe. I'm afraid you are unaware of connected UDP. Your fears are unfounded. However, I'm not
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Tue, Mar 13, 2012 at 9:48 AM, Leo Bicknell bickn...@ufp.org wrote: I'm hard pressed in my head to rationalize how maintaining software for the next 50 years on a few billion or so boxes is cheaper in the global sense than adding memory to perhaps half a million routers. For a one-order of magnitude increase in routes, (upper bound of $30B/year the BGP way) it may or may not be. For a four orders increase ($30T/year) it's self-evidently cheaper to change software on the billion or so boxes. How many routes would a system improvement that radically reduced the cost per route add? 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
SNMP monitoring of routing tables
Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. Does anyone know of an existing project to do this before I start trying to make one? Walter Keen
Re: SNMP monitoring of routing tables
Try RIS from RIPE NCC or routeviews. regards, as Sent from my mobile device (please excuse typoss and brevit.) On 13 Mar 2012, at 11:54, Walter Keen walter.k...@rainierconnect.net wrote: Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. Does anyone know of an existing project to do this before I start trying to make one? Walter Keen
Re: SNMP monitoring of routing tables
In a message written on Tue, Mar 13, 2012 at 10:54:08AM -0700, Walter Keen wrote: Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. Does anyone know of an existing project to do this before I start trying to make one? RIPE's RIS and Route-View's both archive BGP tables and you can download them and manipulate them. There are several other services that archive the data, like Renesys, but don't provide raw data downloads. SNMP is really a non-starter for this work. Too slow, the table changes out from under you, plus it's hugely inefficient. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpiEsFZrhMnj.pgp Description: PGP signature
Re: Email Integration / Account Migration
I've successfully used YippieMove in the past migrating from Google Apps to Exchange. http://www.yippiemove.com/ -Mike On Tue, Mar 13, 2012 at 8:36 AM, Mike Rae mike@sjrb.ca wrote: Hi : If there is anyone out there that has experience with migrating Email from one ISP to another at the retail level using products such as the True Switch product from ESAYA, and would be willing to share some thoughts/experiences, could you please contact me off list ? Thanks mike -- Mike Lyon 408-621-4826 mike.l...@gmail.com http://www.linkedin.com/in/mlyon
Re: Email Integration / Account Migration
Hello Mike You can look for my friends form shuttlecloud.com They are much into hard core data migration. On Tue, Mar 13, 2012 at 9:06 PM, Mike Rae mike@sjrb.ca wrote: Hi : If there is anyone out there that has experience with migrating Email from one ISP to another at the retail level using products such as the True Switch product from ESAYA, and would be willing to share some thoughts/experiences, could you please contact me off list ? Thanks mike -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com
Re: SNMP monitoring of routing tables
Hi I use bgpmon.net That include among others ripe ris info Might be worth to have look at that Cheers JC Sent from whatever On 13 Mar 2012, at 19:00, Walter Keen walter.k...@rainierconnect.net wrote: Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. Does anyone know of an existing project to do this before I start trying to make one? Walter Keen De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. Cordares Holding NV is gevestigd te Amsterdam en is ingeschreven in het handelsregister van de Kamer van Koophandel onder nummer 33276459. The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. Cordares Holding NV is located in Amsterdam and is registered at the trade register of the Chamber of Commerce with number 33276459. -
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 13, 2012, at 6:03 AM, Masataka Ohta wrote: Ryan Malayter wrote: If the number of routes in DFZ is, say, 100, many routers and hosts will be default free For quite some time, a sub-$2000 PC running Linux/BSD has been able to cope with DFZ table sizes and handle enough packets per second to saturate two or more if the prevalent LAN interfaces of the day. What if, you run windows? Why would you want to run windows on a box you're trying to use as a router? That's like trying to invade Fort Knox with a bag of plastic soldiers. Leo's point is that you can build/buy a DFZ capable router for less than $2,000. If you run windows, the box will be more expensive, less capable, and less reliable. If that's what you want, knock yourself out, but, it's hardly relevant to the discussion at hand. The reason current routers in the core are so expensive is because of the 40 gigabit interfaces, custom ASICs to handle billions of PPS, esoteric features, and lack of competition. The point of http://bill.herrin.us/network/bgpcost.html was that routers are more expensive because of bloated routing table. If you deny it, you must deny its conclusion. To a certain extent you are right. I believe that Bill's analysis and his conclusions are deeply flawed in many ways. However, he is marginally correct in that the high cost of core DFZ routers is the product of the large forwarding table multiplied by the cost per forwarding entry in a high-pps high-data-rate system. Further adding to this is the fact that high-rate (pps,data) routers generally need to distribute copies of the FIB to each line card so the cost per forwarding entry is further multiplied by the number of line cards (and in some cases, the number of modules installed on each line card). The fact that long-haul fiber is very expensive to run limits the number of DFZ routers more than anything else. Given that global routing table is bloated because of site multihoming, where the site uses multiple ISPs within a city, costs of long-haul fiber is irrelevant. Long-haul meaning anything that leaves the building. Yes, it's a poor choice of terminology, but, if you prefer, the costs of last- mile fiber apply equally to Leo's point. Why not take a default route and simplify life when you're at the end of a single coax link? That's fine. If your lucky enough to have access to fiber from multiple providers, the cost of a router which can handle a full table is not a major concern compared with your monthly recurring charges. As it costs less than $100 per month to have fiber from a local ISP, having them from multiple ISPs costs a lot less is negligible compared to having routers with a so bloated routing table. $100/month * 2 = $200/month. $200/month pays for a DFZ capable router every year. That's means that the cost of 2*fiber costs quite a bit more than the cost of the router. There is a difference between a DFZ router and a core router. I personally run a DFZ router for my personal AS. I don't personally own or run a core router for my personal AS. The fact that people conflate the idea of a DFZ router with the idea of a core router is part of the problem and a big part of where Bill's cost structure analysis breaks, as you pointed out. Small to medium businesses that want to multihome can easily do so with relatively small investments in equipment which are actually negligible compared to the telecom costs for the multiple connections. Owen
Re: Shim6, was: Re: filtering /48 is going to be necessary
It's _WAY_ more than a billion boxes at this point. Owen On Mar 13, 2012, at 10:27 AM, William Herrin wrote: On Tue, Mar 13, 2012 at 9:48 AM, Leo Bicknell bickn...@ufp.org wrote: I'm hard pressed in my head to rationalize how maintaining software for the next 50 years on a few billion or so boxes is cheaper in the global sense than adding memory to perhaps half a million routers. For a one-order of magnitude increase in routes, (upper bound of $30B/year the BGP way) it may or may not be. For a four orders increase ($30T/year) it's self-evidently cheaper to change software on the billion or so boxes. How many routes would a system improvement that radically reduced the cost per route add? 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: Programmers with network engineering skills
Joe Greco wrote: The ideal world contains a mix of techniques. Yes and copying parts of relevant code of an MTA could be one. May actually be one of the few sane ones. You cannot just blindly leave it to the MTA to decide what's valid. Along that path lies madness. How do you pass the address to the MTA? Don't do it as a system() call unless you want someone to own your box with a semicolon. Well, the whole world can pass whatever it wants to an MTA, it's supposed to be listening on internet facing port 25 all the time, that's it's mean reason of existence. An MTA is particularly well suited to take any kind of abuse, because that's exactly what it's expecting. Unless in cases such as Owen mentioned I'd say it's a pretty good solution. The madness to me lies in making your own email validating code... This is probably one of those things where the spec was good when it was written for reasons that were good at the time, but now many years later in a generally completely FQDN-ified world, there's little valid reason to need to be able to support some of the odd possible syntaxes that we used twenty or thirty years ago. The problem is, current programmers look at the evil spec, say fooey with that, and then code up something that is too unreasonably restrictive in the opposite direction. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 13, 2:18 pm, Owen DeLong o...@delong.com wrote: On Mar 13, 2012, at 6:03 AM, Masataka Ohta wrote: Ryan Malayter wrote: If the number of routes in DFZ is, say, 100, many routers and hosts will be default free For quite some time, a sub-$2000 PC running Linux/BSD has been able to cope with DFZ table sizes and handle enough packets per second to saturate two or more if the prevalent LAN interfaces of the day. What if, you run windows? Why would you want to run windows on a box you're trying to use as a router? That's like trying to invade Fort Knox with a bag of plastic soldiers. Check your quoting depth... you're attributing Masataka Ohta's comments to me, he brought up running windows. I am the one who brought put forward the notion of a sub-$2000 DFZ router.
Re: SNMP monitoring of routing tables
Does anyone know of a similar tool (opensource/low cost) for the IGPs? It would be really cool to have a snapshot for troubleshooting post-mortem. Thanks! David. On Tue, Mar 13, 2012 at 2:43 PM, Bontje, Juan Carlos j.bon...@cordares.nlwrote: Hi I use bgpmon.net That include among others ripe ris info Might be worth to have look at that Cheers JC Sent from whatever On 13 Mar 2012, at 19:00, Walter Keen walter.k...@rainierconnect.net wrote: Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. Does anyone know of an existing project to do this before I start trying to make one? Walter Keen De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. Cordares Holding NV is gevestigd te Amsterdam en is ingeschreven in het handelsregister van de Kamer van Koophandel onder nummer 33276459. The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. Cordares Holding NV is located in Amsterdam and is registered at the trade register of the Chamber of Commerce with number 33276459. -
Xirrus Wireless
I know this is a little outside of the traditional NANOG realm but... I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. Thanks! Blake
CAIDA's 2012 IPv6 survey -- need network operators to fill out
[direct link to IPv6 operational deployment [plans] survey if you don't need background: http://www.surveygizmo.com/s3/749797/ipv6survey ] hello folks, we're trying to do some quantitative modeling of the IPv4-IPv6 transition, including the impact of IPv4 markets on likely future trajectories, but really need some empirical data to parametrize our model. with much help from many patient reviewers of the questions, we finally have a survey ready for operators to fill out. below i'll give an extremely terse description of the model just to give you an idea of why we need this granularity. there are another 10 dense pages describing the model pending peer review at NSF, which i can send to anyone interested in giving us feedback on it. but it's not necessary for responding to the survey. also note the checkbox to indicate you're amenable to further followup questions. survey will be available till 12 april 2012. (or tell us if you want to fill it out but need more time.) survey link, again: http://www.surveygizmo.com/s3/749797/ipv6survey thanks much, k, amogh, emile -- Most prior work on modeling the adoption of new technologies assumed a binary decision at the organization level -- in the context of IPv6, this decision means switching completely to IPv6 or not at all. We propose to account for the fact that an organization may deploy IPv6 incrementally in its network, meaning that it will continue to have both IPv4 and IPv6 space. A key aspect of our model is that instead of a binary state per organization, we work at the granularity of devices, which are entities that need to be assigned IP addresses. We consider a device to correspond to a single instance of an IP addressing need, which typically corresponds to an interface. Though there can be multiple interfaces (``devices'') on the same computer/router, and multiple addresses (``virtual interfaces'') on a single interface, we will model each need for an independent IP address as an independent device. We define device classes based on the nature of addresses used to number those devices, e.g., public IPv4, IPv6, dual-stack-NATv4, dual-stack-public-IPv4, etc. We model the network growth requirements of each network in terms of the number of additional devices in that network that need to be configured in one of these device classes. ... (then we catalog a list of costs and incentives associated with the decision to adopt IPv6 or satisfy one's addressing needs with IPv4-based technologies. costs parameters include the costs of IPv4 addresses, NAT deployment, renumbering, and translation between IPv4 and IPv6. we will also try to model incentives such as policies and regulations.) We will then model two separate decision processes for a network, based on whether it seeks to add new devices (to expand its network, provision for new customers, deploy new services, etc.), or whether it seeks to optimize the numbering of its existing devices from among the five device classes defined previously. The latter operation may be necessary if external factors and costs have changed such that the network could substantially lower its costs by numbering its devices differently. We want to structure the model (based on feedback from opsfolk like you) to capture both initial costs as well as ongoing operational costs of supporting a given configuration of devices for a specified window following the decision. Iteration of the decision process continues for each network until we reach a state where no network has the incentive to change the numbering of its devices, which represents the equilibrium.
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 13, 8:03 am, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: The point of http://bill.herrin.us/network/bgpcost.html was that routers are more expensive because of bloated routing table. If you deny it, you must deny its conclusion. Bill's analysis is quite interesting, but my initial take is that it is somehwat flawed. It assumes that the difference between what Cisco charges for a 7606 and a 3750G bears some resemblance to the actual bill of materials needed to support the larger routing table. That simply isn't the case: Cisco rightly charges what they think the market will bear for their routers and switches. I think a more realistic approach would be to use the cost differential between a router model X that supports 1M routes the same model configured to support 2M routes. Or perhaps we could look at the street prices for TCAM expansion modules. Either would be a better indicator of the incremental cost attributable to routing table size. The majority of costs in a mid-to-high-end Cisco/Juniper chassis are sunk and have nothing to do with the size of the routing table. The expensive routers currently used by providers are expensive because the market isn't that big in quantity, so they are not commodity items. They are designed to maximize the utility of very expensive long-haul fibers and facilities to a service provider. This means providing a high density of high-speed interfaces which can handle millions to billions of packets per second. They also provide lots of features that service providers and large enterprises want, sometimes in custom ASICs. These are features which have nothing to do with the size of the DFZ routing table, but significantly impact the cost of the device. Given that global routing table is bloated because of site multihoming, where the site uses multiple ISPs within a city, costs of long-haul fiber is irrelevant. I suppose smaller multi-homed sites can and often do take a full table, but they don't *need* to do so. What they do need is their routes advertised to the rest of the internet, which means they must be in the fancy-and-currently-expensive routers somewhere upstream. This is where the cost of long-haul fiber becomes relevant: Until we can figure out how dig cheaper ditches and negotiate cheaper rights-of- way, there will not be an explosion of the number of full-table provider edge routers, because there are only so many interconnection points where they are needed. Incremental growth, perhaps, but physical infrastructure cannot follow an exponential growth curve. As it costs less than $100 per month to have fiber from a local ISP, having them from multiple ISPs costs a lot less is negligible compared to having routers with a so bloated routing table. For consumer connections, a sub-$1000 PC would serve you fine with a full table given the level of over-subscription involved. Even something like Quagga or Vyatta running in a virutal machine would suffice. Or a Linksys with more RAM. Getting your providers to speak BGP with you on such a connection for that same $100/month will be quite a feat. Even in your contrived case, however, the monthly recurring charges exceed a $1000 router cost after a few months. Enterprises pay several thousand dollars per month per link for quality IP transit at Gigabit rates.
Re: SNMP monitoring of routing tables
Does anyone know of a similar tool (opensource/low cost) for the IGPs? packet design randy
Re: Shim6, was: Re: filtering /48 is going to be necessary
Yes, the economics of routing are strange, and the lack of any real strictures in the routing tables are testament to the observation that despite more than two decades of tossing the idea around we've yet to find the equivalent of a route deaggregation tax or a route advertisement tax or any other mechanism that effectively turns the routing space into a form of market that imposes some economic constraints on the activity. among other things, i suspect that the shadow of telco settlements makes us shy away from this. randy
Re: Programmers with network engineering skills
On 2012-03-13 16:33, Joe Greco wrote: Joe Greco wrote: The ideal world contains a mix of techniques. Yes and copying parts of relevant code of an MTA could be one. May actually be one of the few sane ones. You cannot just blindly leave it to the MTA to decide what's valid. Along that path lies madness. How do you pass the address to the MTA? Don't do it as a system() call unless you want someone to own your box with a semicolon. Well, the whole world can pass whatever it wants to an MTA, it's supposed to be listening on internet facing port 25 all the time, that's it's mean reason of existence. An MTA is particularly well suited to take any kind of abuse, because that's exactly what it's expecting. imo, this discussion of outbound SMTP has been sounding akin to me saying I should let my upstream ensure that all of my BGP announcements are good, instead of filtering my own outbound. Unless in cases such as Owen mentioned I'd say it's a pretty good solution. The madness to me lies in making your own email validating code... This is probably one of those things where the spec was good when it was written for reasons that were good at the time, but now many years later in a generally completely FQDN-ified world, there's little valid reason to need to be able to support some of the odd possible syntaxes that we used twenty or thirty years ago. The problem is, current programmers look at the evil spec, say fooey with that, and then code up something that is too unreasonably restrictive in the opposite direction. There are ready-made solutions that abstract away the need for the programmer to write their own regex or compliance checks to meet the specs. In Perl for example, there is Email::Valid. One line of code and you know whether the address is to RFC or not. Less bugs and changes, I feel it is better to give the remote host known-good data then have to have them tell me it is bad. Steve disclaimer: I've wrote patches for said module over the years, and I named it only for example purposes.
Verizon FiOS - is BGP an option?
All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? jms
Re: Xirrus Wireless
On 03/13/2012 02:34 PM, Blake Pfankuch wrote: I know this is a little outside of the traditional NANOG realm but... I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. I can only speak from indirect experience; the rehab place where my wife is staying for a bit uses 4 or 5 of them (older, probably not current, flying-saucer-like boxes suspended from the ceiling at hallway junctions) and there, at least, they appear to work pretty well. The particular ones don't appear to my laptop to do 11a. However, I don't think there is any significant user density just from watching the nifty directional light display, so this may not mean much (I'd guess 3 to 10 users over the whole building including smartphones and a couple of pieces of medical equipment that isn't used much). Also there is no IT (or any real technical maint) guy on-premises to talk to so I can't ask about any other aspect. The local real hospital uses a Cisco system (or at least Cisco APs; don't know about the AP manager box) which really does appear to work well; I'd guess several hundred APs with lots of full-time medical gear, and a guest network which is behind a rather draconian firewall (wouldn't let me ssh out to a non-standard port (65k range), for example; I had to fix myself a 443 ssh port for the time we spent there a couple of months ago... Blocked 25 outgoing; I don't blame them for that, however they also blocked 465 (but allowed 587)). I suspect if I wanted 2.4-only I'd go with ubiquiti, but I don't have any experience with them, and their unifi boxes don't (yet) come in 5gig. And they don't appear to have independent APs in each box, though I don't know how well the directional antennas in the Xirrus actually separate things; even a 100mw transmitter may well overwhelm all the other local receivers unless there is a bunch of shielding inside the enclosure (and maybe even then...) If 802.11 was frequency-split like the cell system it would help such systems a bunch. -- Pete Thanks! Blake
Re: Shim6, was: Re: filtering /48 is going to be necessary
On 14/03/2012, at 9:16 AM, Randy Bush wrote: Yes, the economics of routing are strange, and the lack of any real strictures in the routing tables are testament to the observation that despite more than two decades of tossing the idea around we've yet to find the equivalent of a route deaggregation tax or a route advertisement tax or any other mechanism that effectively turns the routing space into a form of market that imposes some economic constraints on the activity. among other things, i suspect that the shadow of telco settlements makes us shy away from this. Agreed. It's all ugly! The shadow of telco settlement nonsense, the entire issue of route pull vs route push, and the spectre of any such payments morphing into a coerced money flow towards to the so-called tier 1 networks all make this untenable. The topic has been coming up pretty regularly every 2 years since about 1994 to my knowledge, and probably earlier, and has never managed to get anywhere useful. Geoff
Re: Xirrus Wireless
On 03/13/2012 03:35 PM, Blake Pfankuch wrote: Thanks Pete, that does help. Now hopefully I can get someone who has experience with 500+ devices running on a single one in a fairly small area (High School Gym). There was a thread about this a couple of months back, I'm pretty sure it was after last November (but not absolutely sure); lots of discussion about density and Xirrrus was mentioned. My personal experience with Xirrus is certainly not high-density, and the real hospital certainly copes with a bunch (though I'm guessing 20-30 users per AP from how many APs they have distributed among rooms. They seem to do a bunch of their device telemetry on 802.11 but there are also some more dedicated frequencies/protocols for medical devices. (even the IV pumps alarm at the nurse's station...) I do have some experience with full-duplex RF transceiver design, though, and the Xirrus configuration can't be easy to make work well. Not impossible, but difficult. -- Pete -Original Message- From: Pete Carah [mailto:p...@altadena.net] Sent: Tuesday, March 13, 2012 4:32 PM To: nanog@nanog.org Subject: Re: Xirrus Wireless On 03/13/2012 02:34 PM, Blake Pfankuch wrote: I know this is a little outside of the traditional NANOG realm but... I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. I can only speak from indirect experience; the rehab place where my wife is staying for a bit uses 4 or 5 of them (older, probably not current, flying-saucer-like boxes suspended from the ceiling at hallway junctions) and there, at least, they appear to work pretty well. The particular ones don't appear to my laptop to do 11a. However, I don't think there is any significant user density just from watching the nifty directional light display, so this may not mean much (I'd guess 3 to 10 users over the whole building including smartphones and a couple of pieces of medical equipment that isn't used much). Also there is no IT (or any real technical maint) guy on-premises to talk to so I can't ask about any other aspect. The local real hospital uses a Cisco system (or at least Cisco APs; don't know about the AP manager box) which really does appear to work well; I'd guess several hundred APs with lots of full-time medical gear, and a guest network which is behind a rather draconian firewall (wouldn't let me ssh out to a non-standard port (65k range), for example; I had to fix myself a 443 ssh port for the time we spent there a couple of months ago... Blocked 25 outgoing; I don't blame them for that, however they also blocked 465 (but allowed 587)). I suspect if I wanted 2.4-only I'd go with ubiquiti, but I don't have any experience with them, and their unifi boxes don't (yet) come in 5gig. And they don't appear to have independent APs in each box, though I don't know how well the directional antennas in the Xirrus actually separate things; even a 100mw transmitter may well overwhelm all the other local receivers unless there is a bunch of shielding inside the enclosure (and maybe even then...) If 802.11 was frequency-split like the cell system it would help such systems a bunch. -- Pete Thanks! Blake
Re: Shim6, was: Re: filtering /48 is going to be necessary
Yes, the economics of routing are strange, and the lack of any real strictures in the routing tables are testament to the observation that despite more than two decades of tossing the idea around we've yet to find the equivalent of a route deaggregation tax or a route advertisement tax or any other mechanism that effectively turns the routing space into a form of market that imposes some economic constraints on the activity. among other things, i suspect that the shadow of telco settlements makes us shy away from this. Agreed. It's all ugly! The shadow of telco settlement nonsense, the entire issue of route pull vs route push, and the spectre of any such payments morphing into a coerced money flow towards to the so-called tier 1 networks all make this untenable. The topic has been coming up pretty regularly every 2 years since about 1994 to my knowledge, and probably earlier, and has never managed to get anywhere useful. so we are left with o name and shame, and we have seen how unsucsessful that has been. the polluters have no shame. o operational incentives. peers' and general routing filters were the classic dis-incentive to deaggregate. but the droids cave in the minute the geeks leave the room (ntt/verio caved within a month or two of my departure). o router hacks. we have had tickets open for many years asking for knob variations on 'if it is covered (from same peer, from same origin, ...), drop it.' none of which seem to move us forward. i guess the lesson is that, as long as we are well below moore, we just keep going down the slippery, and damned expensive, slope. randy
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? No. If you want to do BGP with Verizon, you have to buy a T1 at 10 times the cost and 1/10th of the speed. Though I'd love to discover I'm mistaken about that. :) 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
Telstra contact
Anyone from the Telstra NOC lurking - or can pass on a Telstra technical contact? Having no luck through the usual channels. Looking to utilise some data from some cables you have lurking around. Ideally someone with global net ops insight rather than local coverage. Many thanks, Robert.
Re: Verizon FiOS - is BGP an option?
Haha true that. How else would.they.push their atm and.Ethernet products. chris On Mar 13, 2012 7:04 PM, William Herrin b...@herrin.us wrote: On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? No. If you want to do BGP with Verizon, you have to buy a T1 at 10 times the cost and 1/10th of the speed. Though I'd love to discover I'm mistaken about that. :) 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: Shim6, was: Re: filtering /48 is going to be necessary
In a message written on Wed, Mar 14, 2012 at 07:58:30AM +0900, Randy Bush wrote: none of which seem to move us forward. i guess the lesson is that, as long as we are well below moore, we just keep going down the slippery, and damned expensive, slope. Bill's model for price is too simple, and it's because the number of devices with a full table change as the price pressure changes, and that causes other costs. Quite simply, if a box that could take a full table were 10x cheaper, more people would take a full table at the edge. More full tables at the edge probably means more BGP speakers. More BGP speakers means more churn, and churn means the core device needs more CPU. TL;DR A savings in ram may result in an increased need for CPU, based on a change in user behavior. I also think the difference in the BOM to a router vendor is small for most boxes. That is the actual cost to manufacture difference between a 1M route box and 2M route box is noise, on the high end the cost of 40 and 100G optics dominate, and on the low end in a CPU switching box RAM is super-cheap. The only proof I can offer is the _lack_ of vendors offering different route-holding profiles, and that the few that do are stuck in the mid-range equipment. If the route memory was such a big factor you would see more vendors with route memory options. Indeed, over time, the number of boxes with route-memory options have dropped over time and I think this is due to the fact that memory prices have dropped _much_ faster than CPU or optic prices. TL;DR backbone routers are on a treadmill for faster interfaces, and memory is a small fraction of their cost, edge routers are on a tredmill for more CPU for edge features, and again RAM is a fraction of their cost. It's only boxes in the middle being squeezed. I'll note Bill used the 6509/7600 platform, which is solidly in the middle and does have route-memory options (Sup720-3C Sup720-3CXL). If my theory is right, he used pretty much the _worst_ case to arrive at his $8k per route figure. The list price difference in these two cards is $12,000 to go from 256,000 routes to 1,000,000 routes. $12,000 / 750,000 routes = 1.6 cents per route per box. That matches Bill's number (and I think is where he got it), $8000 route/box / 1.6 cents/route/box = 500,000 boxes. But that box has a 5-7 year time frame, so it's really more like (being generous) $1600 per route per box per year. Priced a 100 Gig optic lately, or long haul DWDM system? I don't think the cost of routes is damned expensive. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpxsgNWsHWHQ.pgp Description: PGP signature
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 7:09 PM, chris tknch...@gmail.com wrote: On Mar 13, 2012 7:04 PM, William Herrin b...@herrin.us wrote: On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. No. If you want to do BGP with Verizon, you have to buy a T1 at 10 times the cost and 1/10th of the speed. Haha true that. How else would.they.push their atm and.Ethernet products. A cost I could live with. It's the fact that they won't sell me BGP service in the FiOS product line *at all* that makes me pine for the days of FCC mandated unbundling. 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: Verizon FiOS - is BGP an option?
On Tue, 13 Mar 2012, William Herrin wrote: A cost I could live with. It's the fact that they won't sell me BGP service in the FiOS product line *at all* that makes me pine for the days of FCC mandated unbundling. Having the same problem with Comcast, even on there business Cable service they wont do BGP with me. -Nathan 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: Verizon FiOS - is BGP an option?
Comcast same deal ethernet only chris On Mar 13, 2012 7:42 PM, Nathan Stratton nat...@robotics.net wrote: On Tue, 13 Mar 2012, William Herrin wrote: A cost I could live with. It's the fact that they won't sell me BGP service in the FiOS product line *at all* that makes me pine for the days of FCC mandated unbundling. Having the same problem with Comcast, even on there business Cable service they wont do BGP with me. -Nathan 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: Verizon FiOS - is BGP an option?
On Tue, 13 Mar 2012, chris wrote: Comcast same deal ethernet only Yep, I got a quote for that, 7K a month yet I can get 100 meg on a gig circuit for $400 bucks from them in a datacenter. Oh, and the 7K is NOT to cover build out, did I forget to mention that node for my area is in MY backyard??? -Nathan
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner strei...@cluebyfour.org wrote: All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? So techsupport folks aside.. the product they sell is: A) DHCP only, single address, dynamic B) Single Static address (uplift of 25$/month I believe?) C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the option-B above/month. You can't bring your own space You can't do BGP You can get more than 5 ips (in 5 ip chunks I believe) for 25$/month per chunk... ip address rental, welcome to 1999! Also, I know that on 701 the rate of BGP to non-BGP customers was increasing and was at ~30% or so as of ~2007... You'd think that 19262 would see that, see the business opportunity and offer it? Though, I suppose they DO see the business opportunity: You want bgp? you want to bring your own ips? you want more than a DHCP address? Pay up, a lot. weee! fun times! At some point there was fairly serious talk of moving the FIOS product into the last-mile offering for 701 customers as well, guess that didn't happen? :( Seems, to me at least, like the PON technology would be a win/win for large ISP customers... easy upgrade paths (dial-on-demand-bandwidth almost?) and simple CPE deployments: Ethernet? sure it's available! -chris
Re: SNMP monitoring of routing tables
I concur. Their tool is quite nice. --Tom On Mar 13, 2012, at 6:14 PM, Randy Bush wrote: Does anyone know of a similar tool (opensource/low cost) for the IGPs? packet design randy
Re: Verizon FiOS - is BGP an option?
So I have to ask you the big question... Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or Cable ?) Is the intent to Peer with their network ? (which they will rightfully only allow on bigger fatter connections).. or Are you trying to delivery your IP's to a End Customer behind that FIOS / Cable Connection ? ... (there a ways to accomplish this without needing their cooperation..) Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 3/13/2012 8:06 PM, Christopher Morrow wrote: On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner strei...@cluebyfour.org wrote: All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? So techsupport folks aside.. the product they sell is: A) DHCP only, single address, dynamic B) Single Static address (uplift of 25$/month I believe?) C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the option-B above/month. You can't bring your own space You can't do BGP You can get more than 5 ips (in 5 ip chunks I believe) for 25$/month per chunk... ip address rental, welcome to 1999! Also, I know that on 701 the rate of BGP to non-BGP customers was increasing and was at ~30% or so as of ~2007... You'd think that 19262 would see that, see the business opportunity and offer it? Though, I suppose they DO see the business opportunity: You want bgp? you want to bring your own ips? you want more than a DHCP address? Pay up, a lot. weee! fun times! At some point there was fairly serious talk of moving the FIOS product into the last-mile offering for 701 customers as well, guess that didn't happen? :( Seems, to me at least, like the PON technology would be a win/win for large ISP customers... easy upgrade paths (dial-on-demand-bandwidth almost?) and simple CPE deployments: Ethernet? sure it's available! -chris
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 8:20 PM, Faisal Imtiaz fai...@snappydsl.net wrote: So I have to ask you the big question... Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or Cable ?) Is the intent to Peer with their network ? (which they will rightfully only allow on bigger fatter connections).. 'peer' has many connotations, I think most of the cases of it over FIOS are just: I want bgp so I can announce my prefixes, and see yours/default/etc (which leads to 'multihoming' and other normal (for businesses) activities on the Internet. or Are you trying to delivery your IP's to a End Customer behind that FIOS / Cable Connection ? ... (there a ways to accomplish this without needing their cooperation..) or you are multihomed or you want some semblence of 'the internet is down' so other bits of your infrastructure can take over or you want ... a thousand other things.
Re: Verizon FiOS - is BGP an option?
On Tue, 13 Mar 2012, Faisal Imtiaz wrote: Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or Cable ?) To gain redundancy for a consulting client. Is the intent to Peer with their network ? (which they will rightfully only allow on bigger fatter connections).. I think you mean higher margin connections ;) As far as I know, most major carriers will still sell you a T1 for Internet access (and even BGP!) if you want it. Are you trying to delivery your IP's to a End Customer behind that FIOS / Cable Connection ? ... (there a ways to accomplish this without needing their cooperation..) Running BGP over a tunnel is one (albeit sub-optimal) option, but I don't know of any providers that sell such a service. All of the other options have varying degrees of downside, i.e. how much of an outage are you willing to put up with when provider A fails, transferring DNS records, etc. jms
Re: Verizon FiOS - is BGP an option?
Peering is generally for a comercial endevor to my understandind fios is a residential service so which are you trying to accomplish Sent from my iPhone On 2012-03-13, at 7:32 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Mar 13, 2012 at 8:20 PM, Faisal Imtiaz fai...@snappydsl.net wrote: So I have to ask you the big question... Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or Cable ?) Is the intent to Peer with their network ? (which they will rightfully only allow on bigger fatter connections).. 'peer' has many connotations, I think most of the cases of it over FIOS are just: I want bgp so I can announce my prefixes, and see yours/default/etc (which leads to 'multihoming' and other normal (for businesses) activities on the Internet. or Are you trying to delivery your IP's to a End Customer behind that FIOS / Cable Connection ? ... (there a ways to accomplish this without needing their cooperation..) or you are multihomed or you want some semblence of 'the internet is down' so other bits of your infrastructure can take over or you want ... a thousand other things.
Re: Verizon FiOS - is BGP an option?
On Tue, 13 Mar 2012, Christopher Morrow wrote: A) DHCP only, single address, dynamic B) Single Static address (uplift of 25$/month I believe?) I think that might be $40/mo now, but I could be mistaken. Also, I know that on 701 the rate of BGP to non-BGP customers was increasing and was at ~30% or so as of ~2007... You'd think that 19262 would see that, see the business opportunity and offer it? Though, I suppose they DO see the business opportunity: You want bgp? you want to bring your own ips? you want more than a DHCP address? Pay up, a lot. I wonder if something is cooking there. When I look at a full BGP view, I see quite a few ASNs downstream of 19262, beyond some that appear to be internal VZ ASNs: * 12.195.9.0/24x.x.x.x 701 19262 30079 * 65.198.73.0/24 x.x.x.x 701 19262 40321 * 68.236.226.0/24 x.x.x.x 701 19262 18762 * 137.71.229.0/24 x.x.x.x 701 19262 20258 * 141.155.220.0/24 x.x.x.x 701 19262 36512 * 143.165.216.0/21 x.x.x.x 701 19262 2923 . jms
Re: Verizon FiOS - is BGP an option?
4 of the 6 downstreams are multihomed. Only 40321 (Emigrant Bank) and 18762 (Dominick Dominick LLC) are single homed to 19262 (Verizon Online LLC). -Grant On Tue, Mar 13, 2012 at 7:43 PM, Justin M. Streiner strei...@cluebyfour.org wrote: On Tue, 13 Mar 2012, Christopher Morrow wrote: A) DHCP only, single address, dynamic B) Single Static address (uplift of 25$/month I believe?) I think that might be $40/mo now, but I could be mistaken. Also, I know that on 701 the rate of BGP to non-BGP customers was increasing and was at ~30% or so as of ~2007... You'd think that 19262 would see that, see the business opportunity and offer it? Though, I suppose they DO see the business opportunity: You want bgp? you want to bring your own ips? you want more than a DHCP address? Pay up, a lot. I wonder if something is cooking there. When I look at a full BGP view, I see quite a few ASNs downstream of 19262, beyond some that appear to be internal VZ ASNs: * 12.195.9.0/24x.x.x.x 701 19262 30079 * 65.198.73.0/24 x.x.x.x 701 19262 40321 * 68.236.226.0/24 x.x.x.x 701 19262 18762 * 137.71.229.0/24 x.x.x.x 701 19262 20258 * 141.155.220.0/24 x.x.x.x 701 19262 36512 * 143.165.216.0/21 x.x.x.x 701 19262 2923 . jms
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 9:09 PM, Grant Ridder shortdudey...@gmail.com wrote: 4 of the 6 downstreams are multihomed. Only 40321 (Emigrant Bank) and 18762 (Dominick Dominick LLC) are single homed to 19262 (Verizon Online LLC). yup... vz had for quite some time actual 'network' customers behind 19262, as part of larger multi-site deals. they also ran a 'private mpls vpn' across that same core for a time (and likely still do...) -chris On Tue, Mar 13, 2012 at 7:43 PM, Justin M. Streiner strei...@cluebyfour.org wrote: On Tue, 13 Mar 2012, Christopher Morrow wrote: A) DHCP only, single address, dynamic B) Single Static address (uplift of 25$/month I believe?) I think that might be $40/mo now, but I could be mistaken. Also, I know that on 701 the rate of BGP to non-BGP customers was increasing and was at ~30% or so as of ~2007... You'd think that 19262 would see that, see the business opportunity and offer it? Though, I suppose they DO see the business opportunity: You want bgp? you want to bring your own ips? you want more than a DHCP address? Pay up, a lot. I wonder if something is cooking there. When I look at a full BGP view, I see quite a few ASNs downstream of 19262, beyond some that appear to be internal VZ ASNs: * 12.195.9.0/24 x.x.x.x 701 19262 30079 * 65.198.73.0/24 x.x.x.x 701 19262 40321 * 68.236.226.0/24 x.x.x.x 701 19262 18762 * 137.71.229.0/24 x.x.x.x 701 19262 20258 * 141.155.220.0/24 x.x.x.x 701 19262 36512 * 143.165.216.0/21 x.x.x.x 701 19262 2923 . jms
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 8:35 PM, Mark Gauvin mgau...@dryden.ca wrote: Peering is generally for a comercial endevor to my understandind fios is a residential service so which are you trying to accomplish 'peering' really is a loaded term... 'settlement free peering' ? 'bgp peering' ? there are other meanings as well, but I think in the case the person I responded (Faisal?) was asking about he meant 'settlement free peering', which I don't think is what Justin meant, Justin just wants the same as most of the bgp speakers want: multihoming. -chris
Re: Verizon FiOS - is BGP an option?
What is the SLA for FIOS? I believe that FIOS uses either PON or GPON technology where a single data wavelength is split up to 32 times resulting in a shared pipe back to the CO. Does Verizon offer any SLA at all for FIOS? On the other hand Verizon Wireless offers BGP peering for business customers, but lacks geographically-dispersed peering points with their wired network, which results in unusually high round trip latencies. On Tue, Mar 13, 2012 at 3:26 PM, Justin M. Streiner strei...@cluebyfour.org wrote: All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? jms
Re: Verizon FiOS - is BGP an option?
Sorry, by saying Peering I mean any kind of direct peering.. As to the other reason for running BGP, there are technical solutions to get around this 'lack of cooperation'. Personally speaking, asking for BGP peering on a 'resi' grade service is like going to McDonalds, and asking for a cooking lesson from their Head Chef. No flame or offense intended. Take us for example, we are an independent service provider, technically, can we do bgp over a DSL connection, the answer is yes, can we 'route' a class 'C' for someone purchasing a resi dsl service, the answer is yes... Now the real question you are asking ... (or complaining about) is Do we want to do this ? from a business perspective ..answer is NO. from a Technical perspective... do we have the desire to support it ? ... answer is NO... .. Complex Routing and resi connections just don't mix ... :) So if we don't want to do this, why do you think or feel that VZ or any other Large provider should do this ? (besides. there is this other minor issue that their infrastructure deployed to serve FIOS / Cable / ADSL / UVerse is not designed nor capable of doing BGP with end-user connection / routers.. ). Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 3/13/2012 9:15 PM, Christopher Morrow wrote: On Tue, Mar 13, 2012 at 8:35 PM, Mark Gauvinmgau...@dryden.ca wrote: Peering is generally for a comercial endevor to my understandind fios is a residential service so which are you trying to accomplish 'peering' really is a loaded term... 'settlement free peering' ? 'bgp peering' ? there are other meanings as well, but I think in the case the person I responded (Faisal?) was asking about he meant 'settlement free peering', which I don't think is what Justin meant, Justin just wants the same as most of the bgp speakers want: multihoming. -chris
Re: Shim6, was: Re: filtering /48 is going to be necessary
Given that global routing table is bloated because of site multihoming, where the site uses multiple ISPs within a city, costs of long-haul fiber is irrelevant. I suppose smaller multi-homed sites can and often do take a full table, but they don't *need* to do so. What they do need is their routes advertised to the rest of the internet, which means they must be in the fancy-and-currently-expensive routers somewhere upstream. This is where the cost of long-haul fiber becomes relevant: Until we can figure out how dig cheaper ditches and negotiate cheaper rights-of- way, there will not be an explosion of the number of full-table provider edge routers, because there are only so many interconnection points where they are needed. Incremental growth, perhaps, but physical infrastructure cannot follow an exponential growth curve. Not entirely accurate. Most of the reduction in cost/mbps that has occurred over the last couple of decades has come not from better digging economics (though there has been some improvement there), but rather from more Mpbs per dig. As technology continues to increase the Mbps/strand, strands/cable, etc., the cost/Mbps will continue to drop. I expect within my lifetime that multi-gigabit ethernet will become commonplace in the household LAN environment and that when that becomes reality, localized IP Multicast over multi-gigabit ethernet will eventually supplant HDMI as the primary transport for audio/video streams between devices (sources such as BD players, DVRs, computers, etc. and destinations such as receivers/amps, monitors, speaker drivers, etc.). There are already hackish efforts at this capability in the form of TiVO's HTTTPs services, Sling Box, and others. As it costs less than $100 per month to have fiber from a local ISP, having them from multiple ISPs costs a lot less is negligible compared to having routers with a so bloated routing table. For consumer connections, a sub-$1000 PC would serve you fine with a full table given the level of over-subscription involved. Even something like Quagga or Vyatta running in a virutal machine would suffice. Or a Linksys with more RAM. Getting your providers to speak BGP with you on such a connection for that same $100/month will be quite a feat. Even in your contrived case, however, the monthly recurring charges exceed a $1000 router cost after a few months. Simpler solution, let the providers speak whatever they will sell you. Ideally, find one that will at least sell you a static address. Then use a tunnel to do your real routing. There are several free tunnel services and I know at least one will do BGP. Enterprises pay several thousand dollars per month per link for quality IP transit at Gigabit rates. Since this isn't a marketing list, I'll let this one slide by. Owen
Re: Verizon FiOS - is BGP an option?
C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the option-B above/month. And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, 5 for your devices all routed as a single /29. Owen
GRX looking glass
Hello, Any public looking glasses for GRX? Thanks. Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 11:20 PM, Owen DeLong o...@delong.com wrote: C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the option-B above/month. And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) eh, these end up (I think) aggregated on the edge router, so you get 5 /32's from a /23 (or the like) routed to the edge layer3 device. not as bloaty for the rest of their network as it at first seems. In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, 5 for your devices all routed as a single /29. owen, seen the config on a live router, yes they are routed as /32's to the VC you are connected to. I probably have the config for my old link in IM/email somewhere. apparently their automation either doesn't understand CIDR, or it was 'too expensive' to make the automation do CIDR once they started to offer extra ips to the business customers. -chris
Re: Verizon FiOS - is BGP an option?
On Tue, Mar 13, 2012 at 11:20 PM, Owen DeLong o...@delong.com wrote: C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the option-B above/month. And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, 5 for your devices all routed as a single /29. Nope. I have FiOS and the 5 IPs. They are 5 IPs, in sequence, at a completely arbitrary location in a /24 subnet. They're not routed to anywhere. I can plug an plain old hub into the FiOS ONT and whatever machine responds to the ARP request gets them. I too expected they were going to be a /29 routed to an exterior interface. I was disappointed since I could have squeezed 9 IPs out of that. 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: Verizon FiOS - is BGP an option?
One possible avenue is put a router/computer in a colo and build a GRE tunnel over your FiOS connection to the data center, and then peer with folk there. Frank -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Tuesday, March 13, 2012 5:27 PM To: nanog@nanog.org Subject: Verizon FiOS - is BGP an option? All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? jms smime.p7s Description: S/MIME cryptographic signature
Re: Verizon FiOS - is BGP an option?
next lets encapsulate bgp over http next so we can run bgp at wifi hotspots :) On Wed, Mar 14, 2012 at 12:34 AM, Frank Bulk frnk...@iname.com wrote: One possible avenue is put a router/computer in a colo and build a GRE tunnel over your FiOS connection to the data center, and then peer with folk there. Frank -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Tuesday, March 13, 2012 5:27 PM To: nanog@nanog.org Subject: Verizon FiOS - is BGP an option? All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the what is BGP? response that likely awaits from their salescritters? jms
RE: Xirrus Wireless
Thanks very much to all of the useful on and off list releases. I would like to also thank Ron Valdez of Vall Technologies for his very prompt sales contact as well. Very unprofessional, but nice try to cover up the contact with the excuse of simple google searches while reaching out to local IT firms to find my contact information and directly attempt to market a product which I just recently asked about here, and conveniently he happens to be a Xirrus Gold Partner. Summary of what I have learned, including quotes from a few people who said it better than I can reword it. Conceptually, it sounds like a good idea to increate spectral bandwidth, but I have a hunch that it falls down somewhat in practice. Several people have mentioned that only a limited number of radios within each device (3) can do 2.4ghz at the same time (which makes sense) due to signal conflict and the specified specs which say 120 degrees of broadcast per antenna. Several people have also stated (as well as math) that a single device can only handle about 90-120 2.4ghz clients before there is noticeable slowdown. 5ghz wise experience holds up to specs as far as client connections. Having 802.11b enabled anywhere has had a very negative on performance of the device as one could expect. In buildings with many smaller rooms, using a single device to cover so many rooms runs you into the problem of interference thanks to walls, refraction and material conflicts. Scaling them back becomes tough because each device with its large number of radios saturates the spectrum, allowing limited overlap... Xirrus is overkill [...] when doing small gigs and won't scale [to] very big events, compared to a truckload of cisco APs. Mostly because our venues are not stadium sized. Turn up the AP count, turn down the signal strength fill the building 'til it glows. Thanks for all the input! -Original Message- From: Pete Carah [mailto:p...@altadena.net] Sent: Tuesday, March 13, 2012 4:46 PM To: Blake Pfankuch; NANOG Mailing List Subject: Re: Xirrus Wireless On 03/13/2012 03:35 PM, Blake Pfankuch wrote: Thanks Pete, that does help. Now hopefully I can get someone who has experience with 500+ devices running on a single one in a fairly small area (High School Gym). There was a thread about this a couple of months back, I'm pretty sure it was after last November (but not absolutely sure); lots of discussion about density and Xirrrus was mentioned. My personal experience with Xirrus is certainly not high-density, and the real hospital certainly copes with a bunch (though I'm guessing 20-30 users per AP from how many APs they have distributed among rooms. They seem to do a bunch of their device telemetry on 802.11 but there are also some more dedicated frequencies/protocols for medical devices. (even the IV pumps alarm at the nurse's station...) I do have some experience with full-duplex RF transceiver design, though, and the Xirrus configuration can't be easy to make work well. Not impossible, but difficult. -- Pete -Original Message- From: Pete Carah [mailto:p...@altadena.net] Sent: Tuesday, March 13, 2012 4:32 PM To: nanog@nanog.org Subject: Re: Xirrus Wireless On 03/13/2012 02:34 PM, Blake Pfankuch wrote: I know this is a little outside of the traditional NANOG realm but... I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. I can only speak from indirect experience; the rehab place where my wife is staying for a bit uses 4 or 5 of them (older, probably not current, flying-saucer-like boxes suspended from the ceiling at hallway junctions) and there, at least, they appear to work pretty well. The particular ones don't appear to my laptop to do 11a. However, I don't think there is any significant user density just from watching the nifty directional light display, so this may not mean much (I'd guess 3 to 10 users over the whole building including smartphones and a couple of pieces of medical equipment that isn't used much). Also there is no IT (or any real technical maint) guy on-premises to talk to so I can't ask about any other aspect. The local real hospital uses a Cisco system (or at least Cisco APs; don't know about the AP manager box) which really does appear to work well; I'd guess several hundred APs with lots of full-time medical gear, and a guest network which is behind a rather draconian firewall (wouldn't let me ssh out to a non-standard port (65k range), for example; I had to fix myself a 443 ssh port for the time we spent there a couple of months ago...
Re: Verizon FiOS - is BGP an option?
On Mar 13, 2012, at 8:57 PM, Christopher Morrow wrote: On Tue, Mar 13, 2012 at 11:20 PM, Owen DeLong o...@delong.com wrote: C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the option-B above/month. And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) eh, these end up (I think) aggregated on the edge router, so you get 5 /32's from a /23 (or the like) routed to the edge layer3 device. not as bloaty for the rest of their network as it at first seems. In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, 5 for your devices all routed as a single /29. owen, seen the config on a live router, yes they are routed as /32's to the VC you are connected to. I probably have the config for my old link in IM/email somewhere. apparently their automation either doesn't understand CIDR, or it was 'too expensive' to make the automation do CIDR once they started to offer extra ips to the business customers. -chris Interesting. I guess to each their own. Many other providers I know are selling 5 IP packages done the other way. Owen
Re: Verizon FiOS - is BGP an option?
On Wed, Mar 14, 2012 at 1:00 AM, Owen DeLong o...@delong.com wrote: Interesting. I guess to each their own. Many other providers I know are selling 5 IP packages done the other way. many providers are not crazy yes I agree.
Re: Xirrus Wireless
Blake Pfankuch wrote: Thanks very much to all of the useful on and off list releases. If you want to try and gleen more info. and get some questions answered, Moonblink is having a webinar next Wednesday and I'm sure they'd love to have you attend. FREE Webinar! The Changing Role of Wi-Fi w/ Xirrus March 21, 2012 @ 10AM PST Register Today! Wi-Fi is changing. In addition to a desktop or a laptop connecting to a local AP, people have wi-fi enabled smartphones, tablets, and other devices. A new generation of wireless infrastructure is needed. Join Perry Correll, Xirrus' Director of Product Marketing, to learn how Wi-Fi is changing and how Xirrus' Wi-Fi Arrays are the only products capable of accommodating current and future wi-fi requirements. http://www.moonblinkwifi.com/pd_xirrus-wi-fi-array-hardware-xn8.cfm
RE: Xirrus Wireless
Blake/NANOGL I just completed the Technical Training with Xirrus at a session in Dallas. The arrays are designed to go way beyond just worrying about signal strength (coverage) throughout a building or venue. They tackle the problem of how much bandwidth each connected client has available, which is something I have not had the tools to worry about with other WiFi manufacturers. They seem robust and full featured. They have been around for a while too, so going with Xirrus Arrays is not a beta test of their product. They are at least in their third generation of the product now. Cool stuff! Lorell Hathcock MTCRE, MTCWE, MTCTCE OfficeConnect.net lor...@officeconnect.net -Original Message- From: Blake Pfankuch [mailto:bl...@pfankuch.me] Sent: Tuesday, March 13, 2012 4:34 PM To: NANOG (nanog@nanog.org) Subject: Xirrus Wireless I know this is a little outside of the traditional NANOG realm but... I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. Thanks! Blake
