On Fri, Nov 4, 2016 at 6:30 PM, Nathan Anderson <[email protected]> wrote:
> Gotcha. > > > > You can't do this on the 8K, and it wouldn't solve all of your problems, > but with the 7K, you could set up a MikroTik L2TP BCP concentrator and have > your 7K establish BCP tunnels to that. Then your overheads would be 1496 - > L2TP headers (which I think is normally 40 bytes when using IPCP, but I > don't know what it looks like with BCP) instead of 74 bytes for S1 > overhead. Not full 1500, but you can emulate that to the end-user with > MRRU and having L2TP fragment the packets for you. > With the 7000s, that's exactly what I did — used a separate client and a tunnel type that could support fragmenting. > > > Oh, grr, scratch that, I just realized after typing that out that there is > no MRRU option on the 7K interface. Darn. > > > > It might still be educational to try this, just to see if your PPPoE > frames happen to make it through that tunnel. > > > > I really haven't experimented much with this stuff because we decided in > the end not to do bridging. This was back when my understanding was that > EPC-defined AMBRs meant that the EPC was working in concert with the eNB > TDMA scheduler for the most efficient means of controlling bandwidth, but > it is now unclear to me whether that is true. But even if setting the AMBR > on the EPC is no more efficient than using queues on a MikroTik upstream > from the EPC, it just seemed weird to contemplate requiring two levels of > authentication (SIM card, then PPP user/pass on top of that). > Tunnels definitely are a step backwards if you intend to do QOS — Randy Ortiz has been testing this lately, with good results. The only use case I have for this is small MDUs; I'm just starting to get more of them than I wish. And I can still keep the current architecture, which is a separate router, but the loss of GRE forwarding/DMZ with the 8000s has sent me back to the drawing board. I don't like the current workarounds. > > I'd still love to know how you end up making out on this. Please keep us > updated. > I'm surprised that nobody else has done it… everyone was waiting for native large MTUs I guess. > > > -- Nathan > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Jeremy Austin > *Sent:* Friday, November 04, 2016 7:10 PM > *To:* [email protected] > *Subject:* Re: [Telrad] Telrad Digest, Vol 25, Issue 1 > > > > > > On Fri, Nov 4, 2016 at 6:08 PM, Nathan Anderson <[email protected]> wrote: > > If you can get 1496-byte packets all the way to the UE's IP through the > EPC, then that shows (interestingly) that S1 traffic from EPC <-> eNB is > somehow not beholden to the MTU as-reported on the S1 VLAN (or on the > master interface for that matter), but that PDN traffic definitely is > restricted by that 1496 MTU. I'm guessing that Telrad would need to > release a software fix to increase the PDN VLAN MTU to 1500 or above to > work around that problem. > > > > That VPLS traffic seems to be constrained by the S1 VLAN MTU, even though > L3 traffic isn't, is also interesting. It must have something to do with > how VPLS is implemented on the EPC side...something is paying attention to > that MTU value set on that VLAN in certain scenarios but not in others. > Again, sounds like a software fix may be in order? > > > > What did Nick have to say when you talked to him on the phone? > > > > > My observations as well. > > > > Nick is evidently working on the same issues. Didn't hear from him today. > > > > -- > > Jeremy Austin > > > > (907) 895-2311 > > (907) 803-5422 > > [email protected] > > > > Heritage NetWorks > > Whitestone Power & Communications > > Vertical Broadband, LLC > > > > Schedule a meeting: http://doodle.com/jermudgeon > > _______________________________________________ > Telrad mailing list > [email protected] > http://lists.wispa.org/mailman/listinfo/telrad > > -- Jeremy Austin (907) 895-2311 (907) 803-5422 [email protected] Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC Schedule a meeting: http://doodle.com/jermudgeon
_______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad
