I may be misunderstanding you, but depending on what exactly you are trying to do, this isn't 100% accurate, although given the limitations imposed on the EPC's built-in switch, it is close enough.
It actually IS possible to have bearer tunnel traffic not flow in and out of the same ethernet port on the EPC as PDN traffic: you have to configure "set switching vlan-assignment epc-access-if-list" in order to accomplish this. Unlike epc-network-if-list, epc-access-if-list can actually include more than one port in the list. epc-network-if-list must always be defined; epc-access-if-list is optional. epc-access-if-list was really only intended to be used in the distributed/local EPC model, where you plug one or more Compacts directly into an EPC. You actually don't *have* to use it that way: you can plug multiple Compacts into a switch, and then plug that switch into just one of the ports in the epc-access-if-list. There is thus also no reason why the EPC and the Compact or Compacts it is serving all have to be physically located together at the same site. However, epc-access-if-list does have some severe restrictions placed on it, which makes it inconveient to use for anything other than its stated purpose: 1) The EPC seems to employ some kind of split-horizon-esque forwarding among all of the ports listed in the epc-access-if-list. So, a Compact plugged into one of the access-if ports cannot talk to a Compact plugged into another access-if port, although they can both talk to the EPC itself. 2) The bearer and external-management VLANs continue to be exposed on the network-if port, along with all PDN VLANs. Which is good and makes sense, because you still need to be able to manage the Compacts, and as has already been established (#1 above), forwarding between access-if ports is blocked, so you can't manage them via another access-if port. However, the EPC appears to filter out any and all multicast traffic sent to the bearer or external-management VLANs via the network-if port, which closes some doors / makes certain network topologies impossible. 3) Although the EPC will forward external-management traffic (with the exception of multicast) between the network-if port and the access-if ports, it will not respond to its own configured external-management IP address via one of the access-if ports, only via the network-if port. Again, this closes certain doors and also prevents you from managing an EPC in the event that it becomes unreachable on your network via the single network-if port. In our case, we wanted to configure two centralized geographically-diverse redundant EPCs with redundant PDN gateways side-by-side with them, using VRRP to control failover between the two gateways, and have all bearer traffic arrive at the EPCs directly via access-if ports. These restrictions to the access-if feature ended up making it impossible to do this the way that we wanted to. VRRP uses multicast heartbeats, so the multicast filtering broke VRRP for the bearer and management gateway addresses. Even if that wasn't a factor, the fact that an EPC does not respond to its management IP on an access-if port means that if one of the gateways died, we would stop being able to manage the EPC paired to that gateway or get any BreezeView data from that EPC for the duration of the outage (although bearer traffic would continue to flow just fine to the alternate gateway, so at least there wouldn't be a customer outage). Finally, because we were forced to continue to use just a single network-if port on each EPC for everything on account of these problems, we had to implement some hacky scripts on the two gateways (MikroTiks) that toggle some of the VRRP interfaces on and off under certain conditions (we were hoping that in the event of EPC death, we could just count on the path between the two gateways being physically severed, and then let VRRP do its thing, but not anymore...). And that's beside the fact that it is my personal opinion that just using one port for everything, when the hardware has all of these ports available, seems terribly inefficient (the traffic hairpinning between bearer and PDN on the same port will only serve to more quickly accelerate the need for us to implement LAG or move to 10gig). We tried to talk to Telrad about these issues, but got nowhere, and I just gave up trying. In fairness, Nick wasn't the one who got the ticket, and it really felt like there was a language barrier issue between myself and the fellow I was trying to explain our needs and concerns to. You are definitely correct, however, that even though it is technically possible to split the bearer traffic off to its own port(s), it is not possible, as far as I can tell, to split multiple PDNs across discrete ports. All traffic for all PDNs must flow out the single network-if port. At the end of the day, I think what I would really like to see is just more flexibility allowed in defining the switching config on the EPC. I suspect Telrad went the route that they did with this to keep things simple and reduce potential support headaches. And being able to get away with configuring your ports with only a couple of commands is definitely simple, I'll give you that! (In fact, from what I can tell by reading older draft copies of the EPC manual, it was slightly more flexible initially, but then they changed over to what we see today.) -- Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Shayne Lebrun Sent: Sunday, November 20, 2016 1:07 PM To: [email protected] Subject: Re: [Telrad] Issues The EPC considers itself to have one virtual Ethernet port, with one or more physical ports attached to it. You can’t have, say, physical port 1 on the EPC accepting bearer tunnels while port 2 outputs customer data on vlan 20, port 3 outputs different customer data on vlan 21, and so on. You should be able to have the EPC plugged into one trunk port on your switch, with the vlans then broken out by the switch into separate ports heading further upstream, though. The official Telrad method of eliminating the EPC as a point of failure, as far as I can tell, is to have multiple EPCs. I’m not sure, off hand, what methods the eNBs support to determine which EPC use; i.e. always use the primary unless it’s gone, straight round robin, etc. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jeremy Austin Sent: Sunday, November 20, 2016 1:02 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. It is always a relief to finally isolate problems like this. We experienced something very odd when we moved an EPC from being directly connected to a router to being connected via a switch, with separate ports for bearer, management, and PDN. Even with no overlapping port VLANs on the switch, the EPC refused to work when connected via a switch, and we had to consolidate VLANs to one port. Apparently that was an unsupported configuration. We'll do a LAG for all trunks when that is available. In a perfect world we could do multiple LAGs, one to each of two separate switch/router combos, to eliminate SPOF… -- Jeremy Austin (907) 895-2311 (907) 803-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
