Return to index.
X.25 networks can implement access restrictions by means of Closed User Groups (CUG). A terminal (DTE) may be "subscribed" to a list of CUGs, which restricts them to making or receiving calls between endpoints within one of those CUGs. Optionally the DTE may be allowed to still communicate with the "open" part of the network (addresses not belonging to any CUG) while still being prevented from accessing non-subscribed CUGs.
Each closed group is identified by a 2-digit or 4-digit decimal number. When a call is made, the Call Request packet sent by the calling DTE contains a list of facilities (similar to TCP options), one of which may be "Closed User Group (basic)" for a 2-digit CUG or "(extended)" for a 4-digit CUG. If a CUG was specified in the Call Request, it will be validated by the DCE to make sure the line is subscribed to that CUG; if none was requested, then a default or "preferential" CUG will be assumed for that call.
The same CUG number may optionally be included in the Incoming Call packet sent to the answering DTE, although that is only after the network itself has already enforced CUG security, so the called DTE may ignore it (or the customer may opt out from receiving the facility entirely).
CUG identifiers have only local significance. The local CUG specified by the calling DTE may be translated to some kind of network CUG by the DCE (so that different customers' uses of the 0–99 namespace do not collide) and then on the other end may be translated again to a local CUG for the answering DTE.
(In modern terms, CUGs could be compared to Ethernet 802.1Q VLANs, but with Ethernet MAC addresses – not IP addresses – being the counterpart of X.121 addressing, since the DTE has the same global X.121 address across any and all CUGs.)
Text-mode PADs may allow the user to specify a CUG if the line is subscribed to more than one, e.g. the standard X.28 PAD interface allows prefixing an address with gXXXX- to request a specific CUG.
*g1234-471043
Some networks had custom, more user-friendly interfaces; e.g. DATEX-P supported a CUG(XXX) prefix:
CUG(1234) 471043
This example shows a call being made from the X.28 PAD interface (more specifically from Cisco IOS emulating a PAD using the x28 command) with the gXXXX- syntax used to specify an arbitrary 4-digit CUG number, followed by Cisco IOS debug output as it forwards the call out to a DTE attached on Serial0/1:
*g1234-471043 Apr 25 20:03:45.134: Serial0/1: X.25 O R1 Call (24) 8 lci 1 Apr 25 20:03:45.134: From (6): 471041 To (6): 471043 Apr 25 20:03:45.134: Facilities: (9) Apr 25 20:03:45.134: Packet sizes: 128 128 Apr 25 20:03:45.134: Window sizes: 2 2 Apr 25 20:03:45.134: Closed User Group (extended): 1234 Apr 25 20:03:45.134: Call User Data (4): 0x01000000 (pad) Apr 25 20:03:45.146: Serial0/1: X.25 I R1 Call Confirm (3) 8 lci 1
Normally the PAD is considered the DTE, or user premises equipment, so it does not enforce any CUG restrictions – that is done by the DCE, which represents the network side of the Network-User boundary.
In X.25, calls are always initiated by the DTE, never by the network, so even though this particular example happens to be from a Cisco IOS terminal line on the "DCE" device (emulating a PAD using the x28 command), IOS still acts as if there is a DTE-DCE transition and applies local-to-network CUG translation (as configured on line vty) before the network-to-local translation on Serial0/1 takes place.
DRAFT
While explaining CUGs it is necessary to remember that X.25 connections are not quite peer-to-peer, but are designed to mirror the structure of telephone networks – in which there is a central Network surrounded by Users – and the purpose of X.25 is to define specifically the interface between a Network and its User (that is, between a DCE and a DTE). For example, when two identical Cisco routers are connected back-to-back, one of them must have its X.25 interface configured in "DCE" mode (therefore acting as the Network) while the other will be in DTE mode (the default, acting as a User). Communications inside of the Network (between two DCEs) are beyond the scope of X.25, and could have been implemented using the similar X.75 or proprietary methods.
All CUG configuration is done at the Network-User boundary, and some terminology used by Cisco IOS will only make sense when keeping this in mind. Only DCE-type X.25 interfaces can have CUG parameters, and such parameters use the term 'incoming call' for call requests which exit the interface. This is because X.25 calls are only initiated by Users – never by the Network – so a call is 'incoming' for an interface when it originates "somewhere else" and terminates at the User connected to that interface.
(Though a Cisco router will happily forward X.25 packets even between two of its DTE-mode interfaces, so it is possible to have a chain of 3 routers where the middle one is configured as a DTE or half-DCE/half-DTE; this is not exactly in line with X.25 architecture, however, so it can make CUG configuration even more confusing than it already is. A proper imitation of a tiny X.25 PDN should have a central router with all-DCE interfaces, acting as the Network for its Users which are all DTEs.)
For the same reason, CUGs cannot be configured on XOT (X.25-over-TCP) profiles as those are considered to be inter-network (DXE) connections.
What about calls made directly from (or into) a router's terminal line, using the pad command or the x28 interface? As of IOS 12.3, each terminal line is a Network-User boundary and can have its own CUG configuration in the same style as a DCE serial interface.
DRAFT
CUG enforcement is done on the DCE side, and can be configured at interface level for downstream X.25 connections to DTEs connected via serial links, or at line level for calls originating from the router's local EXEC (each terminal line can be considered an imaginary DTE). In both cases the DCE-side configuration looks the same, but is somewhat intermixed with DTE-side configuration.
! Upstream interface interface Serial 0/0 encapsulation x25 x25 facility x25 address 471041 ! Downstream interface to a physical DTE interface Serial 0/1 encapsulation x25 dce x25 address 471041 x25 subscribe cug-service x25 subscribe local-cug 11 network-cug 501 preferential x25 subscribe local-cug 24 network-cug 504 ! Routing for the DTE's address (regex) and a default route route ^471042 interface Serial 0/1 route ^471 clear route ^ interface Serial 0/0 ! Local terminal lines (interfaces to imaginary DTEs) which may make ! outbound 'pad' calls line vty 0 4 transport input telnet x25 subscribe cug-service outgoing-access x25 subscribe local-cug 24 network-cug 504 ! A terminal line (again acting as imaginary DTE) which is set up to ! receive 'pad' calls from outside, using sub-address 5 or 05 line aux 0 transport input pad rotary 5 x25 subscribe cug-service x25 subscribe local-cug 69 network-cug 509
In this example, a DTE wired to Serial0/1 is only allowed to make calls if it indicates CUGs 11 or 24, and the DCE router will translate them to 501 or 504 respectively before forwarding the Call-Request upstream. (If the DTE doesn't indicate a CUG, the DCE will behave as if the preferential CUG was indicated; in this example it will attach CUG facility 501 to the upstream request.) Likewise, the DTE is only allowed to receive calls which indicate CUGs 501 or 504, and those will be translated back to 11 or 24 for the downstream DTE.
Meanwhile, users on terminal lines (in this example, connecting to IOS via Telnet) can use the pad or x28 commands to make calls if they indicate CUG 24 or no CUG at all (but are not allowed to specify any other CUG).
How is the CUG determined for a given destination? PADs (including the IOS x28 emulated PAD) allow the CUG to be specified using the gXXX- address prefix, e.g. calling g24-12345 will indicate local CUG 24. For the IOS EXEC pad command, instead, the outbound interface needs to have x25 facility cug XXX specified to designate the default CUG. Optionally x25 map pad ADDR cug XXX can define a per-destination CUG.
The x25 facility cug and x25 map pad commands can also be specified on a downstream (DCE) interface. In that case, they specify the "network" CUG, which will be translated to a local CUG for the DTE that is downstream.
- If the DCE interface has CUG service activated, then the CUG is interpreted as a "network" CUG (since calls from the DCE are calls from the Network) and translated to the corresponding "local" CUG for the downstream DTE. Interfaces without CUG service simply pass the CUG as-is.Mappings are only applied to pad /use-map, not to plain pad (nor to x28 interface). They also override the regular X.25 routing table; if /use-map was specified and a mapping is found on Serial0/1 then the Call-Request will be sent through the same Serial0/1, even if the routing table would have directed it elsewhere.