02/08/12

Rev 4.0

Useful Troubleshooting Commands

Telnet to the Switch an get in debug mode (1) confirm the existing IP address: get node.2.0 (2) set the new IP address: set node.2.0 [a.b.c.d]

show arp show bgp show billing show card [slot] show community show ctr [slot] show dump file show dvmrp show external show fltrtbl show fltrbind show hardware show icmp show imlp [port] show ip show ipfwd show ipif show iplport show ipqos show logging show lport show lnkswitch show mpt show ntp show ospf show pnni show policy show pport show ppp show pram [slot] show pvc show rip show software show software flash show static show svc show system show task [sl] [id] show tcp show tproto show trap show udp show users

Show Arp Cache BGP attributes and statistics Billing System status Card configuration per slot (no slot # gives SP info) Display Community name and address information Cookies for trace Directory of dump files DVMRP information OSPF ASE device and host table Show all the filter entries Show all the filter bindings MIM info for populated cards & adapters ICMP statistics Internal Management address for logical port IP statistics Show Ip forward statistics for card Show ip interface Show iplport IP QoS Lport statistics Current state of trace logging Logical port attributes and statistics LNK_SWITCH or LNK_SWITCH_PROXY fields Current state of the multipoint-to-point tree Network Timing Protocol status OSPF attributes and statistics PNNI routing topology and statistics IP Routing Policy attributes Physical port attributes and statistics PPP port information Contents of PRAM files (no slot # gives SP info) PVC attributes and statistics RIP statistics Version info for software running on card Version info for files on PCMCIA disks Show configured static routes SVC statistics General system information Show psos task [slot=1..n] [task id in hex] TCP statistics Display trk protocol stuff Trap queue counts and traps dropped UDP statistics Users that are currently logged in

02/08/12

Rev 4.0

show vcentry show fe

VC_ENTRY fields for the specified circuit FE statistics

Bold = Most commonly used commands

(Switch Name)> enable debug

Debug password: (mootman) DEBUG ACCESS LEVEL GRANTED.

(Switch Name)> show system

Switch Name: System Desc: Model: Location: Contact: System State: Uptime: Current time: Serial Number: Hardware Rev: EPROM Rev: Software Rev: Ethernet Addr: Slot Type 1 2 7 9 10 11 SP30 SP30 DS3-8 OC3/STM1-4 OC3/STM1-4 OC3/STM1-4

General system information

da2acbx1 Ascend Communications Corporation CBX 500 CBX-500 211 S. Akard - room 365 row 17 cabinet 4 Joe Cuthbertson 214-464-5568 Active 184 days 2 hours 46 minutes 49 seconds Fri Feb 25 22:38:34 2000 UTC 22A48222 04 01.00.00.00 03.02.04.00 00:06:29:15:11:5A Redund State Standby Active Active Active Active Active SW Rev 03.02.04.00 03.02.04.00 03.02.04.00 03.02.04.00 03.02.04.00 03.02.04.00 Internal IP Addr: Ethernet IP Addr: Network Wide Addr: Network Mask: HW Rev 11 11 00 05 05 07 172.29.1.1 155.179.59.39 172.29.0.0 255.255.0.0 Serial# 22A85090 22A62567 22A70865 22A45676 22A45332 22A81940

EPROM 01.00.00.00 01.00.00.00 01.01.00.00 01.00.00.00 01.00.00.00 00.00.00.00

Switch Name> show hardware

LDN> show hardware Slot Product Code MFG. # 1 11410 810-00183-00 1 IOA 11023M 810-00111-06 2 11410 810-00183-00 2 IOA 11023M 810-00111-06 6 11072A 810-00277-10 6 IOA 11054 810-00121-00 8 11075L 810-00206-01 8 IOA 11046 810-00056-01 9 11075L 810-00206-01 9 IOA 11046 810-00056-01 10 11075L 810-00206-01 10 IOA 11041 810-00041-01 11 11075L 810-00206-01 11 IOA 11041 810-00041-01 14 11074A 810-00276-05 14 IOA 11034 810-00115-00 H/W Rev 10 04 10 04 05 03 05 03 06 03 06 01 06 01 05 07 S/N 22A41931 22A44984 22A41018 22A44984 28B39373 28B26908 22A42901 22A53610 22A38533 22A46850 22A38523 22A49524 22A47648 22A49548 22A56555 22A55624

02/08/12 Card Status

Rev 4.0

Slot Status Non-Fatal Error Time Fatal Error Time 1 ok SYS_TIMING_MINOR: One of two configured references lost.4:1:51:4 Internal Error 0:3:47:56 2 ok Warm Boot 13:22:36:14 6 ok Warm Boot 13:22:32:17 8 ok Cold boot / SMC Reset 119:23:28:22 9 ok Cold boot / SMC Reset 101:1:59:18 10 ok Cold boot / SMC Reset 1:5:54:43 11 ok Cold boot / SMC Reset 88:9:40:7 14 ok Cold boot / SMC Reset 66:21:45:53 Fan Status 1 up 2 up 3 up 4 up 5 up 6 Up 7

Switch Name## show card state

Card State 1 Active 2 Active 3 Down 4 Active 5 Active 6 Active 7 Unknown 8 Unknown 9 Unknown 10 Unknown 11 Unknown 12 Unknown 13 Unknown 14 Unknown 15 Unknown 16 Unknown

-Loading - Loadingdone- Active (the process in rebooting)

Switch Name ## show card 11

Serial#: 22A81940 Configured Card Type: Hardware Revision: 07 Actual Card Type: EPROM Revision: 00.00.00.00 Physical Slot: Software Revision: 03.02.04.00 Logical Slot: Actual IOA Type: 4 prt OC3/STM1 SMLR Redund State: Card State: Administrative Status: Operational Status: Diagnostics Status: Active Active Up Up Up Memory(9) Available: CPU Utilization: OC3/STM1-4 OC3/STM1-4 11 11

11912272 2%

02/08/12 Packets Received: Octets Received: Packets Sent: Octets Sent:

Rev 4.0 195923103 Maximum number of PVCs: 799151509 Inactive PVCs: 197427005 Free VCs: 2468321243

4 16351 73 16245

Switch Name ## next card.2.1.67

(Shows Card Uptime) 1.3.6.1.4.1.277.1.7.2.1.67.1.1 = 58697180 (Timeticks, 6 days 19 hours 2 minutes 51 seconds) 1.3.6.1.4.1.277.1.7.2.1.67.1.2 = 58696160 (Timeticks, 6 days 19 hours 2 minutes 41 seconds) 1.3.6.1.4.1.277.1.7.2.1.67.3.1 = 58693370 (Timeticks, 6 days 19 hours 2 minutes 13 seconds) 1.3.6.1.4.1.277.1.7.2.1.67.4.1 = 58693000 (Timeticks, 6 days 19 hours 2 minutes 10 seconds) 1.3.6.1.4.1.277.1.7.2.1.67.5.1 = 58692450 (Timeticks, 6 days 19 hours 2 minutes 4 seconds) 1.3.6.1.4.1.277.1.7.2.1.67.6.1 = 58693040 (Timeticks, 6 days 19 hours 2 minutes 10 seconds) 1.3.6.1.4.1.277.1.7.2.1.68.1.1 = 952934340 (Integer)

Switch Name ## next card.2.1.23

Shows the last fatal error in Ascii text format

1.3.6.1.4.1.277.1.7.2.1.23.1.1 = NMS requested a redundant switchover. (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.1.2 = Cold Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.3.1 = ACTIVE NOT RESPONDING - SHOOTING (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.3.2 = Internal Error (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.11.1 = ACTIVE NOT RESPONDING - SHOOTING (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.11.2 = Internal Error (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.13.1 = Internal Error (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.13.2 = Internal Error (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.15.1 = ACTIVE NOT RESPONDING - SHOOTING (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.15.2 = Internal Error (OctetString) 1.3.6.1.4.1.277.1.7.2.1.24.1.1 = 5 (Counter)

Switch Name> show pport 10 Shows all pports and the number of interfaces on a slot and the status
Pport 1 2 3 4 5 6 7 8 type UIO-8 UIO-8 UIO-8 UIO-8 UIO-8 UIO-8 UIO-8 UIO-8 # of lports 1 1 1 0 1 1 1 1 datarate 1536000 1536000 512000 1536000 128000 512000 1536000 1536000 status Down Up Up Down Up Up Down Up

Switch Name> show pport attributes 7.8 (Slot 7; Port 8 on a DS3-8 card
Port Type: Interface Type: Data Rate: Link Down Reason: DS3-T3-8 44736000 NONE N/A

Operational Status: Up Administrative Status: Up Clock Source: Loop Timed

Switch Name> show pport statis 7.8

Receive Transmit

02/08/12 Control Octets: Control Frames: Control Discards: Control Errors: Cells: Cell Errors: Out Discard Cells: 0 0 0 0 9210167 100

Rev 4.0 0 0 0 0 3741898 0 Priority Queues 0 : 0 1 : 0 2 : 0 3 : 0

Peak Cell Rates for High Cells/second Queue Cells/second Queue Cells/second Queue Cells/second Queue

Switch Name ## next pport.2.1.44 5.1

1.3.6.1.4.1.277.1.4.2.1.44.3.1 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.3.2 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.3.3 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.3.4 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.3.5 = 95 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.3.6 = 95 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.3.7 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.3.8 = 1045 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.1 = 372 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.2 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.3 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.4 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.5 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.6 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.7 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.4.8 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.5.1 = 61 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.5.2 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.5.3 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.5.4 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.6.1 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.6.2 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.6.3 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.44.6.4 = 0 (Counter) 1.3.6.1.4.1.277.1.4.2.1.45.3.1 = 0 (Counter)

Shows the total # of cells received with error on slot/port this shows slot 3, port 1 with 0 errors

Switch Name## next lport.1.1.2

1.3.6.1.4.1.277.1.5.1.1.2.17 = 4 (Integer) 17 = iF #; 4 = Slot # 1.3.6.1.4.1.277.1.5.1.1.2.18 = 3 (Integer) 1.3.6.1.4.1.277.1.5.1.1.2.19 = 3 (Integer) 1.3.6.1.4.1.277.1.5.1.1.2.20 = 3 (Integer) 1.3.6.1.4.1.277.1.5.1.1.3.17 = 1 (Integer)

Switch Name## next lport.1.1.3

1.3.6.1.4.1.277.1.5.1.1.3.17 = 1 (Integer) 17 = iF#; 1 = port# of Slot# above 1.3.6.1.4.1.277.1.5.1.1.3.18 = 1 (Integer) 1.3.6.1.4.1.277.1.5.1.1.3.19 = 8 (Integer) 1.3.6.1.4.1.277.1.5.1.1.3.20 = 5 (Integer)

02/08/12

Rev 4.0

1.3.6.1.4.1.277.1.5.1.1.4.17 = 1 (Integer) In the example highlighted in red; you can tell that the iF# is 17 in slot 4 from the next lport.1.1.2, and in on port 1 from the next lport.1.1.3

Switch Name ## next lport.1.1.2

1.3.6.1.4.1.277.1.5.1.1.2.19 = 3 (Integer) 1.3.6.1.4.1.277.1.5.1.1.2.20 = 5 (Integer) 1.3.6.1.4.1.277.1.5.1.1.2.21 = 3 (Integer) 1.3.6.1.4.1.277.1.5.1.1.2.33 = 4 (Integer) 1.3.6.1.4.1.277.1.5.1.1.2.34 = 3 (Integer) 1.3.6.1.4.1.277.1.5.1.1.3.19 = 5 (Integer)

Switch Name ## show lport statis 19

Control Frames: Control Octets: Control Discards: Control Errors: Cells: Receive Transmit 0 6 0 318 0 0 95 0 0 6 Receive 52644560 2790161680 0 61 52644560 Transmit 9359027 496028431 0 0 9359027

Logical port statistics

Switch Name ## show lport statis 20

Control Frames: Control Octets: Control Discards: Control Errors: Cells:

Switch Name ## show lport attrib 19

Logical port attributes Slot: 3 Port: 5 Interface: 19 Data Rate: 40704000 Port In BW In BW Out BW Out BW Oversub.: Avail. Alloc. Avail. Alloc. Qos1 100% 95900 0 95900 0 Qos2 100% 95900 0 95900 0 Qos3 100% 95900 0 95900 0 Qos4 100% 95900 100 95900 100 Administrative Status: Up Operational Status: Down Explanation of the above output: Qos1, 2, 3, 4, CBR, rt-VBR, nrt-VBR,UBR/ABR Oversub = % of over subscription on that service In BW Avail = Available bandwidth for each type of service In BW Alloc = Bandwidth allocated (used) per service type Out BW Avail = Available bandwidth for each type of service Out BW Alloc = Bandwidth allocated (used) per service type Note: if looking at a trunk, from a 500 to a 9000, you will see e.g. CBR 5% lport BW for trunk overhead For a 500 to 9000 Amethyst, you will see 5% on the 500 CBR out and VBR-nrt IN; 9000 CBR IN, VBR-

02/08/12

Rev 4.0

nrt OUT. 9000 Amethyst uses vbr-nrt for trunk protocol and ospf = 5% deduction.

Switch Name > show lport attributes 15

Slot: 7 Port: 8 Interface: 15 Data Rate: 10047000 Trunk Status: Full Trunk Overhead: Remote Node: 172.29.1.1 Remote Interface: Trunk Out BW Out BW Oversub.: Avail. Alloc. Qos1 100% 4620 1184 Qos2 100% 4620 0 Qos3 200% 9240 35783 Qos4 100% 4620 0 Administrative Status: Up Operational Status:

5% (This lport attributes shows a trunk) 22 (Shows remote info)

Up

Switch Name ## get lport.1.1.178.52

Shows # of PVCs on an interface last # = ifnum e.g. 52

1.3.6.1.4.1.277.1.5.1.1.178.52 = 454 (Integer) FTW1C501## next card.2.1.23 1.3.6.1.4.1.277.1.7.2.1.23.1.1 = Card warm boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.1.2 = File System Failed Mounting (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.3.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.4.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.5.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.6.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.8.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.9.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.10.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.11.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.13.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.15.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.23.16.1 = Warm Boot (OctetString) 1.3.6.1.4.1.277.1.7.2.1.24.1.1 = 0 (Counter)

Switch Name > show ospf

These are all the show commands for OSPF

show ospf [areas|database|interface|neighbor|names|rtrs|adv|statistics|trunks| pathdb|vcroute] show ospf database [[router|external|network|absr-summary|summary|names| trunks|opaque|all|<area id>]]| [[router|external|network|absr-summary|summary|names| trunks|opaque] <link state id> <adv. router>]| [[router|external|network|absr-summary|summary|names| trunks|opaque] <link state id> <adv. router> <area id>] show ospf statistics [<slot id>|<slot id> <area id] show ospf trunks [<switch id>/<interface #>| <switch id>/<interface #> <slot id>| <qos>|<qos> <priority>] show ospf adv [<link state type> <link state id> <adv. router>|

02/08/12

Rev 4.0

<link state type> <link state id> <adv. router> <area id>] show ospf pathdb [<slot id>|<switch id>|<switch id> <interface #>| <switch id> <interface #> <slot id>] show ospf vcpath [<ip address>|<ip address> <slot id>] show ospf qospath [<ip address>|<ip address> <slot id>] show ospf namedpath [<type> <name> <bit length>| <type> <name> <bit length> <slot id>] If you do a show ospf database it will show the entire content of the OSPF Link State Advertisement (LSA) database on the switch. The output is nearly identical to the "database" command available on some routers. The fields are defined in the various OSPF specifications available. - Type - the type of Link State Advertisement. If the type is a router LSA (value of 1), there will be a number following it in parentheses. This is the OSPF rev. level running on that router (i.e. switch).
/* * Link State Types #define LS_RTR 1 #define LS_NET 2 #define LS_SUM_NET 3 #define LS_SUM_ASB 4 #define LS_ASE 5 #define LS_TRUNK 14 #define LS_NAME 15 If the type is an OSPF Name LSA, there will be a number following it in parentheses. This is the name type, as identified here: Name Type Meaning ---- ------1 /* Resilient UNI/NNI */ 2 /* E.164 address (SMDS, Frame relay SVCs) */ 3 /* NSAP address (ATM) */ 4 /* SMDS SNI IA */ 5 /* SMDS group address */ 6 /* SMDS address range */ 7 /* SMDS carrier ID */ 8 /* SMDS Carrier-specific address */ - ID - the LS destination ID, an IP address Adv-Switch - the IP address where the advertisement originates - Seq# - the OSPF sequence number - Age - the age of the advertisement, in seconds. At the end are two more fields: - # LSAs - the total number of LSAs in the database - Xsum - The current checksum of the database

SMRC8> show ospf database

Link-state database for area 0.0.0.0 ---------------------------- ---------------

Type RTR (11) 1 RTR (11) 1 RTR (11) 1 RTR (11) 1 RTR (11) 1

ID 172.16.1.1 172.16.1.2 172.16.1.3 172.16.1.4 172.16.1.5

Adv-Router 172.16.1.1 172.16.1.2 172.16.1.3 172.16.1.4 172.16.1.5

Seq# 0x8000095c 0x800008e2 0x8000082d 0x8000055e 0x8000050a

Xsum 0x608a 0xb0a6 0x1d7d 0xa054 0xef52

Age 907 908 903 1598 1648

02/08/12

Rev 4.0

RTR (11) 1 172.16.1.6 ASE 5 10.10.10.89 Type ID ASE 5 10.10.10.93 ASE 5 10.10.10.97 TRK 14 0.0.0.1 TRK 14 0.0.0.1 TRK 14 0.0.0.1 1(9) 192.148.25.3 1(9) 192.148.25.5 1(9) 192.148.25.6 1(9) 192.148.25.8 1(9) 152.147.19.1 1(9) 152.147.19.3 5 152.148.30.133 5 192.168.11.2 14 0.0.0.32 14 0.0.0.1 14 0.0.0.1 14 0.0.0.64 15(5) 0.0.0.1 15(5) 0.0.0.1 15(5) 0.0.0.2 15(5) 0.0.0.2 15(5) 0.0.0.7 # LSAs: 30 Xsum: 0x109fb3

172.16.1.6 172.16.1.1 Adv-Switch 172.16.1.2 172.16.1.3 172.16.1.2 172.16.1.3 172.16.1.5 192.148.25.3 192.148.25.5 192.148.25.6 192.148.25.8 152.147.19.1 152.147.19.3 192.148.25.3 192.148.25.3 192.148.25.6 152.147.19.3 152.147.19.1 192.148.25.5 152.147.19.3 152.147.19.1 152.147.19.3 152.147.19.1 152.147.19.1

0x800004ec 0x800000b2 Seq# 0x800004a9 0x80000001 0x8000067b 0x80000006 0x800000a0 0x80000190 0x80000430 0x80000442 0x8000018b 0x80000580 0x8000058c 0x80000099 0x80000099 0x800001b9 0x8000021e 0x80000220 0x80000400 0x80000414 0x8000037d 0x8000040a 0x80000343 0x80000343

0x9692 0x21ca 0xf8f2 0x286b 0x90cc 0x671c 0x2ad

907 1448 Age 1601 1296 963 883 744 75 969 83 79 1414 1438 615 615 1601 1743 1756 303 276 1418 276 1418 1418

1st column = the external router # 2nd column = the Host address ID 3rd column = the Advertised address

The show ospf interface command shows the state of all OSPF neighbors.
There are seven fields reported for each neighbor: - Lport - The logical port interface number of the trunk to the neighbor. If this value is "Int", that entry represents an IOP, which in 4.2 is logically an OSPF neighbor of the CP. - Neighbor - The IP address of the neighbor at the other end of the trunk. If the neighbor is an IOP, the first 3 sections of the IP address are 0s, and the 4th is the IOP's slot number. - Nbr_State - The state of the OSPF connectivity between the CP and this neighbor. Possible values are: Down, Attempt, Init, 2 Way, Exch Start, Exchange, Loading, Full, and SCVirtual. - Vers - the OSPF version being run in the neighbor. - #Rxmt - current number of outstanding retransmission requests to this neighbor. If this value is always non-zero, it is an indication of a problem with OSPF communicating with that neighbor. - #LSReq - current number of outstanding link state requests to this neighbor. This value usually will be zero except when OSPF is in exchange state. - #DBsum - current number of LSAs within database descriptor packets remaining to be sent out to the neighbor. This value usually will be zero except when OSPF is in exchange state.

02/08/12

Rev 4.0

10

Switch Name ## show ospf interface Will list the iF#s on the local switch
LPort Neighbor Int 0.0.0.3 Int 0.0.0.4 Int 0.0.0.7 Int 0.0.0.8 Int 0.0.0.10 Int 0.0.0.15 Int 0.0.0.16 1 152.147.19.3 Nbr_State Full Full Full Full Full Full Full Full Vers 9 9 9 9 9 9 9 9 #Rxmt 0 0 0 0 0 0 0 0 #LSReq 0 0 0 0 0 0 0 0 #DBsum 0 0 0 0 0 0 0 0

SMRC8> show ospf nei

LPort Interface 0 0.0.0.0 NbrId NbrIPAddr Pri State Ver #Rxmt#LSRq #DBsum 0.0.0.3 0.0.0.3 0 Full 11 0 0 0 0.0.0.4 0.0.0.4 0 Full 11 0 0 0 0.0.0.5 0.0.0.5 0 Full 11 0 0 0 0.0.0.6 0.0.0.6 0 Full 11 0 0 0 0.0.0.7 0.0.0.7 0 Full 11 0 0 0 2 172.16.1.1 172.16.1.3 172.16.1.3 0 Full 11 0 0 0 3 172.16.1.1 172.16.1.2 172.16.1.2 0 Full 11 0 0 0 How to read: Bold line 2 = iF#, 172.16.1.1 = Local switch address; 172.16.1.3 = neighbor ID and Address 0 = priority for OSPF; Full = State of the OSPF link (full = up) 11 = the version of OSPF running show ospf names command prints a line for every name known to the switch. Names can be any of the name types identified in the description of "show ospf database". There are 5 fields displayed by this command for each name: - Type - the type of name, as identified in the description of "show ospf database" - Flags - any flags associated with the name - Cost - the cost of the path to the switch currently hosting the name (i.e. the name's primary location) - State - the current state of the name (primary or backup), if available - Name/Len Primary (Secondaries) - this parameter indicates the name itself shown as a hexadecimal string, along with the name length shown in bits. These two parameters are separated by a slash. Next is the primary location for the name, shown as the last two sections of the IP address followed by the port number. These two parameters are also separated by a slash. After the primary location is listed any secondary locations for the name.

show ospf names

Type 2 2 4 4 4 4 4 4 5 5 5 Flags 0x00000006 0x00000026 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0 0x0 0x0 Cost 0 40 0 0 0 0 0 0 N/A N/A N/A State N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Name/Len Primary(Secondaries) 1888222/56 19.1/0 234/24 19.1/12 0x20377770/28 19.3/0 0x20388880/28 19.3/0 0x41445670/28 19.3/0 0x97869200/28 19.1/0 0x97869240/28 19.1/0 0x97869250/28 19.1/0 0x800234/24 19.3/0 0x800342/24 19.1/0 0x800777/24 25.5/43690,19.3/0,19.1/0

02/08/12

Rev 4.0

11

show ospf route command shows the OSPF IP routing table on this node. In a 4.2 Ascend network, this routing table is used for management traffic only (e.g. SNMP traffic). There are 6 fields reported for each routing table entry: - Dest - the address of the routing table entry, in IP address format; - Mask - the mask associated with the routing table entry; - Next_hop - the IP address of the next hop IP traffic will take enroute to this routing table entry; - State - the state of the routing table entry; - Cost - the cost associated with the entry; - Age - the age of the entry.

show ospf route

Dest 0.120.24.103 0.120.24.145 130.130.1.1 130.130.1.2 192.168.11.9 Mask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255 Next_hop 0.0.0.0 0.0.0.0 130.130.1.1 0.0.0.0 130.130.1.1 State Cost Static 0 Static 0 OSPF 100 Direct 1 OSPFE1 101 Age 0 0 0 0 0

show ospf adv <type> <ID> <Adv-Switch> shows the details of a particular LSA record, as specified in RFC
2328. <type>, <ID>, and <Adv-Switch> must be values as shown by "show ospf database". <Adv-Switch> is optional if it is a router LSA. For every type of LSA, the command prints out the age, the options, the LSA type, the LSA destination ID, the the router or switch IP address where the LSA originates, the sequence number, the checksum of the LSA record and whether it is good or bad, and the LSA length. For router, ASE, trunk, and name LSAs, additional information is reported. - For router LSAs, the number of interfaces is reported, and for each interface the link type, the link ID, and the link data, plus the cost of any associated type of service (TOS) are reported. If the link type is 1, that represents a trunk connected to that router (i.e. switch), and the link data represents the IP address of the remote end. - For AS external LSAs, the mask value, the cost and type, the forwarding address, and the tag are reported. - For trunk LSAs, the trunk instance and the type of service costs are reported. - For name LSAs, the type, the name, the length, the Lport ifnum, the cost, and the state are reported.

show ospf adv 15 0.0.0.7 152.147.19.1 (from show ospf database above)
LS age: LS options: LS type: LS ID: Adv rtr: LS Seq #: LS Xsum: LS Length Type: Name: Length: Lport: Cost: State: 1535 0x0 Name-LSA 0.0.0.7 152.147.19.1 0x80000033 0x1fb (good) 36 E.164 0x323334 3 12 40 Backup

02/08/12

Rev 4.0

12

The show ospf statisitics command shows the various OSPF statistics for the database on the card specified. The optional "card" value should be the slot number of the card whose statistics you wish displayed; the default is the active CP. There are 36 statistics reported - Switch IP address - IP address of this node; - Secondary address - secondary IP address of this node, if there is one; - # switches - total number of switches contacted in the network; - # reachable switches - current number of switches reachable in the network; - # Dijkstra runs - total number of Dijkstra runs completed on this card since it was last rebooted; - # Trunks - total number of trunk endpoints currently visible in thenetwork. The number in parentheses is the total number of trunk endpoints visible in the network since the card was last rebooted. If trunks have been deleted and/or moved, this value could be considerably higher than the current number of trunk endpoints; - Max LSA size - the size, in bytes of the largest LSA observed in the network; - # Stub links - the number of OSPF stubs. For the Ascend network, the number of routers visible. The number in parentheses is the total number of stub links visible in the network since the card was last rebooted. If stub links have been deleted, this value could be considerably higher than the current number of stub links; - # LSAs - the total number of LSAs currently visible in the network; - Database checksum - the current checksum of the OSPF database; - # router-LSAs - the current number of router LSAs visible in the network; - # AS-external-LSAs - the current number of external LSAs visible to the network; - # name-LSAs - the current number of name LSAs visible to the network; - # VC lookups - the number of times VC manager accessed OSPF; - # VC reroute attempts - number of times VC manager on this card accessed OSPF to ask for a VC reroute; - # successful defaults - the number of times OSPF returned the current path as the best path for VC manager to take, i.e. recommended no reroute; - # specific VC calc. - the number of times OSPF did a new Dijkstra calculation for a VC reroute request; - # QoS failures - the number of times OSPF failed in an attempt to calculate a new path for a VC due to an inability to satisfy the VC's QoS requirements; - # VC unreachables - the number of times OSPF failed in an attempt to calculate a new path for a VC due to node unreachable; - # VC reroutes - the number of times OSPF responded to a VC manager reroute request with a real reroute, as opposed to using the default path; - # VC crankbacks - the number of times VC manager requested a new reroute path, requesting that a particular path link be omitted from the new path; - # Multipoint cranks - same as VC crankbacks, but for point-to-multipoint circuits; - Max task latency (ms) - the maximum amount of time the OSPF task ran on this card before giving up control of the processor; - Max lookup time (ms) - the largest amount of time OSPF took to calculate a circuit path; - # OSPF trunk inst ch - the number of times OSPF cleared a circuit because of a "trunk down" event; - # VCMGR trunk inst ch - the number of times VC manager cleared a circuit because of a "trunk down" event; - # Bad paths reg - the number of times VC manager attempted to register a path with the OSPF paths database, but OSPF determined the path was invalid; - # VCs using old rev - the number of times VC manager called OSPF with path database information related to a trunk on a pre-4.2 node; - # VCMGR call backs - the number of times OSPF informed VC manager that a circuit was dead; - # VCMGR rpt old inst - the number of times VC manager called OSPF with trunk information where the trunk information had invalid sequence numbers; - # Trunk cost chg neg - when OSPF declares a trunk down, it briefly marks the admin cost of the trunk as infinity. This counts the number of times OSPF informed VC manager that a trunk's cost was infinity; - # trunk congestion - the number of times OSPF identified closed loop congestion due to trunks; - # path congestion - the number of times OSPF reported closed loop congestion to VC manager; - Routing S/W revision - Ascend-internal version of the OSPF protocol running in this switch; - Network S/W revision - Ascend-internal version of the OSPF protocol running in the network. This would be the lowest common denominator OSPF revision in the network.

02/08/12

Rev 4.0

13

SMRC8> show ospf statis

Switch IP address Secondary address: # switches # Dijkstra runs: Max LSA size: # LSAs: # router-LSAs: # AS-External-LSAs: # opaque-LSAs: # name-summary LSAs: # local names # VC lookups: # successful defaults: # QoS failures: # VC reroutes: # VC crankbacks Max task latency (ms): # OSPF trunk inst ch: # Bad paths reg: # VCMGR call backs: # Trunk cost chg neg: # trunk congestion: # VC congestion # policy scans # incremental discrd: # free LISTs: # alloc Opaques: Routing S/W revision: 172.16.1.1 0.0.0.0 6 34147 48 0 6 12 0 0 0 0 0 0 0 0 39 0 0 0 0 73 16 1 0 256 83 11 # reachable switches: # Trunks # Stub links: Database checksum: # network-LSAs: 0 # name-LSAs: 0 6 0 (0) 0 (11) 0x0

# network names: # VC reroute attempts: # specific VC calc.: # VC unreachables: # Multipoint cranks: Max lookup time (ms): # VCMGR trunk inst ch: # VCs using old rev: # VCMGR rpt old inst: # Reg on down trunks: # path congestion: # incremental import: # alloc LISTs: # fwd entries: # returned Opaques: Network S/W revision:

0 0 0 0 0 2 0 0 0 0 8 3 256 23 15 11

The show ospf trunk command shows OSPF information for trunks. If no parameters are passed to the command, it will print out the OSPF information about all the known trunks in the network. There are 7 values reported for each trunk: - sw/prt - the class B subaddress of the node at one end of the trunk, followed by the interface number of the trunk endpoint Lport on that node. - sw/prt - the class B subaddress of the node at the other end of the trunk, followed by the interface number of the trunk endpoint Lport on that node. - fbw2/0 - the available bandwidth in a forward direction on this trunk; - rbw2/0 - the available bandwidth in a reverse direction on this trunk; - delay - the delay associated with this trunk;

02/08/12

Rev 4.0

14

- cost - the trunk's administrative cost; and - comments - comments about the trunk. Possible comments are Init (trunk is in initialization state), Mgmt (trunk is management only), Negbw (trunk has negative bandwidth in one or both directions), or Priv (trunk is a VPN trunk).

SMRC8> show ospf trunks

Shows all trunks in the network, When you do a show ospf trunks 1.4/15, it will show you the details of that particular trunk See the next command example. sw/prt sw/prt fbw2/0 rbw2/0 delay cost comments 1.1/2 1.3/1 3067 3067 73 50 1.1/3 1.2/1 317 317 44 50 1.2/2 1.3/2 3067 3067 37 50 1.2/4 1.4/11 41014 37721 3 50 1.3/3 1.6/9 41014 41014 3 50 1.4/15 1.6/18 30965 27728 30 50 1.4/20 1.5/1 37762 37762 105 50 1.5/2 1.6/26 37762 37762 110 100 For both the 1.1/2 and 1.3/1= the last octets of the switch address, e.g. 158.148.1.1 and the iF# You might see a NOTES column which will tell you what kind of trunk it is; e.g. mgmt and data

ct1acbx1> show tproto 15

(TRUNK PROTOCOL INFO FOR INTERFACE 15 ON SLOT 7:)

State: UP Phy Link State: UP Reason: NONE Proto obj ptr: 7 :0x9121e180 KA gap: 1000ms KA threshold: 10 Last 16 delays measured (in 100us): 298, 299, 299, 299, 298, 298, 299, 299 Trk proto up cnt: Trk proto dn cnt: KA req tx cnt: KA rep rx cnt: KA unknown rx cnt: KA corrupt rx cnt: Spur Trk proto up cnt: Spur Trk proto dn cnt: Lnk up time: 1 0 2958 2958 0 0 0 2 0:48 hrs

Ngbr pvcm ver: Static delay: Dynamic delay:

20 298(in 100us) 298(in 100us)

298, 298, 298, 298, 298, 299, 298, 299, PLinkUp evt cnt: PLinkDn evt cnt: KA req rx cnt: KA rep tx cnt: KA timeout cnt: Spur PLnkUp cnt: Spur PLnkDown cnt: Last lnk dn time: 2 1 2959 2959 0 0 0 0:00 hrs

LnkUp evt cnt in last cycle (1 hour) : 0 LnkUp evt cnt in curr cycle in progress (elapsed time: 49 min) : 1 The following indicates the carrier is using their protocol and if these numbers increment, it would indicate the failure may be caused in the carrier network and not the customers network. Spur Trk proto up cnt: Spur Trk proto dn cnt

02/08/12

Rev 4.0

15

show ospf pathdb [card] | [<Class B subaddress>/<IfNum> <card>] command prints out all the OSPF path database entries on a particular card, or all the OSPF path database entries on a particular card which contain a particular trunk in their entry. The "Class B subaddress" parameter is the last two digits of the IP address of a trunk endpoint node whose references in the path database you wish to find (it does not have to be on the local node). The "IfNum" parameter is the LPort interface number of the trunk endpoint on the node specified by "Class B subaddress". The "card" parameter is the slot number of the card in the local switch whose database you wish to query for the information (the default is the active CP). For each entry in the database specified, the output of the command prints 3 fields: - ID - the ID number of the database entry, in the form of "slot.entry_num", where "slot" is the slot number of the card and "entry_num" is the number of the paths database entry; - # VCs - the current number of VCs on this card that take this path; - Path - the path that this database entry represents. The path is a list of comma-separated entries of the form "Class B subaddress/IfNum", where "Class B subaddress" is the last two digits of the IP address of the hop on the path, and "IfNum" is the interface number of the egress trunk LPort on that hop.

show ospf pathdb 14

ID 14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.9 14.10 14.11 14.12 14.13 14.14 14.15 # VCs Path 0 50.106/1,50.60/15,50.25/1,50.26/30,50.88/1,50.89/4 0 50.106/1,50.60/15,50.25/1,50.26/14,50.96/2,50.22/4,50.3/4 0 50.106/1,50.60/15,50.25/1,50.26/28,50.95/2,50.27/20,50.93/8 0 50.106/1,50.60/15,50.25/8,50.139/1,50.105/2 0 50.106/1,50.60/15,50.25/1,50.26/30,50.88/1 0 50.106/1,50.60/15,50.25/1 0 50.106/1,50.60/15,50.25/8,50.139/1,50.105/2,50.27/20,50.93/8 0 50.106/1,50.60/15,50.25/23,50.100/18,50.119/3,50.112/33 0 50.106/1,50.60/15,50.25/23,50.100/3,50.76/2,50.24/1 0 50.106/1,50.60/15,50.25/23,50.100/18,50.119/3 0 50.106/1,50.60/15,50.25/23,50.100/18 0 50.106/1,50.60/15,50.25/23,50.100/18,50.119/3,50.112/33,1.26/38 0 50.106/1,50.60/15,50.25/23,50.100/18,50.119/3,50.112/33,1.26/39 0 50.106/1,50.60/15,50.25/23,50.100/13,50.141/2,50.50/26 0 50.106/1,50.60/15,50.25/23,50.100/2,50.26/19,50.59/72

show ospf pathdb 50.27/1 8

ID # VCs Path 8.1 0 50.106/1,50.60/15,50.25/8,50.139/1,50.105/2,50.27/1,50.28/3,50.4 9/1,50.50/51,50.141/4,50.100/18,50.119/3,50.112/33,1.26/41,50.35/46 8.3 0 50.106/1,50.60/15,50.25/8,50.139/1,50.105/2,50.27/1,50.28/3,50.4 9/1,50.50/51,50.141/4,50.100/18,50.119/3,50.112/7,50.130/2,50.36/4 8.2 0 50.106/1,50.60/15,50.25/8,50.139/1,50.105/2,50.27/1,50.28/3,50.4 9/1,50.50/51,50.141/4,50.100/18,50.119/3,50.112/7,50.130/2,50.36/4,50.89/8

02/08/12

Rev 4.0

16

The show ospf vcpath <IP Address [card] command shows the path a newly-added circuit would likely take from this node through the network. "IP Address" is the full IP address of the node which you want to find a path to, and "card" is the slot number of the card whose database you wish to query for this information; the default is the active CP. The command will output the following information: - Dest - the IP address of the destination node, as specified on the command line;

- Result - the result of the attempt to find a path to the destination. If this reports "Destination unreachable", this will be the last line reported by the command; - #Hops - the number of hops required to reach the destination node. If this value is 0, i.e. the destination node is the local node, and this will be the last line reported by the command;
- Cost - the admin cost of the path to the destination node;

- Path - the list of hops on the path to the destination node, in the form of a Class B subaddress followed by the LPort interface number of the egress trunk on that node, one of these listings for each hop;
- Forward BW - the minimum available bandwidth on the path to the destination node; - Reverse BW - the minimum available bandwidth on the return path from the destination node; and - Delay - the one-way delay on the path to the destination node.

Switch Name ## show ospf vcpath 172.16.1.4

shows results to remote switch for connectivity. This command will tell you 1) Can switch I am entering this command on reach remote switch? If yes, 2) What tis the path, 3) How much bandwidth is available along this path Dest: 172.16.1.4 Result: Success #Hops: 1 Cost: 100 Path: 1.1/21 #2 above Min capability: 0xf43 Max capability: 0xf43 Transit capability: 0xffff Forward BW: 37762 Kbytes #3 above Reverse BW: 37762 Kbytes #3 above Delay: 0.2 milliseconds show ospf qospath <IP Address> [card] command shows the path a newly-added circuit would likely take from this node through the network. "IP Address" is the full IP address of the node which you want to find a path to, and "card" is the slot number of the card whose database you wish to query for this information; the default is the active CP. Unlike "show ospf vcpath", you can specify some of the parameters to be used in determining the path the circuit would take through the network. You will be prompted for these values after entering the command. The parameters are optional except the QoS values. The parameters you can supply are: - Forward BW (Kbytes) - the CIR the circuit would have, in a forward direction; - Reverse BW (Kbytes) - the CIR the circuit would have, in the reverse direction; - Forward QoS (1-4) - the QoS to use, in a forward direction; - Reverse QoS (1-4) - the QoS to use, in the reverse direction; - Routing priority (0-15) - the priority the circuit would have; - Metric (0-3 adm/dly/cdv/hop) - the metric to use to determine best path for this circuit, admin cost, delay, cell delay variation, or hops; - Current Path ID - the path currently being used, to determine if a reroute is required. Using this simulates sending a reroute request to OSPF; - S/W version (2-9) - the OSPF revision level to use;

02/08/12

Rev 4.0

17

- Characteristics vp=1,cell=2,prv=4,mgt=8 - the characteristics the circuit would have; - E-E Delay (milliseconds) - the desired end-to-end delay; - Private Net ID - the VPN ID. If you specify a non-zero value for this, you will be queried as to whether it is OK to use public trunks in the path; - Void trunk (switch/IFIndex) - trunk (or trunks) you do not want OSPF to use in calculating the path; The command will output the following information: - Dest - the IP address of the destination node, as specified on the command line; - Result - the result of the attempt to find a path to the destination. If this reports "Destination unreachable", this will be the last line reported by the command; - #Hops - the number of hops required to reach the destination node. If this value is 0, i.e. the destination node is the local node, and this will be the last line reported by the command; - Cost - the admin cost of the path to the destination node; - Path - the list of hops on the path to the destination node, in the form of a Class B subaddress followed by the LPort interface number of the egress trunk on that node, one of these listings for each hop. - Forward BW - the minimum available bandwidth on the path to the destination node; - Reverse BW - the minimum available bandwidth on the return path from the destination node; and - Delay - the one-way delay on the path to the destination node.

show ospf qospath 130.130.1.1

Forward BW (Kbytes): 64 Reverse BW (Kbytes): 64 Forward QoS (1-4): 3 Reverse QoS (1-4): 3 Routing priority (0-15): Metric (0-3 adm/dly/cdv/hop): Current Path ID: S/W version (2-9): Characteristics vp=1,cell=2,prv=4,mgt=8: E-E Delay (milliseconds): Private Net ID: Void trunk (switch/IFIndex): Dest: 130.130.1.1 Result: Success #Hops: 1 Cost: 100 Path: 1.2/1 Forward BW: 1425 Kbytes Reverse BW: 1425 Kbytes Delay: 0.4 milliseconds

show ospf namedpath <type <name <length [card] command shows the path that a circuit would take from the current
location to the endpoint represented by "name". Names can be any of the name types identified in the description of "show ospf database". The values for "type", "name", and "length" are obtained from the "show ospf names" command output. The "card" value is the slot number of the card whose OSPF database you wish to query; the default is the active CP. For any name, the command prints out: - the Prefix ("name"/"length"); - the Class B subaddress of the node where the name resides and the interface number associated with the name, if any;

02/08/12

Rev 4.0

18

- the full IP address where the name resides; - the result of the attempt to find the path; - and the number of hops to the node where the name resides. If the number of hops is non-zero (i.e. the name resides on a node other than the local one), the command also prints out: - the cost associated with the path; - the path to the node where the name resides, in the form of a comma-separated list of pairs of Class B subaddress and interface number of the outgoing trunk for each hop; - the available bandwidth in a forward direction on the path; - the available bandwidth in the reverse direction on the path; - and the delay to the node where the name resides.

show ospf namedpath 4 0x781891 24

Prefix: 0x781891/24 Node/Port: 1.2/0 Dest: 130.130.1.2 Result: Success #Hops: 1 Cost: 100 Path: 1.1/6 Forward BW: 1425 Kbytes Reverse BW: 1425 Kbytes Delay: 0.4 milliseconds

Switch Name> next ckt.1.1.2.19

Shows all DLCIs on a particular interface found on the next lport.1.1.2 command (see the command on page 6 for this iF#). Use this command to determine how many DLCIs and their ID#s are associated witht the particular iF #.
1.3.6.1.4.1.277.1.6.1.1.2.19.17 = 17 (Integer) 1.3.6.1.4.1.277.1.6.1.1.2.19.18 = 18 (Integer) 1.3.6.1.4.1.277.1.6.1.1.2.19.19 = 19 (Integer) 1.3.6.1.4.1.277.1.6.1.1.2.19.21 = 21 (Integer) 1.3.6.1.4.1.277.1.6.1.1.2.21.63 = 63 (Integer)

Switch Name ## next ckt.1.1.34.21 Switch Name ## next ckt.1.1.26

Shows # of inbound DE marked frames since last reset 1.3.6.1.4.1.277.1.6.1.1.35.19.65546 = 0 (Counter) This shows the circuit path and outbound interfaces at nodes along circuit 1.3.6.1.4.1.277.1.6.1.1.26.19.65546 = 21:18:19:18:18:18 (OctetString) iF #s 21, 18, 19, 18, 18, 18, 1.3.6.1.4.1.277.1.6.1.1.26.20.65636 = *NULL* (OctetString) 1.3.6.1.4.1.277.1.6.1.1.26.20.65646 = *NULL* (OctetString) 1.3.6.1.4.1.277.1.6.1.1.26.20.65656 = 21 (OctetString) 1.3.6.1.4.1.277.1.6.1.1.26.20.65736 = *NULL* (OctetString) 1.3.6.1.4.1.277.1.6.1.1.27.19.65546 = 13 (Integer)

02/08/12

Rev 4.0

19

Switch Name ## next ckt.1.1.21

Current operational status of entire PVC, 1=inactive, 2= active, 1.3.6.1.4.1.277.1.6.1.1.21.19.65546 = 1 (Integer) 1.3.6.1.4.1.277.1.6.1.1.21.20.65636 = 1 (Integer) 1.3.6.1.4.1.277.1.6.1.1.21.20.65646 = 1 (Integer) 1.3.6.1.4.1.277.1.6.1.1.21.20.65656 = 2 (Integer) 1.3.6.1.4.1.277.1.6.1.1.21.20.65736 = 1 (Integer) 1.3.6.1.4.1.277.1.6.1.1.22.19.65546 = 0 (Integer) Note: if you do a show pvc command, it will show the formula for VPI/VCIs

SF01CS2## get ckt.1.1.26.30.701

30 = ifnum, 701 = VCI, This will give you the ifnum of the egress port in th4e neighboring switch. If you telnet to the next switch and do a show loprt attributes for each number, you get the slot port and remote node information 1.3.6.1.4.1.277.1.6.1.1.26.30.701 = 32:31:27:42:13:14 (OctetString) SFO3CS1## show lport attrib 31 Slot: 8 Port: 2 Interface: 31 Data Rate: 149760000 Trunk Status: Remote Node: Trunk Full 172.16.1.21 Remote Interface: 26

BW Out BW Out BW Oversub Type Avail (cps) Alloc (cps) Qos1 100% dyn 326173 13500 Qos2 300% dyn 978518 11792 Qos3 300% dyn 978518 9315 Qos4 300% dyn 978518 19497 Administrative Status: Up Operational Status:

Up

Switch Name> get ckt.1.1.127.59.724 Gives you the outgoing port number for the adjacent VC entry in this switch. 59= ifnum; 724 = the VCI. You can use the ifnum/VCI or the VC # to check this. 1.3.6.1.4.1.277.1.6.1.1.127.59.724 = 57 (Integer) Switch Name> get ckt.1.1.128.59.724 Gives you the adjacent VC entry corresponding to this circuit across the bus. 7419 = the VC # on the egress port of the switch you are in.. You can use the ifnum/VCI or the VC # to check this.
1.3.6.1.4.1.277.1.6.1.1.128.59.724 = 7419 (Integer)

Switch Name> get ckt.1.1.129.57.7419 Gives you the adjacent VC # for the this circuit across the trunk to the ingress port of the next switch.. You can use the ifnum/VCI or the VC # to check this. 1.3.6.1.4.1.277.1.6.1.1.129.57.7419 = 2245 (Integer) Switch Name> get ckt.1.1.8.30.701 Gives you the ifnum of the end point destination for this circuit. 30 = ifnum of the switch you are in, 701 = the VCI of this switch. 1.3.6.1.4.1.277.1.6.1.1.8.30.701 = 59 (Integer) Switch Name> get ckt.1.1.88.30.701 VC Using the ifnum and VCI you can see the # of ATM cells received on a

02/08/12

Rev 4.0

20

1.3.6.1.4.1.277.1.6.1.1.88.30.701 = 8776942 (Counter) Switch Name> get ckt.1.1.89.30.701 Using the ifnum and VCI you can see the # of ATM cells transmitted on a VC 1.3.6.1.4.1.277.1.6.1.1.89.30.701 = 30332703 (Counter) Switch Name> get ckt.1.1.90.30.701 Using the ifnum and VCI, this gives you the # of ATM CLP0 cells received and discarded on a VC 1.3.6.1.4.1.277.1.6.1.1.90.30.701 = 0 (Counter) Switch Name> get ckt.1.1.91.30.701 Using the ifnum and VCI, this gives you the # of ATM CLP1 cells received and discarded on a VC 1.3.6.1.4.1.277.1.6.1.1.91.30.701 = 0 (Counter) Switch Name ## next interface.2.1.4.20 1.3.6.1.2.1.2.2.1.4.21 = 53 (Integer) Shows the size of the largest datagram sent/recd in octets

Switch Name## show pvc attributes 30.701 Shows the PVC details 30 = if num, 701 = VCI, also shows
the destination node Ip, ifnum, VPI/VCI , how many PVCs are on this port and how many are active. You can use the numbers from pg 18 on the next ckt.1.1.2 command to check the DLCIs current state . this shows ATM information
Src NodeId: 1.9 Src Interface: 30 Src vpi_vci: 701 Src VPI: 0 Src VCI: 701 In Priority: 1 In Effective BW(bps): 0 In QoS: UBR_ABR In Traffic Desc.: 7 Out Traffic Desc.: 7 In TD Param1: 353207 In TD Param2: 0 In TD Param3: 0 Type of Service: 0 Creation time: 3105850 DCE state: 2 DTE status: 2 Interface state: Up Admin Status: 2(Active) PVC state: 6(Active) Operation status: 2(Active) Dst NodeId: Dst Interface: Dst vpi_vci: Dst VPI: Dst VCI: Out Priority Out Effective BW(bps) Out QoS (pcr-01-bestEffort) (pcr-01-bestEffort) Out TD Param1 Out TD Param2 Out TD Param3 Discard enable: Last change: DTE state: Receive ready: Data flow: 1.80 59 724 0 724 1 0 UBR_ABR 353207 0 0 0(Off) 2721490 2 Yes 1

SF01CS2> get lport.1.1.178.30

Gives you another way to get the number of PVCs on the port 1.3.6.1.4.1.277.1.5.1.1.178.30 = 6 (Integer)

02/08/12

Rev 4.0

21

Switch Name ## sho pvc attrib 20.65656

20 = ifnum of the PVC #65656 Src NodeId: 1.1 Dst NodeId: 1.4 Src Interface: 20 Dst Interface: 20 Src vpi_vci: 65656 Dst vpi_vci: 65636 Src VPI: 1 Dst VPI: 1 Src VCI: 120 Dst VCI: 100 In Priority: 1 Out Priority 1 In Effective BW(bps): 0 Out Effective BW(bps) 0 In QoS: UBR_ABR Out QoS UBR_ABR In Traffic Desc.: 7 (pcr-01-bestEffort) Out Traffic Desc.: 7 (pcr-01-bestEffort) In TD Param1: 353207 Out TD Param1 96000 In TD Param2: 0 Out TD Param2 0 In TD Param3: 0 Out TD Param3 0 Type of Service: 0 Discard enable: 0(Off) Creation time 8234380 Last change: 65900 DCE state: 2 DTE state: 2 DTE status: 2 Receive ready: Yes Interface state: Up Data flow: 1 Admin Status: 2 (Active) PVC state: 6 (Active) Operation status: 2 (Active)

Switch Name## sho soft flash

Active CP Software:: Part# Revision 7000910100 4.02.07.16 7000900100 4.02.07.00 7000910200 7000900200 7000914600 7000904600 7000914700 7000904700 4.02.07.16 4.02.06.00 4.02.07.16 4.02.07.00 4.02.07.16 4.02.06.01

Shows the software currently in Flash for that switch Size 704709 167781 795740 123761 732979 160077 742759 165554 Description CP Application [28-P00000075] CP Boot FLASH 872490 Total IOPA Application [28-P0000005D] IOPA Boot FLASH 919501 Total IOPB Application [28-P0000003C] IOPB Boot FLASH 893056 Total IOPC Application [28-P0000002F] IOPC Boot FLASH 908313 Total Description CP Application [28-P00000075] CP Boot FLASH 872490 Total IOPA Application [28-P0000005D]

Standby CP Software: Part# Revision 7000910100 7000900100 7000910200 4.02.07.16 4.02.07.00 4.02.07.16

Size 704709 167781 795740

02/08/12

Rev 4.0

22

7000900200 7000914600 7000904600 7000914700 7000904700

4.02.06.00 4.02.07.16 4.02.07.00 4.02.07.16 4.02.06.01

123761 732979 160077 742759 165554

IOPA Boot FLASH 919501 Total IOPB Application [28-P0000003C] IOPB Boot FLASH 893056 Total IOPC Application [28-P0000002F] IOPC Boot FLASH 908313 Total

Switch Name ## show software disk Shows the software loaded to disk. To see software that is currently running- use the show system command.
Active CP has the following software: Set A: Part# 7000910100 7000900100 7000910200 7000900200 7000914600 7000904600 7000914700 7000904700 7000914900 7000904900 8000900100 Set B: Part# Revision 7.02.00.00 7.01.00.05 7.02.00.00 7.00.00.00 7.02.00.00 7.01.00.01 7.02.00.00 7.00.02.01 6.02.05.10 6.02.05.10 1.00.05.00 Revision Size 1267140 179396 959943 120085 1092333 165500 1190641 165021 1103547 553936 143958 Size Description CP Application [30-R00000059] CP Boot Flash IOPA Application [30-R0000001A] IOPA Boot Flash IOPB Application [30-R00000058] IOPB Boot Flash IOPC Application [30-R00000018] IOPC Boot Flash IOP5 Application [65-P0000001C] IOP5 Boot Flash [65-P00000012] CP Extended POST Description

Standby CP has the following software: Set A: Part# 7000910100 7000900100 7000910200 7000900200 7000914600 7000904600 7000914700 7000904700 7000914900 7000904900 8000900100 Set B: Part# Revision 7.02.00.00 7.01.00.05 7.02.00.00 7.00.00.00 7.02.00.00 7.01.00.01 7.02.00.00 7.00.02.01 6.02.05.10 6.02.05.10 1.00.05.00 Revision Size 1267140 179396 959943 120085 1092333 165500 1190641 165021 1103547 553936 143958 Size Description CP Application [30-R00000059] CP Boot Flash IOPA Application [30-R0000001A] IOPA Boot Flash IOPB Application [30-R00000058] IOPB Boot Flash IOPC Application [30-R00000018] IOPC Boot Flash IOP5 Application [65-P0000001C] IOP5 Boot Flash [65-P00000012] CP Extended POST Description

02/08/12

Rev 4.0

23

Switch Name## show pram 2

Just show pram will show pram of active SP/CP/NP. Show pram 2 will show pram of standby SP/CP/NP. - make sure the checksum matches With the controller cards and Signature has entry NEVER 0000000 Configuration Database version=7.77, tables=48, checksum=00002651 signature=38FDEEA4 size=720896 Table Idx Offset Length RSize Max Count net 909BE9D0 800 223 87 1 1 node 909BEA40 1023 855 615 1 1 card 909BEAC0 1878 246 154 1 1 ase 909BEB70 2124 5148 20 256 1

Switch Name ## show pram 3

You can do this for any IOM or IOA Configuration Database version=7.77, tables=15, checksum=00008B6D signature=38FDEA6B size=753664 Table card pport lport path Offset 800 1006 4366 72510 Length 206 3360 68144 4328 RSize 86 130 542 43 Max 1 24 124 100 Count 1 1 0 0

Switch Name ## show tr

Shows what application you can do a trace on - SEE ESCALATION. This has an impact on the SP/CP/NP processor utilization. We try to use in environments where SP/CP/NP has low utilization CPU INTENSIVE (Ctl L turns this on and off) APPLICATION STATE LEVEL REDIRECT msgmgr(00) CLOSED 0 0 vcmgr(01) OPEN 0 0 svc(02) CLOSED 0 0 addrmgr(03) OPEN 0 0 ume(04) CLOSED 0 0 rrmgr(05) OPEN 0 0 cfgmgr(06) CLOSED 0 0 ltp(07) OPEN 0 0 stats(08) CLOSED 0 0 bsmgr(09) CLOSED 0 0 bsftp(10) CLOSED 0 0 nrts(11) CLOSED 0 0 cug(12) OPEN 0 0 spvc(13) OPEN 0 0 frsvc(14) CLOSED 0 0 BGP(15) OPEN 0 0 mpt(16) OPEN 0 0 prtcon(17) OPEN 0 0 RIP(18) OPEN 0 0 IPFILTER(19) OPEN 0 0 IPIFARP(20) OPEN 0 0 policy(21) CLOSED 0 0 ucore(22) CLOSED 0 0 nhrp(23) OPEN 0 0

02/08/12

Rev 4.0

24

igmp(24) cac(25) snmp(26) RADIUS(27) dvmrp(28) warmStt(29) SwMgr(30) rlmi(31 cktprim(32) downlink(33)

CLOSED OPEN OPEN CLOSED CLOSED OPEN OPEN OPEN OPEN CLOSED

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

Switch Name ## reset system

Resets the switch ARE YOU SURE <YES|NO> ? yes RESETTING SWITCH, STAND BY.... Switch Name ## Mon960 Now looking for software image from boot flash bank address 0xf0040000 ASSEMBLY: 8000900100 REVISION: 01.00.05.00 DESCRIPTION: CP Extended POST SUB-ASSEMBLIES: P/N REV ADDRESS 7000904601 01.00.01.00 0xf004008a 7000904613 01.00.00.00 0xf00584b9 7000903814 01.00.00.00 0xf0060f09 7000903817 01.00.00.00 0xf006212c Now executing extended POST. Now looking for software image from boot flash bank address 0xf0000000 ASSEMBLY: 7000900100<CP Boot FLASH REVISION: 04.02.3c.01 DESCRIPTION: CP Boot FLASH SUB-ASSEMBLIES: P/N REV ADDRESS 7000900102 04.02.3c.01 0xf000010a 7000900103 04.02.3c.01 0xf00014b4 7000903814 04.02.3c.01 0xf002018c 7000903817 04.02.3c.01 0xf00213af 7000904607 01.00.00.00 0xf00224d9 7000904608 01.00.00.00 0xf002321e 7000904612 03.01.5f.00 0xf0027db5 Press BREAK

Switch Name ## toggle card 1

You can toggle any redundant card Redundant state of card 1 has been toggled MAKE SURE YOU CHECK THE VERSION AND PRAM

Switch Name> show ip route

02/08/12

Rev 4.0

25

Dest Next_hop State Cost Lport Age Ckt m192.168.1.1/32 192.168.1.2 OSPF 200 29 * m192.168.1.2/32 192.168.1.2 OSPF 100 29 * m192.168.1.3/32 192.168.1.2 OSPF 200 29 * m192.168.1.4/32 192.168.1.2 OSPF 300 29 * m192.168.1.5/32 192.168.1.2 OSPF 300 29 * m192.168.1.6/32 192.168.1.2 OSPF 300 29 *

Switch Name> show pvc

To get the formula to figure out the VPI/VCI show pvc [statistics|attributes] interface.vpi_vci where interface = ifIndex of logical port and vpi_vci = vpi*65536 + vci Example: customer gives you the VPI/VCI of 4/33 then the formula would give you: (VPI) 4 * 65536 = 262144, 262144+33 (VCI) = 262177 This is the circuit # You can also do the following command to get the Circuit Number: Another useful tool is to get the trap log on the NMS by doing the following commands:

$ cd /opt/OV/log $ tail -f trapd.log

932681845 7 Thu Jul 22 17:17:25 1999 snfccs7.wcom.com - LPort snfccs7.15.1.6(15,1) at switch snfccs7 has congest rate 92% (exceed threshold 50%);2 .1.3.6.1.4.1.277.10.0.18 0 932681846 7 Thu Jul 22 17:17:26 1999 lsa1cs6.wcom.com - Circuit unitedre_wz804961-wz850432 at switch lsa1cs6 has been re-routed;1 .1.3.6.1.4.1.277.10.0.21 0 932681847 7 Thu Jul 22 17:17:27 1999 dll1cs1.wcom.com - LPort sbcs,inc_wz804642(9,1) at switch dll1cs1 has encountered 916405 frame errors (exceed threshold 64).;2 .1.3.6.1.4.1.277.10.0.23 0 932681847 7 Thu Jul 22 17:17:27 1999 lnd1cs1.wcom.com - LPort salomon_wz917727(15,3) at switch lnd1cs1 has encountered 912165 frame errors (exceed threshold 64).;2 .1.3.6.1.4.1.277.10.0.23 0 932681847 7 Thu Jul 22 17:17:27 1999 hstncs1.wcom.com - Circuit konica_wy105437-wz512354 at switch hstncs1 has been re-routed;1 .1.3.6.1.4.1.277.10.0.21 0 932681848 7 Thu Jul 22 17:17:28 1999 sttlcs2.wcom.com - LPort failure_wz582937(7,1) at switch sttlcs2 has congest rate 55% (exceed threshold 50%);2 .1.3.6.1.4.1.277.10.0.18 0 932681848 7 Thu Jul 22 17:17:28 1999 dnvrcs4.wcom.com - LPort nrcs_wz923960(14,3) at switch dnvrcs4 has encountered 1844269 frame errors (exceed threshold 64).;2 .1.3.6.1.4.1.277.10.0.23 0

02/08/12

Rev 4.0

26

LPORT Conflict Resolution Information

addit"Lport Conflict" Duplicate Interface Numbers reported by CBX-500 after card change Introduction/Definition Interface numbers (ifnums) are assigned by the NMS to each Lport and Pport on the CBX-500.Ifnums are assigned to Lports as the user creates them and assigned to Pports automatically when the card is added to the system. Each IOM and SP manages its own proxy table that contains entries for each ifnum on the node, including that ifnum's slot and port data. Whenever an ifnum is de-allocated in the node, either by an NMS Lport deletion or NMS IOM deletion, the card where that ifnum resided sends messages to all of the other cards in the system, informing them that they must remove the ifnum entry from their proxy table. In addition, the NMS will put the ifnum back into its "available" queue.
Producing an Lport Conflict

An Lport conflict is a discrepancy between an IOM or SP's proxy table entry for a particular ifnum, and the data being broadcast by the slot where the ifnum resides. Whenever an Lport or card is deleted by the NMS and the actual card is unreachable, or not installed, there is no way for the card to receive the "invalidate ifnum" SNMP set from the NMS and and turn tell the rest of the cards in the switch to update their proxy tables by invalidating its ifnums. In this situation the NMS will still register the ifnums back into its "available" queue for future assignment. When these ifnums are reassigned either to Lports or dummy-Lports, these ifnums represent Pports and are automatically assigned to the Pports of a card when the card is first configured on the node. There is a card present or added, the ifnums will be broadcasted to the other cards as an update to their infum/port tables. If this does occur a 'duplicate interface number' scenario will occur and the user may see an Lport conflict. This could happen on any card that hasn't been rebooted whenever a user adds another port to the system - in ten minutes, or ten months.

Reproduction Efforts

We are able to recreate this lport conflict by taking a card with known lports, pull this card and make it unreachable, and then via the NMS delete the lport. This did cause an SNMP timeout and in turn the 'IGNORE' option was selected which changed the NMS but not the node since the destination card was unreachable. See above explanation for a description of the condition. In all of the Lport conflicts reproduced in our labs, we were able to remedy the situation by warmbooting the cards reporting the error.
Fixing the Problem

IOM and SP proxy tables are restructured at startup time. To completely remedy the lport conflict being reported by any IOM or SP, that IOM or SP must be either warmbooted or coldbooted. A pram synch from the NMS works because it's followed by a warmboot. A warmboot will suffice and saves time over a pram synch. A pram synch alone, or reset pram, will not fix the problem.
Proposed Workaround

To prevent an Lport conflict, the user must make certain to delete all PVCs, trunks, lports, and card on the node while the card is still present. These variables must be deleted before changing a slot to "empty" on the NMS. Following this rule should prevent the lport conflict from happening.

02/08/12

Rev 4.0

27

Process to Move Cards

Below are some steps that can be taken prior to moving cards. I will also include some other info re: cleaning up switches where cards may have already been moved or no longer exist. 1.) Should the customer want to move a card from slot 3 to slot 6 I.E. All config information should be removed from the card in slot 3 while the card is still active in switch. This will delete from both the database on NMS and config on card itself .All other cards in the switch will also delete lport attributes that existed for this card . Once this is done , telnet to switch and "reset pram 6 " , this will remove config from harddrive on CBX500 . Card should be in sync at this point , and you will need to remove the card from the NMS database . After the card has been removed from the NMS database, it can be moved to its new slot . This procedure will work well in cases where card to be moved is reachable from the NMS . 2.) For other case, such as " red " cards showing on NMS , these will be more difficult and will require telnetting to switch and issuing a few commands . It may also be necessary to verify physically that the card is not there . Telnetting to the switch and issuing a "show card " command will verify that the software does/does not see a card for a particular slot . If customer comes across a switch that shows red cards , the card should be removed from the NMS by selecting the slot and setting the attributes of the card to " empty card " . After this is done , you should telnet to the switch and issue a " reset pram slot# " to make sure that a config file no longer exists in this slot . This will stop other cards from loading the config files should they ever be installed into an empty slot that previously had a card installed . 3.) If there have been cases where cards have been moved in an emergency situation and config information could not be removed, there is really nothing we can do to avoid lport conflicts . The reason for this is that all cards in a switch will contain lport tables of all other cards in the switch in which they have pvc's , svc's attached to . When the procedure in # 1 above is followed, all other cards will remove this information, therefore , when the card is removed as # 1 above , no lport conflicts should exist . Preventing the Problem Guidelines for preventing lport conflict conditions from occurring: 1. When permanently deleting a card configuration from a managed node make sure to delete all associated variables properly. See below steps for deleting IOMs properly. 2. If the card is not present then re-insert the card and delete it properly. 3. If the card is not present the user needs to perform a 'reset pram x', where x= slot number, and then perform a 'reset system'. After the node has recovered then perform a 'next lport.1.1.2' SNMP Get from the command-line interface. This SNMP Get will list the interface numbers and the cards that they are present on. Verify that there are no invalid interface designations. Proper method for deleting an IOM To prevent an Lport conflict, the user must make certain to delete all of the card specific parameters properly while the card is still installed and manageable in the node. The following list should be used as a reference and should be performed in the order listed: 1. Delete all PVCs that may have endpoints on any lport defined on the card. 2. Delete any trunks that may have an endpoint defined on the card.

02/08/12

Rev 4.0

28

3. Delete all lports that reside on any Pport on the card. If there are any remaining trunk or PVC endpoints that have not been deleted from the configuration the system will not allow the lport to be deleted. 4. Delete the card from the node by making the card type equal to 'Empty Card'. 5. Pull the card to be removed. If the card is to be replaced by a card of a different type then insert the new card, wait until it is seen in an active state via the 'show card state' command while logged into the node via TELNET, and then define the slot via the NMS to reflect the type just inserted. 6. The new card can now be configured as desired.

Sahara (AX) Menu Descriptions

General Rules: To back out of a screen = escape twice; to move within screen = Tab/arrow key (may just use arrow In certain areas , scrolling in the ICME box , F2 to select configuration parameters; Must hit Apply after making changes, MUST SAVE To save the config changes. 2. General settings for the communication to the Sahara: Direct Connect- Com 1, 38400, N-8-2, VT100, Zmodem
1. 3.

Administration:
Shows the Software Revision loaded in the box and system up time (upper section) System Info Type of system, e.g. AX100, time, Location of the system, and contact name Security Shows the users list and access rights; you can add users in this screen System Timing Where you set the system level timing both primary and secondary IP Routes set the path to the next hop. (destination address and mask is 0.0.0.0; next hop = the address of the next hop IMLI Node Prefix shows the registration address e.g. Type E164, Signaling Config Setting up SVC data ATM Routes Call routes SVC Set-up Bulk Stats Config (5.0 and above) Sets up the Bulk stats server address and parameters

4.

Monitor:

Shows the status of the slots (1, 3, 5, etc.), primary and secondary timing status, # of connections, Fan status, SUM status, Power status (upper section) Proc Utility Processing utilization should be less than 90% most of the time Inventory assembly part #/part code, serial #, and hardware information for both the CPOD and ICME Specific ICM/ICME Processing memory must be 32MB POD Information - Slot#-POD#, POD Type, Admin Status, Oper Status and Inventory (same as above) Cell Highway/Priority Que Stats shows the state of the cell highway and Pri Que allocation CAC Bandwidth Stats shows the available and variable bandwidth stats, % variable BW used Pro Acc Stats Receive and Transmit cell Count, next level shows the details MIB II Stats show the mib vaiables data ASPVC Stats Shows the traffic statson the ASPVC

5. Diagnostics
Cell Hwy, Port Loopback, F4/F5, and :SVC

6. Utilities
Allows you to save config changes without rebooting, gets you to the OASOS prompt (dos like prompt),

02/08/12

Rev 4.0

29

File Management Allows you to save config Zmodem We dont use this Exit to Shell brings you to the OASOS prompt Do an ls to list files loaded Config Fallback IP (on 1st startup) Core IP, Acess IP, WAN IP Reboot and load software via zmodem mode (rz)
7. 8.

Event Manager Allows you to set trap and filters captures to a management station

Interface Management Physical configuration menus ICM list choose the ICM - POD - Port Reset System will reset the system CAC displays the CAC config, set pool %, load % VC Buffer Config allows you to set the buffer allocation for congestion control based on service

type Will lead you to other layers to configures e.g. Service management ATM UNI
9.

Service Management You can view the ATN UNI, Circuit Emulation, Frame Relay, Inverse Multiplexing, Native LAN, and Compression Tunnels and circuits.

Voice

What Clock Source to use on AX device on the System and Port levels
When do you use each type Choices: System Level (Administration---> System Timing) Configure Primary Source: Internal : The AX uses its own internal clock source as the primary clock External : Not currently supported Recovered : AX unit uses the timing from (recovered) an interface external to the to the AX (CBX500). Use the S-P-P of the POD the connection is made to the external clock source in the RX IF field Configure Secondary Source: (fallback clock source if the primary fails) Internal : The AX will use its own internal clock source if the primary clock fails (default if using Recovered as Primary) External : Not currently supported Recovered : AX unit will use the timing from (recovered) an interface external to the to the AX if the primary clock fails. Use the S-P-P of the POD the connection is made to the external clock source in the RX IF field NOTE: Never disable alarm reporting on any port used for primary and secondary Recovered timing. If you want to have the clock revert back to it's Primary source, set the "Set Auto Revert" to Yes. Port Level: In Main Menu: Interface Management--->ICM --->POD--->Port

02/08/12

Rev 4.0

30

For CES DS1: Loop The port transmit timing source is derived from the timing signal coming INTO this port System (default) The system timing provides the transmit timing for this port. (use this if Recovered is configured in the System Timing screen) LocalThe POD's internal timing source will provide the transmit for this port For OC3: LoopTiming The port transmit timing source is derived from the timing signal coming INTO this port SystemTiming (default) The system timing provides the transmit timing for this port. (use this if Recovered is configured in the System Timing screen) LocalTiming The POD's internal timing source will provide the transmit for this port

Notes about Remote Management

You should note that the remote management connection established using the procedures in this chapter is saved as part of the nv_db.dat configuration file. If the nv_db.dat file is renamed, deleted or becomes corrupted, the remote management connection parameters will be lost.

Setting up a Connection to a Remote PSAX Unit

It is not necessary to have a direct PC-to-AX unit physical connection or even an Ethernet connection to manage a PSAX unit. WebXtend makes it possible to remotely manage PSAX units over ATM connections, as shown in Figure G-1.

Figure G-1. Remote Management of PSAX Units without Ethernet Ports

The following instructions make several assumptions:  All PSAX units have been properly configured with IP addresses as described in Changing the IP address on page 2-5. (If the remote PSAX units are on different subnets than the local PSAX unit)The

02/08/12

Rev 4.0

31

PSAX units have IP routes defined to the next-hop router or core ATM switch in

the network, so that management traffic to the PC may be correctly routed. The Ethernet connection between your PC and the local PSAX unit has been made as described in Making an Ethernet Management Connection on page 4-34 of the Hardware Installation Guide. The ATM network connections between the local and remote PSAX unit have been made, including any intermediate switching connections (in the ATM cloud). Follow the instructions below to prepare a PSAX unit for remote management, then configure your local PSAX device to connect to the remote unit, as described on page G-5.

Preparing a PSAX unit for remote management

To prepare a PSAX unit for use as a remote unit: 1. Log in to the PSAX unit using the craft interface as described in Accessing the Craft Interface on page A-7. 2. Select Service Management at the Main menu. 3. From the Service Management window, select Native LAN Service, then select the appropriate slot (ICM) to open the LAN Interfaces window. 4. From the LAN Interfaces window, select Add Bridge Group. 5. Complete the Add NLS Group window as described in Adding a Bridge Group on page 5-96. In the IP Management frame, set the Select IP Access to IP, and enter the IP Address and Subnet Mask you wish to use to access this unit. Choose OK to add the new group and return to the LAN Interfaces window. 6. From the LAN Interfaces window, select the group created in step 5 to open its LAN Interface Options window. 7. From the LAN Interface Options window, select the Tunnels button. 8. From the NLS Tunnels window, select Add Tunnel. 9. Complete the Add Tunnel window as described in Creating Tunnels for an NLS Bridge Group on page 5-101. In the VPI and VCI fields, define a VPI and VCI for this connection. Choose OK to close the window and confirm the new tunnel. The PSAX unit is now ready to serve as a remote unit, able to receive management connections from your local PSAX unit and web browser.

Creating the connection from local to remote

To set up a management connection to a remote PSAX unit: 1. Log in to the local PSAX unit using your browser as described in Accessing WebXtend on page 2-7. 2. Select Service Management at the Main menu. 3. From the Service Management window, select Native LAN Service, then select the appropriate slot (ICM) to open the LAN Interfaces window. 4. From the LAN Interfaces window, select Add Bridge Group. 5. Complete the Add NLS Group window as described in Adding a Bridge Group on page 5-96. Choose OK to add the new group and return to the LAN Interfaces window. 6. From the LAN Interfaces Groups window, select the group created in step 5 to open its LAN Interface Options window. 7. From the LAN Interface Options window, select the Tunnels button.

02/08/12

Rev 4.0

32

8. From the NLS Tunnels window, select Add Tunnel. 9. Complete the Add Tunnel window as described in Creating Tunnels for an NLS Bridge Group on page 5-101. In the VPI and VCI fields, enter a VPI and VCI for this ATM connection. If the ATM connection you are creating is a point-to-point connection directly from the local to the remote unit, the VPI/VCI should match the VPI/VCI assigned to the remote unit. Otherwise, enter the VPI/VCI of the next device within the ATM cloud. Choose OK to close the window and confirm the new tunnel. You have now established a connection from your PC over Ethernet through the local PSAX unit and from the local PSAX unit over the ATM network to the remote PSAX unit. To manage the remote PSAX unit, enter its IP address into your browser. The connection will be made to the remote PSAX unit and you will be prompted to log in.
SA CORIP Configuration:
Overview: The sa_corip command will allow the user to establish a single IP management tunnel between the SA units and the CBX500/550 switches via a management VPI/VCI across an ATM WAN. The functionality removes the requirement of configuring PVCs across the CBX500/550 backbone for the purpose of carrying SA management traffic. SA Configuration: From the utilities menu on the SA main menu, exit to shell. If an nv_db.dat file exists, rename it to nv.old. From the oasos> prompt, the type sa_cfg. OASOS> sa_cfg Enter new fallback IP address [152.148.128.187]: Enter new fallback IP subnet mask [255.255.255.0]: Enter console port baud rate [38400]: Enable WAN IP (y/n) [n] ? Enable CORE IP (y/n) [n] ? (Choose Y to enable CORIP) Enter CORE IP addr [0.0.0.0]: (Enter an IP address belonging to the same subnet as the CBX500/550 internal IP address) Enter CORE IP remote addr [0.0.0.0]: (Enter the internal IP address of the CBX500/550) Enter CORE IP subnet mask [0.0.0.0]: (Enter the subnet mask) CORE IP service rate selections... 1: 64 Kbps 2: 128 Kbps 3: 256 Kbps 4: 512 Kbps 5: 1544 Kbps 6: 2048 Kbps Enter CORE IP service rate [(invalid)]: (Enter a service rate) slot [0]: (Enter ATM WAN trunk slot on the SA unit) pod [0]: (Enter the ATM WAN trunk POD on the SA unit) port [0]: (Enter the ATM WAN trunk port on the SA unit) vpi [0]: (Enter the VPI configured in the CBX500/550 management VPI/VCI) vci [0]: (Enter the VCI configured in the CBX500/550 management VPI/VCI) You have entered ...( The following is a summary of the configuration) Fallback IP address: xxx.xxx.xxx.xxx Fallback IP subnet mask: 255.255.255.0 Console port baud rate: 38400 WAN IP Enable: n CORE IP Enable: y CORE IP addr: xxx.xxx.xxx.xxx CORE IP remote addr: xxx.xxx.xxx.xxx CORE IP subnet mask: xxx.xxx.xxx.xxx

02/08/12 CORE IP service rate: 512Kbps CORE IP PVC parameters... slot: 1 pod: 3 port: 1 vpi: 1 vci: 32

Rev 4.0

33

Is this correct (y/n) [n] ? (If satisfied with the configuration above choose yes to save) In addition, access administration from the SA main menu and select IP routes. Configure the Ethernet address of the CBX500/550 as the default route. CBX Configuration: From the Set all management VPI VCI menu: Add a management VPI/VCI. Select the port attached to the SA unit and specify a VPI/VCI. Make sure that the management VPI/VCI configured here is the same as the one configured in the SA unit during the sa_corip configuration. From the Set all management paths menu: Select management VPI/VCI (the default is ethernet). Select the appropriate management VPI VCI name. For the IP address, fill in the CORIP address of the SA unit. A PRAM sync must be performed to enable the management VPI VCI

----------------------------------------------------------------------------------------------------------------------------------------Anyone have a select statement that returns CircuitNames from 1 switch only?? possibly by slot and/or port or anything close that I can modify? mine are all striking out; can't get the correct key's between Circuit and Switch table... 1> select * from VCircuit 2> where SwitchKey1 = (SwitchKey) 3>go (This gives you the list of all the circuits in this switch with the specified SwitchKey) --Boon RaymondSorry I'm so slow to repond to you but I just ran into the same problem. As a matter of fact, here in Alameda we have opened an Action Request for Westford TAC. The ticket number is 644754. Here what the problem is: First, the installation guide for 08.00.03.00 is poor at best. give you the proper procedure to extract the gzipped Sybase installation file. It doesn't even

Second, your exact problem is due to the fact that the .profile for Sybase is not installed with Sybase or Naviscore. There are two files under the /opt/sybase directory. They are the .sybenv file and the SYBASE.sh file. You can use these 2 files to create the environment variables that must be present for Sybase to run. Vi the .sybenv file and it will give you

02/08/12

Rev 4.0

34

the proper syntax to execute the SYBASE.sh file. You must execute this file logged in as the sybase user. After this file is run you must reference the entries in the .sybenv file for the SYBASE and DSQUERY variables and create these variables again under the sybase user. One last caveat, the paths in the SYBASE.sh file are incorrect so you must use the absolute path while executing the isql command. It is something like /opt/sybase/ASE-12_5/bin/isql -Usa -Psuperbase. Hope this helps and I'll let you know when I get the installation docs updated and Westford creates new installation discs. Paul -----Original Message----From: Adam, Raymond (Raymond) [mailto:adamr@lucent.com] Sent: Monday, June 10, 2002 6:53 PM To: acn@ascend.com Subject: Sybase ASE 12.5 default sa password Dear Engineers: I have installed sybase ASE 12.5 on my sparc machine. Both dataserver and backup are running. However I can't log into the server via isql. It does not accept any password I configure, including superbase. Is there a special password to use with this Europa8 MR1 sybase? I am running Solaris 8 and I was able to install HPOV 6.2, but I can't install naviscore8.0.3 because sybase will not accept my sa password. FolksHere's a quick explanation of how X works and the basics of fonts in Xwindows. Xwindows is a multi-platform windowing system developed by the X/Open Consortium for GUI interfaces to UNIX systems. The terminology used in working with the X systems is confusing, as it can be contrary to common thinking. In Xwindows, the SERVER is the machine running the Xwindows environment (CDE, KDE, OpenMotif, etc.), and the CLIENT is the program (running on a remote machine) that is sending a display to the SERVER. So, contrary to the idea that the SERVER sends information to a CLIENT, in Xwindows, a SERVER provides the graphical interface into which a CLIENT program can send its' display. The .Xdefaults file is the user-config for Xwindows. .Xdefaults, in the user's home directory, contains information parsed by the X server when it is starting up. For any new information to be read by the X server, it must be restarted. Note that the CLIENT programs have no effect on the X SERVER, but that the X SERVER governs such things as font size and X environment variables. Any time a program requires X environment variables (such as HPOV's requirement for Ovw*unknownStatusLineColor and Ovw*upStatusLineColor to be defined) they MUST be defined on the X SERVER box, not on the machine that the client programs are running on. shok, Modify the two lines in /opt/nms/.Xdefaults (add the colon)

02/08/12

Rev 4.0 Ovw*unknownStatusLineColor: blue Ovw*upStatusLineColor: #00e626

35

You do not need to reboot the server but will need to restart your session. You will also need to copy .Xdefaults to the user directories for all the user that will be using NavisCore. --Boon Just a note. I recently had the same problem at a customer site, when installing an NMS. With help from Boon, I found that I could get the display to be perfect with just a few alterations. The monitor I had to work with was 19" at best, and it was an actual Sun machine - not a clone. All you have to do is make sure that your .Xdefaults file is in your users home directory and fixed with the addition of the missing colons. Then, adjust the resolution to the highest that particular video card can stand, and your problem is fixed. You adjust the video card driver resolution settings in Solaris by running the /usr/sbin/(driver config utilitiy), mine was the m64config. Run it with the options to check the present settings and then run it with the res option to change the settings to a resolution that will work with Naviscore. Once you change the driver config you have to reboot the box, but it is that simple. Hope this helps.