Scott, Actually, I originally missed the part about "mikrotik router". We don't use Mikrotik routers currently, as they can not accommodate us loading our custom management software code. But all our servers are Linux based, so can likely do anything that Mikrotik can, (with a little bit of effort).
Butch was suggesting using PPTP. I need to double check that we have a PPTP package loaded on our routers, and if not, load one first. (I could always get a MT box to do the tunnel, and just allocate an Ethernet port on my Linux router to it, but I'd need to procure a MT unit first. ) I agree, at minimum, it would be a fun experiment,with no disadvantage. We have plenty of free bandwidth. We should probably take this offlist, at this point. We can always share the results with the list, after the fact. Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband ----- Original Message ----- From: "Scott Carullo" <sc...@brevardwireless.com> To: "WISPA General List" <wireless@wispa.org> Sent: Sunday, April 26, 2009 6:58 PM Subject: Re: [WISPA] Interesting BGP Redundancy Opton for FREE > > Hello again... > > I didn't specify comcast but in the context of our discussion it doesn't > matter much :) > > Tom... Lets just do a test from your network to mine. A learning > experience if nothing else - can't go wrong there. > > I've never heard of CIPE but I assure you that MT has no problem > whatsoever > passing traffic from anyone over a tunnel between us, I think you are hung > up on something that is a non-issue and what Butch mentioned was not about > over one's own network - he understood that it was from some end user > provider to another with multiple possible ISPs in the middle... its a > mute point who's in the middle really with whats being proposed and how it > works. > > I have a router ready to go, you? Latency between us is good, less than > 30ms. I 60MB on any given day/time still available not doing anything, > usually a little more. > > Scott Carullo > Brevard Wireless > 321-205-1100 x102 > > -------- Original Message -------- >> From: "Tom DeReggi" <wirelessn...@rapiddsl.net> >> Sent: Sunday, April 26, 2009 6:49 PM >> To: "WISPA General List" <wireless@wispa.org> >> Subject: Re: [WISPA] Interesting BGP Redundancy Opton for FREE >> >> Butch, >> >> You completely missed my point, ot the background to the thread.. >> Of course "you" can build a tunnel of just about any MTU size on "your" >> network. >> The issue at hand is what max MTU size OTHER upstream ISPs allow on their > >> network. >> >> Scott was talkng about doing a tunnel accross an end user Comcast > circuit. >> With the open Internet, the two end point end users don't really have >> control of what ISPs in between gets traversed from End Point A to B. > The >> ISPs in the middle could chance at any time. This is not a new > problem.... >> >> For example.... A number of years back Universities built a "private" >> experimental transport network to support high MTU above 9600, so that > their >> GB and 10GB networks could pass full capacity. As you know, max transfer > >> rate is directly proportional to latency times packet size. Most common > ISPs >> only passed 1500MTU, therefore the Universities had to make their own > net. >> This has been a challenge for years for even passing VLAN tags or MPLS > data, >> where layer2 fiber carriers would only pass a 1512 packet. When you are > the >> end user, the answer is to shrink your MTU, so after the tunnel overhead > it >> fits into the ISP's max 1512 MTU. But when one is an tranport ISP that >> transports many customer's data, it is not appropriate for the ISP to > shrink >> his MTU below 1500, as all the other end users would not know that the > MTU >> was shrunk, and would not have their routers set to a smaller MTU to > fit. >> >> Sure you can allow fragmentation, and TCP will automatically split the >> packets to fit, but it has been common ISP management practice to > disallow >> fragmentation for various reasons that I don't want to get into in this >> thread. And yes, there is MTU autolearning, but again, not supported by >> everyone or all protocols. >> >> So sure, the ISP can make a tunnel setting a lower MTU, so after tunel >> overhead, it will fit in the uipstream's 1512 MTU. But then full size >> packets (because packets comming from end user customers will be 1512 > size) >> inside the tunnel will get fragmented to fit into the tunnel. For long > haul >> backhauls, there can be side effects of just simply allowing > fragmentation >> on the routers without any further consideration. >> >> Again, we have a good solution for this... It is called CIPE. Its a >> tunneling protocol that splits the packets appropriately for optimal >> efficiency. I understand how CIPE works because it is what we use. I > can't >> say I understand the methods that Mikrotik may use. So, what I asked is > how >> Mikrotik can deal with that problem, because Mikrotik does not support > CIPE. >> >> >> Tom DeReggi >> RapidDSL & Wireless, Inc >> IntAirNet- Fixed Wireless Broadband >> >> >> ----- Original Message ----- >> From: "Butch Evans" <but...@butchevans.com> >> To: "WISPA General List" <wireless@wispa.org> >> Sent: Friday, April 24, 2009 11:03 PM >> Subject: Re: [WISPA] Interesting BGP Redundancy Opton for FREE >> >> >> > On Fri, 2009-04-24 at 19:37 -0400, Tom DeReggi wrote: >> >> Over a Layer2 PTP its usually not an issue, but it is over a standard >> >> transit connection. >> >> (customer and Internet needs to see 1500 bytes, but an ISP's tunnel >> >> causes >> >> packet size to exceed 1500 MTU. >> > >> > I have built tunnels that carry 12000 byte packets. Not sure where > this >> > idea comes from. They can be built that will carry as much as 65k >> > bytes. >> > >> >> We use Cipe tunnels to solve that. To split the full size packets > before >> >> it >> >> enters the tunnel, so tunnel stays at 1500MTU or less, required by > the >> >> transit provider.. >> >> >> >> How do you do it with Mikrotik ? >> > >> > Of the tunnels I've done with MT, you just use PPtP and set the MRRU >> > (just like your tunnels). I've done this with standard Linux, too. > It >> > is actually quite an elegant solution. >> > >> > -- >> > ******************************************************************** >> > * Butch Evans * Professional Network Consultation* >> > * http://www.butchevans.com/ * Network Engineering * >> > * http://www.wispa.org/ * WISPA Board Member * >> > * http://blog.butchevans.com/ * Wired or Wireless Networks * >> > ******************************************************************** >> > >> > >> > >> > >> > > ---------------------------------------------------------------------------- > ---- >> > WISPA Wants You! Join today! >> > http://signup.wispa.org/ >> > > ---------------------------------------------------------------------------- > ---- >> > >> > WISPA Wireless List: wireless@wispa.org >> > >> > Subscribe/Unsubscribe: >> > http://lists.wispa.org/mailman/listinfo/wireless >> > >> > Archives: http://lists.wispa.org/pipermail/wireless/ >> >> >> >> > ---------------------------------------------------------------------------- > ---- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> > ---------------------------------------------------------------------------- > ---- >> >> WISPA Wireless List: wireless@wispa.org >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ > > > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
