- Test - lists.nanog.org

Wireless bridge
by Peter Boone 05 Apr '10

05 Apr '10

Hi NANOG, I'm looking for some equipment recommendations for a wireless bridge between two locations approximately 500-800 meters apart. The current setup for this company has been extremely unstable and slow. I don't have a lot of experience in this area so I was hoping someone could give me a few pointers. Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT firmware (Yes, 802.11g. All extra bells and whistles are disabled in the firmware. They were set up for WDS so other wireless clients could connect to the same access point, with varying degrees of success. Not very important). They are connected to SmartAnt 2300-2500 MHz 14 dBi directional antenna mounted on the roof (extended pretty high for perfect line of sight). I'm not sure when they got these antenna exactly but I'm told it was when WiFi was very new. The network is very small so both locations share the same subnet (192.168.1.0/24). They have gone through numerous Linksys access points over the years. The wireless settings are tweaked as best as possible, and we have found the connection to be most stable when the TX is limited to 6-9 Mbps. We have explored other options as well. An internet connection at each location + VPN is out due to very slow upstream speeds (the buildings are in an industrial area, ADSL is the only option.) The max they offer on regular business accounts is 800 kbps up. T1 lines are even slower and even more expensive. They won't offer us any other solutions such as fibre. We have considered running fibre/coax but there is too much construction activity and other property in the way. I'm looking into RouterBOARD right now, considering a RB433AH and R52H wireless card, but I'm not sure this will actually solve the problem. It's difficult to determine if the issue is with the antennas or access points (for example, after a good thunderstorm, the wireless link will be down for at least 12 hours, but will fix itself eventually. Resetting either access point will keep the link down for at least 30 minutes. Using an airgun on the access points tends to make them more reliable, even if they are clean and dust free. From the admin interface, each access point will report seeing a very good and strong signal from the other, yet they refuse to communicate until they feel like it a few hours later.) Any suggestions welcome. I'm sure you can tell cost is a bit of a factor here but it will be easy for me to justify a higher price if I'm confident it will be effective. While I'm at it, I've been reading along on the list for over a year now; thanks everyone for sharing your real world experiences :) Peter

23 36

Re: what about 48 bits?
by Franck Martin 05 Apr '10

05 Apr '10

----- "Valdis Kletnieks" <Valdis.Kletnieks(a)vt.edu> wrote: > On Mon, 05 Apr 2010 17:26:53 EDT, "Patrick W. Gilmore" said: > > I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out > of > > MAC addresses. Instead of going to get more - if I even can! - I > > recycle those MAC addresses > > There were several cases of production run errors from multiple > vendors, > where the MAC address went 14, 15, 16, 17, 17, 17, 17, *thwack*, 18, > 19.... And to make the problem worse, they are likely to end up in the same shop, and you get them when you purchase several of them.

1 0

Common statistics from your NOC
by Kasper Adel 05 Apr '10

05 Apr '10

Hello, I want to collect experience from the Gurus on this mailer on how they make use of the data they can get from NOC. what i mean by data, trouble tickets opened internally or with vendors. I wonder what would be common or even uncommon type of statistics that a network operator would like to poll from their NOC to help them in: 1) Optimizing and tuning operations 2) Optimizing and tuning engineering Example on point 1: If we were to put all tickets in an excel sheet and take a holistic look at the type of technology or product, we can see that out of 100 incidents, there were 50 cases related to routing protocols, this would yield that either more training is needed for operations team or that the design is flawed. Example on point 2: 20 incidents appeared to be related to new configuration lines that when added, a conflict was seen, so the take away would be that engineering needs a lab. Excuse my poor English, unicast replies are welcomed. Regards, Kim

1 0

RE: What is "The Internet" TCP/IP or UNIX-to-UNIX ? (Jim Mercer)
by Joel M Snyder 05 Apr '10

05 Apr '10

