Like I said, I can't think of any objective reason to not like it.
------ Original Message ------
From: "Jesse DuPont" <[email protected]>
To: "Adam Moffett" <[email protected]>; [email protected]
Sent: 2/1/2017 1:41:28 PM
Subject: Re: [Telrad] Setting up EPC
In the end, with the ports in the router/switch being full duplex, does
it really matter if the traffic hairpins a single port vs in one and
out another? Aren't the bits still traversing the same chip (if
hardware switched/routed) or same CPU (if software switched/routed) and
has access to the same overall bus capacity (that is, single gig port
or two gig ports, still only 1 Gbps in any single direction)?
Jesse DuPont
Network Architect
email: [email protected]
Celerity Networks LLC
Celerity Broadband LLC
Like us! facebook.com/celeritynetworksllc
Like us! facebook.com/celeritybroadband
On 2/1/17 9:14 AM, Adam Moffett wrote:
Yes, the hairpinning is unavoidable with single-port. Great
description by the way. It never sat right with me, but I don't have
an objective reason to not like it.
Personally I'm going to populate the SFP+ slot and use a single 10G
fiber.
------ Original Message ------
From: "Nathan Anderson" <[email protected]>
To: "[email protected]" <mailto:[email protected]> <[email protected]>;
"Tristan Johnson" <[email protected]>
Sent: 1/31/2017 9:48:55 PM
Subject: Re: [Telrad] Setting up EPC
The single-port method is what Telrad recommends for centralized EPC
deployments, and multi-port is (the way I read the docs) only
recommended/intended for EPC-at-each-site deployments. (You can make
it work with centralized EPC, but there are many indicators that this
feature was never intended to work this way.)
But the single-port method will inevitably always have some traffic
hairpinning occur, which is the main reason why I don't like it. It
doesn't matter if you are routing or bridging between your Compacts
and your BreezeWay: the user traffic comes in on the PDN VLAN to the
EPC, then gets encapsulated in GTP by the EPC, and finally gets
turned right back around on a different VLAN and sent back out the
exact same port on its way to the ENB.
So not only does the traffic cross that particular ethernet port
twice on the EPC, but assuming that you have your EPC plugged
directly into a router as we do, the same traffic from the internet
to your users will traverse your PDN router on at least three ports:
once coming from the internet, twice going-and-coming to/from the
EPC, and then once more on its way out to an ENB. This traffic flow
wouldn't look any different regardless of whether you are trying to
route between EPC and ENBs or bridge/switch.
In your (Tristan's) case, I am a little confused by your description.
If I understand you correctly, you have a switch physically located
close to the WIB that you have the EPC plugged into, then a Mimosa
path to a site somewhere where you have another router and
(presumably) one or more ENBs, and you have the gateway addresses for
the management and bearer VLANs sitting not on your WIB but on the
router that sits at the other end of the Mimosa path. Do I have that
correct?
If that's right, you presumably have the WIB and the close end of the
Mimosa path plugged into the same switch with the EPC, and then have
the VLANs trunked like this:
WIB port on switch: PDN VLAN tagged
EPC port on switch: PDN, Mgmt, and Bearer VLANs tagged
Mimosa port on switch: Mgmt and Bearer VLANs tagged
With that arrangement, presuming that at the remote site the ENB is
also being trunked the management and bearer VLANs directly, it
matters not one whit which router on your network you put the .1 (or
whatever) addresses on for the management and bearer subnets. In
fact, you could get away with not putting those addresses on any
router, and not even bothering to set the next-ip-gateway for the
'bearer' and 'external-management' network configs on either the EPC
or ENB. It would all still work since the EPC and ENBs are all
talking to each other over the same ethernet broadcast domain.
This isn't an entirely bad set-up, either, because the WIB never sees
anything but the PDN traffic, and the only device that encounters the
traffic hairpinning is the switch that the EPC is plugged into. But
since it's a switch (and presumably a modern-enough one), it is
non-blocking / has enough backplane capacity for all ports to be
moving their rated speed in each direction simultaneously. So, who
cares.
Now, if I've misunderstood and you actually both want and are working
to achieve a routed set-up, and the bearer interfaces of each ENB
will be in their own subnet(s) apart from the bearer subnet on the
EPC, then where the gateway address sits for the EPC's bearer subnet
will of course matter and have an effect on the flow of traffic
between it and the ENBs.
-- Nathan
From:[email protected] [mailto:[email protected]] On
Behalf Of Jeremy Austin
Sent: Tuesday, January 31, 2017 3:40 PM
To: Tristan Johnson; [email protected]
Subject: Re: [Telrad] Setting up EPC
Tristan, this fits into the discussion Nathan and I were having --
I'm currently using the single port method, and he is not.
>From what I can tell, Bearer traffic will use the bearer gateway,
and management traffic will use the management gateway.
I do not believe that there is any doubling back, so to speak. There
are some firewall rules that Nathan can describe in greater detail,
much of which you can find in the list archives.
I have been finding radically different iperf behavior when testing
the EPC's management interface directly on L2 vs. L3. I do not yet
know whether this dichotomy affects bearer traffic; if anyone can
confirm that would be awesome, as Telrad design docs appear to
support both setups.
I am possibly leaning toward Nathan's topology of porting all ENB
traffic back over VPLS, as I already have a full MPLS stack
available.
On Tue, Jan 31, 2017 at 11:59 AM Tristan Johnson
<[email protected]> wrote:
Hey guys,
Working on getting our Telrad test gear going after, um, a couple
years now. (long waits and contract failures at some tower sites
perfect for LTE).
I've been working on getting the EPC working, and we do have our EPC
and EnB set up and functional. But, I'm curious if I have this
configured in the most effective and efficient way.. I'll be
perfectly honest, I'm not a switch guru, or VLAN man. I've routed
from day one, and never really used VLANs (strange as it may be). So
we have an OSPF routed network, and I'm trying to put the EPC at our
head end. It goes something like this.
(AZOTEL WIB router w/PDN vlan and another subnet for BH traffic from
the rest of our network) ---> Switch --> Mimosa radio pair
-->Another router with BH taffic IP, VLAN for EPC bearer, and VLAN
for EPC managment, with default route to Azotel WIB. EPC is plugged
in to switch with bearer and management pointing to far router, and
PDN VLAN pointing to WIB.
If you can follow that, my question revolves around how the EPC uses
ONE port to move all of it's traffic around, and if our traffic is
actually going to where it's supposed to without having to double
back. Say bearer traffic going to the WIB then to the EPC because of
the default route at that far router.
Or should all EPC VLANs terminate at the WIB?
I ask mainly because we have seen some inconsistent speed tests, and
when I do a traceroute to the EPC from that far router I get a
failed hop in between the router and the EPC in the list of 3 hops
(which I wouldn't expect to be 3 anyway). There is just some
strangeness.
Thanks,
Tristan Johnson
Owner
www.wirelessdatanet.net <http://wirelessdatanet.net>
309-893-4152
--------------------------------------------------------------------------------
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
This email has been checked for viruses by Avast antivirus software.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
_______________________________________________
Telrad mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/telrad
_______________________________________________ Telrad mailing list
[email protected]http://lists.wispa.org/mailman/listinfo/telrad
_______________________________________________
Telrad mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/telrad
