Well now you've got me curious. We have a second BreezeWay that we intend to use as a geographically-redundant EPC, but we haven't gotten around to putting it into full service yet (we didn't even have all of our ENBs running 6.6 until relatively recently, and that was a prerequisite for the primary/secondary S1 redundancy feature). I can't reconfigure our primary EPC for non-"epc-access-if-list" mode on a whim as that would be extremely disruptive, but I am seriously considering putting our other BreezeWay into single-port mode in order to try running some iperf tests over the management VLAN, and see if my memory on this issue is correct.
LAGs I believe have been supported for the epc-network-if-list port for quite some time (since first GA release I'm almost sure), and I *believe* that they are also supported for epc-access-if-list ports, but don't hold me to that. Even if they were, though, I have no intention of configuring one since as far as I can tell, LAGs are strictly statically defined and there is no LACP support. (I might change my tune on LAGs once we start topping out 1Gbit/s on user traffic, though; heh.) Maybe I'm overthinking things, but I would be concerned about having a network partition event downstream of one port or the other that wouldn't affect the link state of that port on the BreezeWay. Thus LAGs without LACP can't really be (effectly) used for proper L2 redundancy, just for doubling traffic capacity. I would love to see LACP support come to the BreezeWay someday, but I have no idea if it is even on the roadmap... Correct, we don't have any recorded test results of routed vs. bridged iperf between ENB and EPC. At one point when we were struggling with that damned RB1100 switch chip issue (without knowing yet what was at fault), we tried routing traffic to one of our ENBs instead to see if that helped at all...the suspicion at the time was that VPLS itself was possibly the cause of our performance woes, so we were trying to remove it from the equation. As I recall, performance to that ENB was comparable before vs. after: switching to pure routing made effectively zero difference. We do have a spare Compact on the ground (for when a production one flames out and we need to replace it in an emergency), and I could *probably* do the same thing with it and put a couple of routers in between it and our EPC. I'm trying to think through whether that would even work with epc-access-if-list defined... Anyway, feel free to send me your results. I'll see what I can do on my end to set up a "lab"-ish environment using our spare EPC and ENB (or both). -- Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Austin Sent: Monday, January 30, 2017 8:41 PM To: [email protected] Subject: Re: [Telrad] Issues On Mon, Jan 30, 2017 at 6:38 PM, Nathan Anderson <[email protected]<mailto:[email protected]>> wrote: ...though I should warn you that we are using epc-access-if-list as detailed in past posts of mine, so we are unable to have our ENBs talk to our EPC over the management VLAN. Thus we can only run iperfs between ENB and EPC over the S1 VLAN, which isn't something you can normally do (due to iptables filter rule installed by Telrad on EPC side). I had intended to use epc-access-if-list, but I wasn't able to make that work and still have L2 redundancy. I might have missed something obvious? Honestly I'd be fine with a LAG, but I wasn't 100% sure it is supported yet. (Or better yet, a 10G interface.) I am pretty sure that that filter rule wasn't there previously (probably in initial 6.5 release), and although I cannot recount the details, I also seem to recall that we saw significant differences between iperf tests over the management VLAN and iperf tests over the S1 VLAN. I want to say the tests over the management VLAN were notably worse, and since we knew traffic between devices was not running over that VLAN anyway, we didn't care and discounted those results. At the time I figured that Telrad had optimized for performance over the S1 VLAN somehow at the expense of the management one; nothing else could make sense of the difference. Because we're using L3 EPC<>ENB and the VLANs are only relevant at the last hop, I was assuming that performance would be the same on mgmt vs. S3. And Telrad did iperf testing on my network *using management*, and those were the results I was trying to replicate. So if I understand you correctly, you haven't tested iperf to management on both L2 and L3? This would have to be contrasted with S1 (again, L2 and L3), which you can't do with your setup. We also switch (well, okay, VPLS) all traffic between ENBs and the EPC so (from the ENB and EPC's perspective) there is no L3/routed infrastructure sitting between them. So the way we have our network set up may not be an apples-to-apples comparison with yours. I'm leaning toward this topology, unless S1 routed performance is identical to switched — but this isn't what Telrad tested! What Telrad was trying to prove was that S1/backhaul performance is inadequate and causing some performance issues. I was unconvinced, as the results were significantly poorer than router-to-router testing. And in attempting to replicate them, I discovered that iperf using management is radically different on L3 vs L2. -- Nathan From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Nathan Anderson Sent: Monday, January 30, 2017 7:21 PM To: [email protected]<mailto:[email protected]> Subject: Re: [Telrad] Issues Oh I see, gotcha. Happy to help off-list if that's where you want to take it. -- Nathan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jeremy Austin Sent: Monday, January 30, 2017 7:19 PM To: [email protected]<mailto:[email protected]> Subject: Re: [Telrad] Issues Nathan, I can send you more details off list. I should have been clearer; I'm getting different results when testing iperf on L2 to the EPC management network vs. L3 to management, even when taking bandwidth delay product into account. Thanks... more later. On Mon, Jan 30, 2017 at 6:08 PM Nathan Anderson <[email protected]<mailto:[email protected]>> wrote: Can you detail your specific results? I'll try to run some iperfs between our ENBs and EPC so we can compare to yours, but we are not doing L2 PDNs so not sure how much help we can be there. -- Nathan From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Jeremy Austin Sent: Monday, January 30, 2017 7:01 PM To: [email protected]<mailto:[email protected]> Subject: Re: [Telrad] Issues On Sun, Nov 20, 2016 at 2:13 AM, Nathan Anderson <[email protected]<mailto:[email protected]>> wrote: Which again leaves us at square one as far as explaining what is going on, but at least we now have a working solution. So, huzzah for that. Ever since moving the EPC trunk port to a different port on our LTE core router, I have been able to do 60Mbit/s single-stream TCP tests to UEs that are multiple hops out on our microwave backbone. I have NEVER been able to accomplish this before, much less consistently. I think that using the word "giddy" here to explain our disposition ever since we made this discovery would be a vast understatement. To revisit an older thread, has anyone else done iperf tests between ENB and EPC and found a bottleneck that wasn't a backhaul? I'm getting radically different L2 vs. L3 results, and it does seem to be narrowed down to the EPC. S1 and PDNs are on the same switch port. -- Jeremy Austin (907) 895-2311<tel:(907)%20895-2311> (907) 803-5422<tel:(907)%20803-5422> [email protected]<mailto:[email protected]> Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC Schedule a meeting: http://doodle.com/jermudgeon _______________________________________________ Telrad mailing list [email protected]<mailto:[email protected]> http://lists.wispa.org/mailman/listinfo/telrad _______________________________________________ Telrad mailing list [email protected]<mailto:[email protected]> http://lists.wispa.org/mailman/listinfo/telrad -- Jeremy Austin (907) 895-2311<tel:(907)%20895-2311> (907) 803-5422<tel:(907)%20803-5422> [email protected]<mailto:[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