>The ability to build dirt-cheap networks over crappy phone lines >and using some no-name PCs as message and packet routers was >noticed, see for example: "Developing Networks in Less >Industrialized Nations" by Larry Press Heck, I even wrote my PhD dissertation (http://www.opus1.com/www/jms/diss.html) on it. And among the 848 references, this "Antonov" character (avg(a)hq.demos.su) even gets quoted three times (assuming you're not also V.S.Antonov who wrote "Interfacing Tasks of Systems SM and ES Computers and Ways of Their Solution" in 1983). jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms(a)Opus1.COM http://www.opus1.com/jms

1 0

Re: What is "The Internet" TCP/IP or UNIX-to-UNIX ?
by msokolov＠ivan.Harhan.ORG 05 Apr '10

05 Apr '10

Jim Mercer <jim(a)reptiles.org> wrote: > if the script determined an email was > X bytes (100k?), the message body > was rewritten with: > > "Contents removed at LSUC, email is not a file transport protocol." > and the mail was left to continue on its path. > > i kinda feel like adding the same script back into my servers. I have my Sendmail configured to cut off anything past 256 KB in the collect phase. At first I had it configured to reject the whole message (close the SMTP connection while the junk is still spewing), but people started assuming that my E-mail address was bad instead of realizing that they were sending oversize junk, so I've changed it to cut off and discard the excess fat, but still let the first 256 KB through so I at least see that someone tried to send me something. Files are meant to be FTPed, not E-mailed. If someone is too stupid to use a real command line FTP client to upload a file to my FTP drop box, I make them use www.yousendit.com. MS

3 2

CPE Ethernet switch suggestions
by ML 05 Apr '10

05 Apr '10

Lately I've been delivering triple play services over a single CAT5 drop from a IDF to customers. We have been using small SOHO switches but they've been turning into a bit of a hassle since we have to stage each switch before deployment. I want remove the initial staging step by allowing the installer to just plug the switch in and have the switch grab a config from a TFTP server noted by a DHCP option. Features that I would absolutely need for the switch to be viable: IGMP Snooping Dot1q VLAN tagging Preferably 8-ports A decent set of rate limiting options (5/10/20Mbps) Extra bonus if it can also be PoE powered Does anyone on list know of such a dream CPE device?

3 2

Re: NANOG Digest, Vol 27, Issue 25
by Russell Berg 05 Apr '10

05 Apr '10

"nanog-request(a)nanog.org" <nanog-request(a)nanog.org> wrote: Send NANOG mailing list submissions to nanog(a)nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request(a)nanog.org You can reach the person managing the list at nanog-owner(a)nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. RE: legacy /8 (George Bonser) 2. Re: legacy /8 (Randy Bush) 3. RE: legacy /8 (Frank Bulk) 4. RE: legacy /8 (Frank Bulk) 5. Re: legacy /8 (David Conrad) 6. Re: legacy /8 (Zaid Ali) 7. Re: legacy /8 (Mark Smith) 8. Fw: legacy /8 (Mark Smith) ---------------------------------------------------------------------- Message: 1 Date: Sat, 3 Apr 2010 12:09:51 -0700 From: "George Bonser" <gbonser(a)seven.com> Subject: RE: legacy /8 To: <marka(a)isc.org> Cc: nanog(a)nanog.org Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C76(a)RWC-EX1.corp.seven.com> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: marka(a)isc.org [mailto:marka@isc.org] > Sent: Saturday, April 03, 2010 11:42 AM > To: George Bonser > Cc: Larry Sheldon; nanog(a)nanog.org > Subject: Re: legacy /8 > > > And we would have still had the same problem of intercommunicating. > We know how to talk from IPv6 to IPv4 and get the reply traffic back. > The hard part is how to initiate connection from IPv4 to IPv6. The > same problem would exist in your "just expand the address bits world". > > Mark Actually, Mark, I hadn't said "just expand the address", I said to tunnel v4 in v4 which we already know how to do and most routers are already capable of doing. But yes, in the case of legacy devices that don't "speak" the new protocol, some sort of state for the flow would have to be maintained in that unit's first hop (or close to first hop) gateway. Simply increasing the address header on v4 to 128 bits would have fixed this problem years ago and got rid of such problems as NAT and we wouldn't be having this issue (and it would have been completely backwards compatible as 0s would be inserted into the new expanded address bits to put the legacy space in a special address range. I wouldn't expect to work out all the details over email on a weekend but I don't think it would take 10 years, either. The fundamental issue to me is that v6 solves a lot of problems that aren't really problems for most people and to get the fix that solves the problem you do have, you must accept a bunch of additional "fixes" for problems you don't have that makes the whole thing some big unwieldy contraption. That having been said, once the world has migrated to v6, we should have an easier go of it in the future as v6 is more easily extensible. But in the meantime, we are stuck with both protocols for probably the next 20 years or so as there are going to be places that are going to run v4 internally even if they communicate v6 externally. So ... "we are going to mandate that everyone use this new and better car but it will take different fuel, use different tires, won't fit in your garage and oh, it is incompatible with all existing roads unless you load it up on one of the old style vehicles piggy-back, but new roads are being built (here's a picture of one) and might someday be available where you live. And two years from now there will be none of the old cars left." But my daughter will need a car in three years and there are no such roads here. "Oh well! The new way is much better, it is for your own good, you will see. Trust me". ------------------------------ Message: 2 Date: Sun, 04 Apr 2010 05:36:26 +0900 From: Randy Bush <randy(a)psg.com> Subject: Re: legacy /8 To: George Bonser <gbonser(a)seven.com> Cc: North American Network Operators Group <nanog(a)nanog.org> Message-ID: <m2hbnsjmt1.wl%randy(a)psg.com> Content-Type: text/plain; charset=US-ASCII > No. But that isn't the point. The point is that v6 was a bad solution > to the problem. Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. it's known as "second system syndrome." and you neglect to add that ipv6 did not deal with the routing problems, which are rather intimately connected with addressing in both the ipv4 and the ipv6 models. randy ------------------------------ Message: 3 Date: Sat, 3 Apr 2010 16:22:12 -0500 From: "Frank Bulk" <frnkblk(a)iname.com> Subject: RE: legacy /8 To: <nanog(a)nanog.org> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABa3wZheJVIR45rbqPho5y5AQAAAAA=(a)iname.com> Content-Type: text/plain; charset="iso-8859-1" If "every significant router on the market" supported IPv6 five years ago, why aren't transit links glowing with IPv6 connectivity? If it's not the hardware, than I'm guessing it's something else, like people or processes? Frank -----Original Message----- From: Michael Dillon [mailto:wavetossed@googlemail.com] Sent: Saturday, April 03, 2010 1:07 PM To: Larry Sheldon Cc: nanog(a)nanog.org Subject: Re: legacy /8 > Not often you hear something that has changed just about every aspect of > life and enabled things that could not be imagined at its outset ?called > a failure Sounds like you are describing the Roman Empire. It failed and that's why we now have an EU in its place. Things change. Time to move on. IPv4 has run out of addresses and we are nowhere near finished GROWING THE NETWORK. IPv6 was created to solve just this problem, and 10 years ago folks started deploying it in order to be ready. By 5 years ago, every significant router on the market supported IPv6. Now that we actually need IPv6 in order to continue network growth, most ISPs are in the fortunate position that their network hardware already supports it well enough, so the investment required is minimized. --Michael Dillon ------------------------------ Message: 4 Date: Sat, 3 Apr 2010 16:30:32 -0500 From: "Frank Bulk" <frnkblk(a)iname.com> Subject: RE: legacy /8 To: "'James Hess'" <mysidia(a)gmail.com>, "George Bonser" <gbonser(a)seven.com>, <nanog(a)nanog.org> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADkiLCe9o7+RLmWUhTYga4rAQAAAAA=(a)iname.com> Content-Type: text/plain; charset="us-ascii" If Google made the same strong statement with IPv6 as they have done with their 700 MHz bid or the Google-subsidized fiber project, it could make a significant difference. A few examples come to mind: - free or discounted advertising to vendors if delivered over IPv6: this would incent advertisers to have viewers access content over IPv6, even if it was just on mobile phones with certain apps. - free or discounted Google Apps if a certain percentage of client access was over IPv6, etc: this would incent enterprises (the non-profits are either free or discounted, so this example applies mostly to the for-profits) to find native IPv6 access because it provides an immediate and direct savings Frank -----Original Message----- From: James Hess [mailto:mysidia@gmail.com] Sent: Saturday, April 03, 2010 1:08 PM To: George Bonser Cc: nanog(a)nanog.org Subject: Re: legacy /8 <snip> I suppose if Google announced tomorrow, that search engine access over IPv4 is going to be discontinued in 12 months, and you will have to connect using IPv6, then IPv4 might become legacy....... They could have posted that on April 1, with impunity too :) Enterprises may take a long time to move, there are so many participants involved, it is difficult to fathom them all acting at once, at least, until some major content providers, major search engines, etc, announce they will _stop_ providing services over V4. <snip> -- -J ------------------------------ Message: 5 Date: Sat, 3 Apr 2010 11:35:56 -1000 From: David Conrad <drc(a)virtualized.org> Subject: Re: legacy /8 To: frnkblk(a)iname.com Cc: nanog(a)nanog.org Message-ID: <FB728DBD-E36B-46A5-B0E2-BADB65A8E23B(a)virtualized.org> Content-Type: text/plain; charset=us-ascii On Apr 3, 2010, at 11:22 AM, Frank Bulk wrote: > If "every significant router on the market" supported IPv6 five years ago, > why aren't transit links glowing with IPv6 connectivity? If it's not the > hardware, than I'm guessing it's something else, like people or processes? Or the fact that "supporting IPv6" could (and as far I could tell did until very recently) mean minimalistic process switching of packets without any of the 'niceties' of filtering, management, monitoring, etc. support. It also ignores the fact that there is a bit more to providing Internet service than simply running routers. However, historically we had: 1) why should ISPs pay to deploy IPv6 when their customers aren't asking for it? 2) why should customers ask for IPv6 when there is no content available via it? 3) why should content providers make their content available over IPv6 when they can't get it from their ISPs and none of their customers are asking for it? It may be that IPv4 free pool run out will result in costs for obtaining IPv4 to rise sufficiently to address (1). Or we could have multi-layer NAT. Regards, -drc ------------------------------ Message: 6 Date: Sat, 03 Apr 2010 14:49:57 -0700 From: Zaid Ali <zaid(a)zaidali.com> Subject: Re: legacy /8 To: <frnkblk(a)iname.com>, <nanog(a)nanog.org> Message-ID: <C7DD0615.2C578%zaid(a)zaidali.com> Content-Type: text/plain; charset="ISO-8859-1" They are not glowing because applications are simply not moving to IPv6. Google has two popular applications on IPv6, Netflix is on it way there but what are other application companies doing about it? A popular application like e-mail is so far behind [ref: http://eng.genius.com/blog/2009/09/14/email-on-ipv6/] and I still encounter registrar's providing DNS service not supporting Quad A's. I feel talking to network operators is preaching to the choir, the challenge is helping content providers think about moving to IPv6. <Sarcasm>I think we will only see success once we are able to successfully work with content providers but they are quite busy now building real technology like the "Cloud" </Sarcasm> Zaid On 4/3/10 2:22 PM, "Frank Bulk" <frnkblk(a)iname.com> wrote: > If "every significant router on the market" supported IPv6 five years ago, > why aren't transit links glowing with IPv6 connectivity? If it's not the > hardware, than I'm guessing it's something else, like people or processes? > > Frank > > -----Original Message----- > From: Michael Dillon [mailto:wavetossed@googlemail.com] > Sent: Saturday, April 03, 2010 1:07 PM > To: Larry Sheldon > Cc: nanog(a)nanog.org > Subject: Re: legacy /8 > >> Not often you hear something that has changed just about every aspect of >> life and enabled things that could not be imagined at its outset ?called >> a failure > > Sounds like you are describing the Roman Empire. It failed and that's why > we now have an EU in its place. > > Things change. Time to move on. > > IPv4 has run out of addresses and we are nowhere near finished GROWING > THE NETWORK. IPv6 was created to solve just this problem, and 10 years > ago folks started deploying it in order to be ready. By 5 years ago, every > significant router on the market supported IPv6. Now that we actually need > IPv6 in order to continue network growth, most ISPs are in the fortunate > position that their network hardware already supports it well enough, so > the investment required is minimized. > > --Michael Dillon > > ------------------------------ Message: 7 Date: Sun, 4 Apr 2010 10:45:00 +0930 From: Mark Smith <nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Subject: Re: legacy /8 To: "George Bonser" <gbonser(a)seven.com> Cc: nanog(a)nanog.org Message-ID: <20100404104500.1c7b6d49(a)opy.nosense.org> Content-Type: text/plain; charset=US-ASCII On Sat, 3 Apr 2010 11:25:48 -0700 "George Bonser" <gbonser(a)seven.com> wrote: > > > > -----Original Message----- > > From: Larry Sheldon [mailto:LarrySheldon@cox.net] > > Sent: Saturday, April 03, 2010 10:54 AM > > Cc: nanog(a)nanog.org > > Subject: Re: legacy /8 > > > > > > That is the parachute's fault? > > > > Really? > > -- > > > No. But that isn't the point. The point is that v6 was a bad solution > to the problem. Rather than simply address the address depletion > problem, it also "solves" a lot of problems that nobody has while > creating a whole bunch more that we will have. Ever used IPX or Appletalk? If you haven't, then you don't know how simple and capable networking can be. And those protocols were designed more than 20 years ago, yet they're still more capable than IPv4. I used to teach Novell CNE courses around the mid 90s. Of the 7 courses, one of them was a two day course on a networking protocol. That networking protocol *wasn't* IPX - it was TCP/IP. IPX just worked, but you had to spend two days explaining TCP/IP. Even though I'd been using TCP/IP for a number of years before then, it still to me 5 attempts at teaching that course before I was completely happy with how I'd explained subnets, and had that feedback from students. I think IPv6 has not just learnt from the history of IPv4, it has also learnt from the history of other protocols. > Rather than simply > address the problem that was on the horizon, the group took the > opportunity to complicate it with a lot of other contraptions and saw > that as being a "good thing" that apparently we and the vendors are just > too dumb to realize or something. And they made v4 incompatible with v6 > rather really addressing the problem. They saw simply extending the > header with additional address bits to be a "bad thing" for some reason > when that is really all that was needed and so they went on building > their mousetrap and we have the mother of all internet protocols that > slices and dices and even makes Julien fries when all we needed was a > bigger potato peeler. > > I am not saying we can change it at this point but I am saying we should > learn from it and never, ever, do things this way again. > > > > > > > ------------------------------ Message: 8 Date: Sun, 4 Apr 2010 10:46:14 +0930 From: Mark Smith <nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Subject: Fw: legacy /8 To: NANOG List <nanog(a)nanog.org> Message-ID: <20100404104614.6bff3a1a(a)opy.nosense.org> Content-Type: text/plain; charset="us-ascii" Hi, Vint Cerf kindly sent through some more explanation. Regards, Mark. Begin forwarded message: Date: Sat, 3 Apr 2010 08:17:28 -0400 From: Vint Cerf <vint(a)google.com> To: Mark Smith <nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Cc: Andrew Gray <3356(a)blargh.com>, NANOG List <nanog(a)nanog.org> Subject: Re: legacy /8 When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint On Fri, Apr 2, 2010 at 10:42 PM, Mark Smith < nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > On Fri, 02 Apr 2010 15:38:26 -0700 > Andrew Gray <3356(a)blargh.com> wrote: > > > Jeroen van Aart writes: > > > > > Cutler James R wrote: > > >> I also just got a fresh box of popcorn. I will sit by and wait > > > > > > I honestly am not trying to be a troll. It's just everytime I glance > over > > > the IANA IPv4 Address Space Registry I feel rather annoyed about all > those > > > /8s that were assigned back in the day without apparently realising we > > > might run out. > > > > > > It was explained to me that many companies with /8s use it for their > > > internal network and migrating to 10/8 instead is a major pain. > > > > You know, I've felt the same irritation before, but one thing I am > wondering > > and perhaps some folks around here have been around long enough to know - > > what was the original thinking behind doing those /8s? > > > > I understand that they were A classes and assigned to large companies, > etc. > > but was it just not believed there would be more than 126(-ish) of these > > entities at the time? Or was it thought we would move on to larger > address > > space before we did? Or was it that things were just more free-flowing > back > > in the day? Why were A classes even created? RFC 791 at least doesn't > seem > > to provide much insight as to the 'whys'. > > > > That's because RFC791 is a long way from the original design > assumptions of the Internet Protocols. > > "A Protocol for Packet Network Intercommunication", Vinton G. Cerf and > Robert E. Kahn, 1974, says - > > "The choice for network identification (8 bits) allows up to 256 > distinct networks. This size seems sufficient for the foreseeable > future." > > That view seems to have persisted up until at least RFC761, January > 1980, which still specified the single 8 bit network, 24 bit node > address format. RFC791, September 1981, introduces classes. So > somewhere within that period it was recognised that 256 networks wasn't > going to be enough. I'm not sure why the 32 bit address size was > persisted with at that point - maybe it was because there would be > significant performance loss in handling addresses greater than what > was probably the most common host word size at the time. > > If you start looking into the history of IPv4 addressing, and arguably > why it is so hard to understand and teach compared to other > protocols such as Novell's IPX, Appletalk etc., everything that has been > added to allow increasing the use of IP (classes, subnets, classless) > while avoiding increasing the address size past 32 bits is a series of > very neat hacks. IPv4 is a 1970s protocol that has had to cope with > dramatic and unforeseen success. It's not a state of the art protocol > any more, and shouldn't be used as an example of how things should be > done today (As a minimum, I think later protocols like Novell's IPX and > Appletalk are far better candidates). It is, however, a testament to how > successfully something can be hacked over time to continue to work far, > far beyond it's original design parameters and assumptions. > > (IMO, if you want to understand the design philosophies of IPv6 you're > better off studying IPX and Appletalk than using your IPv4 knowledge. > I think IPv6 is a much closer relative to those protocols than it is to > IPv4. For example, router anycast addresses was implemented and used in > Appletalk.) > > Possibly Vint Cerf might be willing to clear up some of these questions > about the origins of IPv4 addressing. > > Regards, > Mark. > >

1 0

Auto MDI/MDI-X + conference rooms + bored == loop
by Chuck Anderson 05 Apr '10

05 Apr '10

Anyone have suggestions on Ethernet LAN loop-prevention? With the advent of Auto MDI/MDI-X ports on switches, it seems way too easy to accidentally or maliciously create loops between network jacks. We have bored or inattentive people plugging in patch cords between adjacent network jacks. STP for loop-prevention isn't working so well for us. STP "edge" or "portfast" or "faststart" modes are required for end-station ports (with normal STP, DHCP often times out after 30+ seconds it takes to go into Forwarding state). Since the "edge" STP mode goes into Forwarding state immediately, there is a period when loops will form, causing havok with upstream gear until STP blocks the port (if it ever does see below). "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet switches. Apparently, many of them don't do any kind of STP at all. Recommendations on ones that do STP? RSTP: is it any better than traditional STP in regards to "edge" ports and blocking before a loop gets out of hand? Or perhaps blocking for 5-10 seconds before going into Forwarding state, hopefully preventing loops before they happen but also allowing DHCP clients to get an address without timeouts? Recommendations on "Desktop" switches that do RSTP? Thanks for your suggestions/discussion. -- - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/)

12 20

Re: what about 48 bits?
by msokolov＠ivan.Harhan.ORG 05 Apr '10

