cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
812
Views
0
Helpful
6
Replies

Problem with X.25 CLAM facility

etamara
Level 1
Level 1

Hi,

Recently, I´ve come across with some problems when setting up X.25 calls between my network and an external provider.

I have a Unix machine with two X.25 cards connected to two Cisco 3600 routers ( one card to each switch; one card is active, the other is in standby mode ), which have access to the X.25 provider cloud.

When I initiate a call to the destination using SW1, it completes without problems, but the CALL CONNECTED packet indicates the CLAM facility has been encoded due to hunt group call distribution. Actually, I can see in the traces that the destination address has been changed by the other end.

However, when trying the same call on SW2 ( configs and all are exactly the same ) the CALL CONNECTED packet shows the following:

"Bad Destination Address, Dest. address modified with no CLAM"

As a result, a CLEAR packet is sent from my device to abort the call setup. What is really surprising is that the destination address has also been changed by the other end to the same changed destination address as in the first case ( SW1 ).

See the traces below:

SW1:

Feb 9 11:41:23.112: Serial1/1: X.25 I R1 Call (18) 8 lci 495

Feb 9 11:41:23.112: From (10): 3581228210 To (8): 31419748

Feb 9 11:41:23.112: Facilities: (0)

Feb 9 11:41:23.112: Call User Data (4): 0xFA003176 (unknown)

Feb 9 11:41:23.116: Serial0/0: X.25 O R1 Call (18) 8 lci 543

Feb 9 11:41:23.116: From (10): 3581228210 To (8): 31419748

Feb 9 11:41:23.116: Facilities: (0)

Feb 9 11:41:23.116: Call User Data (4): 0xFA003176 (unknown)

Feb 9 11:41:23.360: Serial0/0: X.25 I R1 Call Confirm (16) 8 lci 543

Feb 9 11:41:23.360: From (10): 3581228210 To (8): 31419716

Feb 9 11:41:23.360: Facilities: (2)

Feb 9 11:41:23.360: Called Line Address Modified notice, reason 0x7: hunt group call distribution

Feb 9 11:41:23.360: Serial1/1: X.25 O R1 Call Confirm (16) 8 lci 495

Feb 9 11:41:23.360: From (10): 3581228210 To (8): 31419716

Feb 9 11:41:23.360: Facilities: (2)

Feb 9 11:41:23.360: Called Line Address Modified notice, reason 0x80: specified by destination

-----------------------------------------------------

SW2:

Feb 9 11:35:17.306: Serial1/1: X.25 I R1 Call (18) 8 lci 500

Feb 9 11:35:17.306: From (10): 3581228210 To (8): 31419748

Feb 9 11:35:17.306: Facilities: (0)

Feb 9 11:35:17.306: Call User Data (4): 0xFA003176 (unknown)

Feb 9 11:35:17.310: Serial0/0: X.25 O R1 Call (18) 8 lci 548

Feb 9 11:35:17.310: From (10): 3581228210 To (8): 31419748

Feb 9 11:35:17.310: Facilities: (0)

Feb 9 11:35:17.310: Call User Data (4): 0xFA003176 (unknown)

Feb 9 11:35:17.450: Serial0/0: X.25 I R1 Call Confirm (14) 8 lci 548

Feb 9 11:35:17.450: From (10): 3581228210 To (8): 31419716

Feb 9 11:35:17.450: Facilities: (0)

Feb 9 11:35:17.450: X.25 Call Confirm packet, Bad destination address, Dest. address modified with no CLAM

Feb 9 11:35:17.450: Serial0/0: X.25 O R1 Clear (5) 8 lci 548

Feb 9 11:35:17.450: Cause 0, Diag 67 (DTE originated/Invalid destination address)

Feb 9 11:35:17.478: Serial0/0: X.25 I R1 Clear Confirm (3) 8 lci 548

Feb 9 11:35:17.478: Serial1/1: X.25 O R1 Clear (5) 8 lci 500

Feb 9 11:35:17.478: Cause 9, Diag 0 (Out of order/No additional information)

Feb 9 11:35:17.490: Serial1/1: X.25 I R1 Clear Confirm (3) 8 lci 500

Does anybody know anything about this kind of problem?

Thanks,

Enrique

6 Replies 6

andi
Level 1
Level 1

Hello Enrique,

according to the X.25 standard, ("Called Line Address Modified notification"), a DTE may set the the CLAM facility in a Call Confirm packet to indicate that the called address has changed. If this facility is not set, the call may be cleared. This is what you see happening.

On SW2 you don't get a CLAM in the CALL CONFIRM, but the called number in the CALL CONFIRM has changed (hunt group). That's why the router complains the call.

Options which could help you:

1) Earlier IOS releases did not verify the CLAM facility (I think before 11.3T).

You can configure the hidden commmnd "x25 version 1980" on all X.25 interfaces that the call is passing (e.g: SW2 Serial 0/0).

It can help but might introduce other problems.

2) Call 31419716 directly (don't call the X.25 hunt group 31419748).

3) Speak to your provider, they may configured the two interfaces differentialy on their X.25 switch (x25 version 1980 or not), see the Facilities in the CALL CONFIRM on Serial 0/0 on SW1 and SW2.

(3) may not really help but, if the switch which is directly connected to the router doesn't care about the X25 called adress to route the X25 VC, i think you can use under serial 0/0 "x25 suppress-called-address"

So, by using the suppress-called-address command under the x.25 serial interface, the router will not check the address in the call-confirm.

Best regards,

Andreas

Hi,Andi:

Thanks for your reply and the solutions you suggest. If my understanding is right, it seems that the problem is caused by the remote end ( call destination ). In other words, if the destination changes the called address for any reason ( such as hunt-groups ), it should also encode the CLAM facility. This is important, since this is becoming a "political" issue. Is this right?

Thanks for all,

Enrique

Hi Enrique,

X.25 is a protocoll between X.25 DTE and X.25 DCE.

This means X.25 calls look like to be end to end but in reallity its just an interface protocol between your router and your UNIX host and between your router and the X.25 switch of your service provider.

The problem is not caused by the remote end (call destination) but (I guess) by your X.25 service provider. There are several options (for example on SIEMENS EWSP X.25 switches) how to handle calls with or without CLAM - notification (e.g. CADM and CAAM parameters).

I guess your service provider did not configured both interfaces to your routers in the same way.

Unfortunately ;-) a CISCO router was not designed as a X.25 switch but can switch X.25 calls. So there are only "workarounds" (already mentioned) on the router to avoid your problem.

To prove my guess, you may configure an X.25 interface between your routers SW1 and SW2 and then switch the call from your UNIX host via SW2 to SW1 to the service provider and then to the end-system. (keep in mind that the X.25 routing table on the

router is working sequential). This should work.

Only if you are using the interface on SW2 to your service-provder the call comes back without CLAM.

I hope this helps.

Regards,

Andreas

Thanks, Andi. I really appreciate your help.

Regards,

Enrique

Hi, Andi:

You were right: Telco problem ( the line was ITU-T 1980 ).

I supposed you´d like to know the outcome of this issue.

Thanks for all

Enrique

Hi Enrique,

the discussion with you helped me with a problem with CLAMN in our network as well (regarding CLAMN in a CALL CLEAR).

Please note there is a cisco command which may help as well (12.2(13T): x25 security clamn).

Regards,

Andreas

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco