28 Oct
2015
28 Oct
'15
2:38 p.m.
On Tue, Oct 27, 2015 at 04:50:37PM +0100, Andreas Schultz wrote:
Indeed.
Thanks a lot for clarifying this!
In pratice that means I simply cannot simulate several GSNs on the same IP
address, because each wants to hog ports 2123 and 2152... Even if the
secondary GSNs are just netcats, the first GSN would send to itself. To
enable a test setup like this, I would need some non-standard config
option, but that would compromise the meaning of the test. Well then.
Which brings us back to OpenGGSN: it doesn't heed these specs! OpenGGSN
always does reply back to where things came from. When I configure gtphub
to listen on and also send GTP-C from port 2222, OpenGGSN happily plays
along and replies GTP-C to port 2222. I *can* have gtphub and OpenGGSN on
the same IP address, just tested that it works.
So anyone using OpenGGSN probably uses ports 2123 and 2152 merely by
incidence, because the SGSN side happens to send from these ports, too.
If an SGSN picked a separate sending port, OpenGGSN would stop working.
I presume that's a fail on OpenGGSN's side, not a choice, right?
And this shows that users up to now don't seem to pick separate sending
ports, kind of making the use of exactly the ports 2123 and 2152 for both
sending and receiving a de facto standard...?
Thanks again!
~Neels
In 3GPP TS 29.060 version 12.9.0, the table of
information elements for
Create PDP Context Request does list SGSN Address for signalling AND
SGSN Address for user traffic, both are mandatory.
Wow, how did I not see that! Thanks!
Still learning my ways around GTP...
Section 4.4.2.0 General:
> For the messages described below, the UDP Source Port (except as specified
> for the Echo Response message) may be > allocated either statically or
> dynamically by the sending GTP-U entity.
Section 4.4.2.3 Encapsulated T-PDUs:
> The UDP Destination Port number shall be 2152. It is the registered port
> number for GTP-U.
This means the following situation is completely
valid:
GGSN (or gtphub)
SGSN 5.6.7.8
Ctrl: 1.2.3.4:111 -------> 2123
1.2.3.4:2123 <------- 5678
User: 4.3.2.1:222 -------> 2152
4.3.2.1:2152 <------- 9012
So SGSN and GGSN can pick any IP addresses independently for the two
planes, and they can *send from* any port they choose; but they must
always *listen* on precisely ports 2123 and 2152.
Meaning that even if gtphub received something from port 111 or 222, it
must discard that port information and reply on either 2123 or 2152.
Hyyypothetically, the GGSN could choose to reply to the port it received
from (111 or 222), which it actually does for Echos, but otherwise, that's
not how GTP do.
As fas as I understand, the GGSN would get these IEs:
* Tunnel Endpoint Identifier Control Plane + SGSN Address for user traffic
* Tunnel Endpoint Identifier Data I + SGSN Address for signalling
It would then reply with:
* GGSN Address for Control Plane + Tunnel Endpoint Identifier Control Plane
* GGSN Address for user traffic + Tunnel Endpoint Identifier Data I
Together this should transport all the information required to match
the tunnels.
Well, indeed... I see it now :)
Still, the
SGSN's port numbers could theoretically be chosen freely. The
GGSN knows the sender of the Ctrl packet(s), and as soon as a User packet
comes in from the same IP address, it also knows the User plane port. As
As pointed out earlier, the ports are no bidirectional. It is mandatory that
GTP-U receives at port 2152 and GTP-C v1 receives at 2123. The sending ports
can be chosen freely.