05 Apr '10

Mark Smith <nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > Has anybody considered lobbying the IEEE to do a point to point version > of Ethernet to gets rid of addressing fields? [...] > Actually the minimum 64 byte packet size could probably go too, as that > was only there for collision detection. And maybe rename it to something else while you are at it? All those people who have hijacked the name "Ethernet" for PtP links (all those "Ethernet" UTP media are really PtP at the physical level, unlike real coaxial Ethernet) are despicable thieves - now those of us who are still using the original coaxial Ethernet in the shared bus mode are left without a clear, unique and distinctive name we once had to refer to what we use. MS

5 5

What is "The Internet" TCP/IP or UNIX-to-UNIX ?
by IPv3.com 05 Apr '10

05 Apr '10

What is "The Internet" TCP/IP or UNIX-to-UNIX ? As of 2010, many people would likely answer that question based on the Services they use as opposed to a religious adoration for TCP/IP. What if TCP is removed ? and IP is completely re-worked in the same 160-bit foot-print as IPv4 ? Would 64-bit Addressing last a few years ? IPv6 is a loser because everyone has to carry the overhead of bloated packets. It is a one-size-fits-all take it or leave it solution. People leave it. The real (new?) need is ONE-WAY streaming to carry ATSC to HDTVs. That can be done with 64-bit addressing in an IPv4 footprint. The Destination Address is most critical to deliver the AV show to the right viewer. IPv6 is too little, too late, in too big a package and at a high price. UNIX-based CPE is now under $50. Anyone can download the complete open source and all the tools to build it. http://www.linksysbycisco.com/gpl UNIX-to-UNIX Service-Based solutions pre-date many ARPA DARPA DOD funding programs run by people who do not write code, they write contracts and purchase orders. What is "The Internet" TCP/IP or UNIX-to-UNIX ?

21 39