First step was getting the firmware patches onto a TFTP server near the switch (had to be less 3 hops from the switch, TFTP doesn't work over longer hops).
Unless this is something specific to the IOS or router, that's bullshit. I just upgraded 5 AS5248s to IOS 12.1(9) with a TFTP server that is 8 hops away. I'm not aware of any TTL issues with TFTP.
Uh... TFTP uses UDP, which is a connectionless protocol, you can of course transfer files over more hops, but keep in mind, the more routers, etc you have in the middle, the more chance of a packet being dropped, and one packet can mean quite a bit when your transfering a new IOS image to your cisco;)
While granted, the 1999 TIGER data set is inaccurate in places (I have no experience with data sets older then that, as I started working with it less then a year ago), the USGS photos, are just that, photos.
As I pointed out previously, for mapping software, how do you propose to use the USGS photos? They don't have feature names, etc for quite a few roads, and you can't do "Driving directions" (and a lot of other things) with them easily, unless you can find an automated way to extract data from the photos... If the USGS has datasets that provide more then elevation data (i.e. feature names, etc), then I would be more then glad to know.:) Otherwise, if you want to manually go through the photos, and convert them to lat/lon pairs, along with feature names, etc be my guest....;)
Mind you, I wouldn't use the TIGER data, for anything that requires precision, however, it has gotten to a usefull point where it can (fairly) reliably be used for driving directions, etc when used with the shape point records.... (and you go through using USGS photos or something else to make sure that things are sane). You are correct through, that there is considerible room for improvement... and I do hope the 2000 census data is a lot better.
Please remember that USGS data does not have all of the feature names, etc... Since the TIGER census data has lat/lon pairs, and shape points for each feature (road, river, etc), along with the name of said feature, it is much more preferred for street maps, etc.
Please also remember, that the USGS photos are just that, photos. The TIGER data, contains information about each feature including the lat/lon pairs. For almost all software mapping applications, the TIGER data is infinitely preferible then the USGS photos. Thats not to say the USGS photos aren't usefull, I am simply saying that they are not very usefull for software mapping programs (unless you need elevation data, then USGS DEMs combined with TIGER data would be the best bet).
Actually, most mapping software and websites(mapquest, along with the Deloreme products, etc etc) use TIGER US Census data, NOT USGS data. USGS DEMs only hold elevation data, and while there are also datasets made from overhead flights, etc. these are not suitable for mapping purposes.
Its very easy to make maps using the tiger census data has some information, but the actual data is kind of hard to find on their site, so goto their FTP site.
So, perhaps you should actually research the subject a bit more before posting about how everyone else is wrong, when you are yourself.
Maybe they will make their database of UPC symbols open to the public...
The only free project.. The internet UPC database allows you to do a mysqldump against their database, so it truely is free, although, unfortunately it only has ~30,000 entries.
"The Apeiro technique is based on a standard called multi-protocol label switching, which Roberts has tweaked and renamed D/MPLS - the D is for dynamic."
Basically, in a large network the border routers would take parts of the header of the IP packet (dest/source IP address, etc just like MPLS), along with parts specific to D/MPLS (probably pulling certain information from the payload of packets, among other things), and sticking it in the ATM cell header, allowing things to be switched at Layer 2.
If your just grabbing data from the header of the IP packet, then MPLS already does this (mind you, it could be better). However, as far as being able to look at portions of the payload of packets, and switching them based on that data.. This is not feasable for a backbone router, the latency this would add would be unacceptable in most cases (versus the benefits), unless the data your looking for is always a certain length, etc.
Besides, the important part is you can impliment custom queueing on gateway and border routers, along with MPLS allowing you to do the same thing (minus a few "features", but not enough to make this anything revolutionary). Custom queueing on a Cisco will give certain types of traffic priority over others. I.E. it can give packets with a destination port (TCP/UDP) of 1720 (H.323) the highest priority, while giving FTP traffic (port 21, etc) lower priority. How to set it up on a cisco (and information on it) is at http://www.cisco.com/univercd/cc/td/doc/product/so ftware/ios120/12cgcr/qos_c/qcpart2/qccq.htm
You can also do nifty things like give priority to traffic with a source of a certain subnet (custom queueing can't do that, but using route-map's, etc it can be done), etc.
I actually currently have a back to back SDSL connection using Net to Net tech equipment. I am currently at ~17k total loop length (from me to the CO is like 2k feet, but from the CO to the ISP is ~15k), and am sync'd at a stable 1536kbps (I was at 2.3mbps, however that dropped several times a day for a few seconds)... Mind you, I'm not actually getting that much bandwidth (I can't afford it), but its cool that I *could* (I was able to verify that when I got the DSL line installed). While it is true you can use back to back Netopia's (tech note on how to do it is Here appearently it only works with R7100/R7171 Netopia routers, meaning if you have an R7200, your out of luck.) I prefer Using a dumb bridge, and letting my gateway do outbound load balancing between my 2 DSL lines anyway (I can do nifty things like policy routing, etc on my gateway that I cant on a Netopia..).
Ok, before you say this, and while I realize that the DSL division is different from their circuit repair division... Have you ever had too call in a downed T-1 to them? I have to work with them on a daily basis....
Let me just say, start beating your head on a rock now, because it will be more painfull talking to the reps/testers. (I realize, this is dependent on the person you get, but.. 9 times out of 10 is just scarey).
Please keep in mind that while SDSL allows you to have the same speed up and down, ADSL and RADSL offer forward error correction, which SDSL does not. In a sense, ADSL and RADSL are more reliable then SDSL, when deployed properly.
Lets face it, a CLEC providing DSL is not the best thing in the world. CLECs have to resell services they purchase from the ILEC, so the ILEC will always have the lowest cost. Having DSL through an ILEC (Verizon, Pacbell, etc), wouldn't be so bad, if they A. implimented a viable commercial DSL product (AFAIK the "commercial" Bell Atlantic DSL does not come with even *1* static IP, much less a block), and B. Stopped overselling bandwidth. Not to mention, all the other problems ILEC DSL have. If Verizon hired a reputable "consultant" to go over all of Verizon's DSL services (from provisioning to service, both technical and non technical aspects), made a list of what they need to improve, I think everyone would be happier. Well, at least until fiber to the home comes around.
Slashdot Mirror
First step was getting the firmware patches onto a TFTP server near the switch (had to be less 3 hops from the switch, TFTP doesn't work over longer hops). Unless this is something specific to the IOS or router, that's bullshit. I just upgraded 5 AS5248s to IOS 12.1(9) with a TFTP server that is 8 hops away. I'm not aware of any TTL issues with TFTP. Uh... TFTP uses UDP, which is a connectionless protocol, you can of course transfer files over more hops, but keep in mind, the more routers, etc you have in the middle, the more chance of a packet being dropped, and one packet can mean quite a bit when your transfering a new IOS image to your cisco ;)
While granted, the 1999 TIGER data set is inaccurate in places (I have no experience with data sets older then that, as I started working with it less then a year ago), the USGS photos, are just that, photos. As I pointed out previously, for mapping software, how do you propose to use the USGS photos? They don't have feature names, etc for quite a few roads, and you can't do "Driving directions" (and a lot of other things) with them easily, unless you can find an automated way to extract data from the photos... If the USGS has datasets that provide more then elevation data (i.e. feature names, etc), then I would be more then glad to know. :) Otherwise, if you want to manually go through the photos, and convert them to lat/lon pairs, along with feature names, etc be my guest.... ;)
Mind you, I wouldn't use the TIGER data, for anything that requires precision, however, it has gotten to a usefull point where it can (fairly) reliably be used for driving directions, etc when used with the shape point records.... (and you go through using USGS photos or something else to make sure that things are sane). You are correct through, that there is considerible room for improvement... and I do hope the 2000 census data is a lot better.
Please remember that USGS data does not have all of the feature names, etc... Since the TIGER census data has lat/lon pairs, and shape points for each feature (road, river, etc), along with the name of said feature, it is much more preferred for street maps, etc. Please also remember, that the USGS photos are just that, photos. The TIGER data, contains information about each feature including the lat/lon pairs. For almost all software mapping applications, the TIGER data is infinitely preferible then the USGS photos. Thats not to say the USGS photos aren't usefull, I am simply saying that they are not very usefull for software mapping programs (unless you need elevation data, then USGS DEMs combined with TIGER data would be the best bet).
Actually, most mapping software and websites(mapquest, along with the Deloreme products, etc etc) use TIGER US Census data, NOT USGS data. USGS DEMs only hold elevation data, and while there are also datasets made from overhead flights, etc. these are not suitable for mapping purposes. Its very easy to make maps using the tiger census data has some information, but the actual data is kind of hard to find on their site, so goto their FTP site. So, perhaps you should actually research the subject a bit more before posting about how everyone else is wrong, when you are yourself.
Maybe they will make their database of UPC symbols open to the public... The only free project.. The internet UPC database allows you to do a mysqldump against their database, so it truely is free, although, unfortunately it only has ~30,000 entries.
This isn't such a revolutionary idea.
o ftware/ios120/12cgcr/qos_c/qcpart2/qccq.htm
It says in the article:
"The Apeiro technique is based on a standard called multi-protocol label switching, which Roberts has tweaked and renamed D/MPLS - the D is for dynamic."
Basically, in a large network the border routers would take parts of the header of the IP packet (dest/source IP address, etc just like MPLS), along with parts specific to D/MPLS (probably pulling certain information from the payload of packets, among other things), and sticking it in the ATM cell header, allowing things to be switched at Layer 2.
If your just grabbing data from the header of the IP packet, then MPLS already does this (mind you, it could be better). However, as far as being able to look at portions of the payload of packets, and switching them based on that data.. This is not feasable for a backbone router, the latency this would add would be unacceptable in most cases (versus the benefits), unless the data your looking for is always a certain length, etc.
Besides, the important part is you can impliment custom queueing on gateway and border routers, along with MPLS allowing you to do the same thing (minus a few "features", but not enough to make this anything revolutionary). Custom queueing on a Cisco will give certain types of traffic priority over others. I.E. it can give packets with a destination port (TCP/UDP) of 1720 (H.323) the highest priority, while giving FTP traffic (port 21, etc) lower priority. How to set it up on a cisco (and information on it) is at http://www.cisco.com/univercd/cc/td/doc/product/s
You can also do nifty things like give priority to traffic with a source of a certain subnet (custom queueing can't do that, but using route-map's, etc it can be done), etc.
I actually currently have a back to back SDSL connection using Net to Net tech equipment. I am currently at ~17k total loop length (from me to the CO is like 2k feet, but from the CO to the ISP is ~15k), and am sync'd at a stable 1536kbps (I was at 2.3mbps, however that dropped several times a day for a few seconds)... Mind you, I'm not actually getting that much bandwidth (I can't afford it), but its cool that I *could* (I was able to verify that when I got the DSL line installed). While it is true you can use back to back Netopia's (tech note on how to do it is Here appearently it only works with R7100/R7171 Netopia routers, meaning if you have an R7200, your out of luck.) I prefer Using a dumb bridge, and letting my gateway do outbound load balancing between my 2 DSL lines anyway (I can do nifty things like policy routing, etc on my gateway that I cant on a Netopia..).
Ok, before you say this, and while I realize that the DSL division is different from their circuit repair division... Have you ever had too call in a downed T-1 to them? I have to work with them on a daily basis.... Let me just say, start beating your head on a rock now, because it will be more painfull talking to the reps/testers. (I realize, this is dependent on the person you get, but.. 9 times out of 10 is just scarey).
Please keep in mind that while SDSL allows you to have the same speed up and down, ADSL and RADSL offer forward error correction, which SDSL does not. In a sense, ADSL and RADSL are more reliable then SDSL, when deployed properly.
Lets face it, a CLEC providing DSL is not the best thing in the world. CLECs have to resell services they purchase from the ILEC, so the ILEC will always have the lowest cost. Having DSL through an ILEC (Verizon, Pacbell, etc), wouldn't be so bad, if they A. implimented a viable commercial DSL product (AFAIK the "commercial" Bell Atlantic DSL does not come with even *1* static IP, much less a block), and B. Stopped overselling bandwidth. Not to mention, all the other problems ILEC DSL have. If Verizon hired a reputable "consultant" to go over all of Verizon's DSL services (from provisioning to service, both technical and non technical aspects), made a list of what they need to improve, I think everyone would be happier. Well, at least until fiber to the home comes around.