This DNS HOWTO assumes you have Googled the basic setup of your BIND service and master/slave deployment. We will only focus on the 3GPP aspect of the zone file and how you can use it with an ASR5000. The 3GPP specification 29.303 Annex A4.3(S10) Annex 4.11(S11 and S5), 23.003, RFC 2915, and RFC 3958(2.2.3) are the main references used in this HOWTO.
Below we show the basic header of a zone file and what each element is and how to use it.
- In the beginning you will see an $ORIGIN epc.mnc111.mcc222.3gppnetwork.org.
value. Every record in the zone file that does not end with a dot will automatically inherit the
$ORIGIN value. For example the record foobar does not contain a trailing dot so the BIND
service would read it as foobar.epc.mnc111.mcc222.3gppnetwork.org. On the other hand if the
record was foobar., BIND would read this as foobar and nothing else.
- Now the next item in the top of your zone file will be the TTL field. The TTL is sent to the DNS
client of the ASR5000 to let it know when the data expires and it need to do a new DNS query. Please
note this TTL value can be overwritten locally on the ASR5000 via the TTL command in the DNS client
- For the Start of Authority(SOA),
you can refer to the zone file snippet used for EPC below. Note that the email in dot form root is
just the root user for the system and will likely be different for your deployment.
@ IN SOA ns root (
1 ; Serial
3600 ; Refresh
30 ; Retry
3600 ; Expire
600 ) ; Negative Cache TTL
- Name Authority Pointer (NAPTR) for
us will only use two flag types (a & s) which is also called S-NAPTR or Straightforward-NAPTR. In S-NAPTR
you will see many service types which are all defined in 23.003 section 19.4.3 "Service and Protocol service
names for 3GPP". The first number in the S-NAPTR RR after the word NAPTR is Order and the second number is
Preference. Also note the existence of application service of "x-3gpp-sgw" & "x-3gpp-pgw" with their
corresponding application protocol of "x-s5-gtp". These service represents if its a SGW or PGW while the
S5 protocol means both node types support GTP based S5 and not PMIP. Note that since we have NAPTR with
flag type "s" for our TAI resolution and gw-selection is co-location, we will not use order or preference
in selection criteria unless we have multiple best matches in which case lowest order value will trump.
;TAI S-NAPTR ;TA which exist within the north or south ;North: tac-lb03.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._north tac-lb04.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._north ;South: tac-lb01.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._south tac-lb02.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._south ;APN NAPTR ;APN's which exist only on one PGW use NAPTR "a" flag ;North: apnName3.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName3.site3.north apnName4.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName4.site4.north ;South: apnName1.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName1.site1.south apnName2.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName2.site2.south ;Common APN on all PGW's use NAPTR "s" flag apnName.apn IN NAPTR 100 100 "s" "x-3gpp-pgw:x-s5-gtp" "" _nodes._pgw
- Service(SRV) records
give you the ability to load balance per weight and set destination port numbers in SRV record. The
first number in the SVR record after the word SRV is Priority and the second number is Weight
followed by port number. Note that when we have multiple best matches with equal order values in
the NAPTR results then we can use priority to tie break (lower better) and weight in the SRV
record to balance traffic if priorities were equal(more to add once R14 is released).
;SRV Records for SGW ;North _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName1.site1.north _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName2.site2.north _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName3.site3.south _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName4.site4.south ;South _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName3.site3.south _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName4.site4.south _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName1.site1.north _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName2.site2.north ;SRV Records for< PGW ;PGW, Equal weight for common apn's. TTL 1800. Port gtp-c v2 is 2123 _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName1.site1.north _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName2.site2.north _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName3.site3.south _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName4.site4.south
- A or AAAA are the final record pointing to the IP address of node.
;A records for PGW ;S5 address of PGWs that support GTP based S5 interfaces. topon.s5-pgw.nodeName1.site1.north IN A 18.104.22.168 topon.s5-pgw.nodeName2.site2.north IN A 22.214.171.124 topon.s5-pgw.nodeName3.site3.south IN A 126.96.36.199 topon.s5-pgw.nodeName4.site4.south IN A 188.8.131.52 ;A records for SGW ;S11 addresses of SGWs that support GTP based S5 interfaces. topon.s5-sgw.nodeName1.site1.north IN A 184.108.40.206 topon.s5-sgw.nodeName2.site2.north IN A 220.127.116.11 topon.s5-sgw.nodeName3.site3.south IN A 18.104.22.168 topon.s5-sgw.nodeName4.site4.south IN A 22.214.171.124
Below you will find basic MME configuration to support node selection plus
static selection in the event DNS/BIND is down or unreachable. The top element
in the structure is the
lte-policy/subscriber-map which calls the
operator-policy. Then the
operator-policy calls the
below is used to say "use dns look up for both SGW and PGW selection" and
if DNS is down use static list
TMD1. The static tai management DB
is also used to define TA Lists that are sent to UE to inform it about the
TA is can move between before it needs to perform a TAU. The important part
call-control-profile for node selection is the use of
co-location which tells the MME to use best
match of SGW and PGW and longest conical name match. In the example above
we would match conical names up to the nodeName# portion of the FQDN.
apn-profile is used for static PGW assignment for when DNS is unreachable.
round-robin-answersenabled in the client, we will round robin across the results on a per service/PCS2 basis. This may result in what looks broken functionality as the first results may get used always until all session managers have done so and move on to next result.
Below we detail the co-location gateway selection criteria available in IOS-M R12.2.gw-selection co-location
- co-location as the determining factor for gateway selection. What this means is the MME will take all records received from DNS and pair together all SGW and PGW with exact conical name match. If failures happen in the pairs, they will be black listed on a per subscriber basis during a attach procedure. Once all the pairs are exhausted from failures during a single attach procedure, the MME will start using all left records as random pairs until success is reached or you run into the four fall back limit mentioned below.
- P/SGW retries configured in egtp service
- P/SGW fall back happens four times per subscriber to the selected nodes equaling total of 5 nodes pair attempts before reject (we only have four co-located pairs in the example).
- If order and priority are all equal and round robin is configured, the MME will use a list for each session manager per PSC card as follows 1,2,3,4,5 to each card for its first sub. Then 2,3,4,5,1 for all PSC cards for it next subscriber and so one as will round robins through the results.
- PGW selection uses Order/Priority on PGW only when more than one PGW is available and only one SGW is available.
|Record Type||Flag||Metric Type||Is it Used?|
|NAPTR||s||Order||Yes, only when DNS returns two or more SGW RRs FQDN length as a tie breaker (lower is better)|
|NAPTR||s||Preference||Used for load balancing in R14 (65535 - value sent by DNS)|
|NAPTR||a||Order||Yes, only when DNS returns two or more SGW RRs FQDN length as a tie breaker (lower is better)|
|NAPTR||a||Preference||Used for load balancing in R14 (65535 - value sent by DNS)|
|SRV||N/A||Priority||Yes, only when DNS returns two or more SGW RRs FQDN length as a tie breaker (lower is better)|
|SRV||N/A||Weight||Yes, When multiple equal length longest matches are returned, this value dictates what percent each will be load balanced. For example if you have two results with priority of 20 and 80 then the 20 result will get 20% of bearer requests and the other will bet 80% per session manager(only in R14.0)|
Below we have a table showing the supported app-service types and app-protocol types.
|Description||IETF RFC 3958 section 6.5 'app-service' name||IETF RFC 3958 section 6.5 'app-protocol' name|
|PGW and interface types supported by the PGW||x-3gpp-pgw||x-s5-gtp
|SGW and interface types supported by the SGW||x-3gpp-sgw||x-s5-gtp
|MME and interface types supported by the MME||x-3gpp-mme||x-s10
- From 3GPP Specification 23.401:
- 126.96.36.199.2 X2-based handover without Serving GW relocation
"The MME determines that the Serving GW can continue to serve the UE" (this means translates 100% to fact that SGW can handle UEs target TA)
- 188.8.131.52.3 X2-based handover with Serving GW relocation
"the MME decides that the Serving GW is to be relocated" (this means translates 100% to fact that SGW cannot handle UEs target TA)
- 184.108.40.206.2 X2-based handover without Serving GW relocation