Modification Release 3.5 The small hardware platform was introduced. Release 4.1 In Release 4.1, SS7 signaling is sent via SIGTRAN to an Internet transfer point (ITP), therefore, dedicated SS7 cables are not attached to the Cisco BTS 10200 Softswitch. These cables have been deleted from this document. This feature module is intended for use by service provider engineering and field personnel who are responsible for designing, installing, configuring, and maintaining networks that use the Cisco BTS 10200 Softswitch. The procedure in this feature module describes how to cable one type of Cisco BTS 10200 Softswitch.

This document is in addition to other Cisco BTS 10200 Softswitch documents that describe how to install and operate the system. Contact your Cisco account team for the documentation applicable to your specific system.

Mar 24, 2010 Sun Fire V120 as NAS part 1: Installing Solaris 10 and drivers. I have a SunFire V120 and a Storedge S1. To connect to the server console we.

Scope and Purpose This procedure is applicable to Cisco BTS 10200 Softswitch systems that are installed on the small hardware platform, SunFire/Netra 120 option, purchased in a reference sale. In a reference sale, the service provider purchases host machines directly from the manufacturer, based on a reference specification provided by the Cisco account team. Note Documentation for the Sun Fire V120 server and Netra 120 server is available on the Sun Microsystems website, www.sun.com.

These documents include front and rear views of the equipment, and instructions for power cabling and general signal cabling. The reference sale also requires two customer supplied Cisco Catalyst 2924M XL Fast Ethernet switches. In addition, you must have an appropriate power distribution unit and an (optional) alarm panel in your rack. The purpose of this procedure is to explain how to: • Cable a new Cisco BTS 10200 Softswitch system • Enable Internet Control Protocol (ICMP) Router Discovery Protocol (IRDP) functionality on the Cisco BTS 10200 Softswitch and on the Cisco routers adjacent to the Cisco BTS 10200 Softswitch. Caution Do not use this procedure to change the cabling of an in-service Cisco BTS 10200 Softswitch, because that will cause interruption of service. It you need to change the cabling of in-service system, you must first contact your network administrator or your Cisco account team for a procedure. Before You Start Before you start cabling the system, perform the following verifications.

Verify that the hosts are already mounted in the rack according to manufacturer instructions, and labeled appropriately. Your system should have the following hardware units: – EMS Side A – EMS Side B – CA Side A – CA Side B – Cisco 2924M Ethernet Switch A – Cisco 2924M Ethernet Switch B – Power distribution unit (DC systems) – Terminal server or alarm panel (if specified in your local documentation) 2. Ask your supervisor or an authorized power installer to verify that appropriate power feeds are available, as defined in the site survey documentation for your system. The electrical power for your system must come from two separate (redundant) sources, so that a single point of failure does not cause a complete system outage.

Warning IMPORTANT SAFETY INSTRUCTIONS This warning symbol means danger. You are in a situation that could cause bodily injury.

Before you work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standard practices for preventing accidents. Use the statement number provided at the end of each warning to locate its translation in the translated safety warnings that accompanied this device. Statement 1071 SAVE THESE INSTRUCTIONS Network Diagram shows the physical interfaces and network connections. Figure 1 Network Diagram. Acronyms and symbols used in: EMS/BDMS = Element Management System/Bulk Data Management System CA/FS = Call Agent/Feature Server EMSA = EMS/BDMS Side A; EMSB = EMS/BDMS Side B CAA = CA/FS Side A; CAB = CA/FS Side B OMS Hub = communication interfaces between EMS/BDMS and CA/FS over OMS Hub VoIP = Voice over IP signaling * = Physical IP address ** = Logical IP address Notes for: 1. Championship Swim Training Bill Sweetenham Pdf Reader. The IP addresses shown in the figure are for illustration purposes only.

IP address examples that begin with 10.89 indicate externally viewable addresses, and those beginning with 10.10 indicate internal nonroutable addresses. The actual IP address data for each Cisco BTS 10200 Softswitch is in the Network Information Data Sheet that was supplied with your specific system. 'To external NEs' refers to any of the following links in the service provider network: • Uplinks for external access to hosts, used for management services (via SSH, SFTP, and so forth) and outbound billing data (via FTP) • Uplinks for external communications, used for connection to external NEs and DNS services via IRDP-enabled network. Note NE = Network element SSH = Secure shell SFTP = Secure file transfer protocol (FTP) DNS = Domain name server IRDP = Internet control message protocol (ICMP) router discovery protocol 3. To support full system redundancy, it is necessary to connect the two external uplinks to separate routers as shown in.

Furthermore, the routers must be connected to separate networks with diverse routing paths to the applicable external NEs and services (such as OSS, DNS, media gateways, and announcement servers). Caution Ensure redundancy of power feeds to your system, so that a single point of failure does not cause a loss of traffic: For AC systems (Sun Fire V120), power Side A hosts from a separate power source than Side B. For DC systems (Netra 120), power each host from two separate (redundant) DC power feeds.

Step 2 Following the procedures and precautions in the Cisco Systems documentation, an authorized power installer should connect power and grounding cables to the two Cisco 2924M Ethernet switches. Warning This equipment must be grounded. Never defeat the ground conductor or operate the equipment in the absence of a suitably installed ground conductor. Contact the appropriate electrical inspection authority or an electrician if you are uncertain that suitable grounding is available. Statement 1024 Labeling the Ethernet Cables Two Ethernet cables are supplied with each host machine. Make sure that all of the Ethernet cables are correctly labeled before you begin. It is suggested that you label the cables according to the procedure in and in.

Connecting Ethernet Cables to EMS and CA Units Follow these steps to connect the Ethernet cables from the host machines (EMS and CA) to the Ethernet switches. Step 1 Obtain the 4 Ethernet cables needed for connections between EMS Sides A and B and the two Cisco 2924M Ethernet Switches A and B.

These cables are listed in in. Step 2 Connect these 4 Ethernet cables between the ports on the rear panel of the EMS units and the ports on the front of the Ethernet switches as specified in. Step 3 Obtain the 4 Ethernet cables needed for connections between CA Sides A and B and the two Cisco 2924M Ethernet Switches A and B. These cables are listed in.

Step 4 Connect these 4 Ethernet cables between the ports on the rear panel of the CA units and the ports on the front of the Ethernet switches as specified in. Step 5 After installing the Ethernet cables, record the necessary information on a copy of or similar document according to local procedures. Connect External Network Uplink Cables to Ethernet Switches External network uplink cables are customer supplied.

Follow these steps to connect uplink cables to the Ethernet switches. Note If your local network documentation calls for gigabit Ethernet, contact Cisco TAC for assistance. Step 1 If your local network documentation calls for 100 Mb Ethernet, connect the applicable network uplink cables to the Ethernet Switches as listed in.

Step 2 After installing the uplink cables, record the necessary information on a copy of or similar document according to local procedures. Connecting Serial Cables to Alarm Panel or Terminal Server Remote management of the Cisco BTS 10200 requires serial cables connected from the four host machines and two Ethernet Switches to a terminal server. If specified in your local work order, connect these serial cables using the steps in this section. Note that some commercially available alarm panels have built-in terminal server capability. Tip See the Sun Microsystems documentation for instructions on using the LOM features. Procedure for Use with Third-Party Terminal Server or Alarm Panel This procedure is applicable if your terminal server or alarm panel is not the Continuous Computing Intelligent Alarm Panel.

If you are using a Continuous Computing Intelligent Alarm Panel, see the. Step 1 Obtain the four serial cables that connect the lights-out management port (A LOM port) of the Sun Fire V120/Netra 120 host machines and an alarm panel or terminal server. If these cables have not been provided, see. Step 2 If necessary, make one serial cable for each SunFire V120/Netra 120 host machine. Follow the procedures in the Sun Microsystems documentation and the terminal server documentation. It is suggested that you label the cables according to the procedure in and in.

Step 3 Connect a serial cable between the A LOM port of each Sun Fire V120/Netra 120 host machine and the alarm panel or terminal server. Follow the procedures in the Sun Microsystems documentation and the terminal server documentation. Step 4 Obtain the two serial cables that connect the CONSOLE port of each Cisco 2924M Ethernet Switch to the alarm panel or terminal server. If these cables have not been provided, see.

Step 5 If necessary, make one serial cable for each Cisco 2924M Ethernet Switch. Follow the procedures in the Ethernet switch documentation and the terminal server documentation. It is suggested that you label the cables according to the procedure in and in. Step 6 Connect a serial cable between the CONSOLE port of each Cisco 2924M Ethernet Switch and the alarm panel or terminal server.

Follow the procedures in the Ethernet switch documentation and the terminal server documentation. Step 7 Record the necessary information on a copy of or similar document according to local procedures Procedure for Use with Continuous Computing Intelligent Alarm Panel This procedure is applicable if your terminal server or alarm panel is the Continuous Computing Intelligent Alarm Panel. If you are using a different terminal server or alarm panel, see the. The rear view of the Continuous Computing Intelligent Alarm Panel is shown in. (The drawing is not to scale.) Figure 2 Rear View of Continuous Computing Intelligent Alarm Panel.

Note The four LOM serial cables are specially designed for the connecting the LOM ports on the SunFire V120/Netra 120 to the SER ports on the Alarm Panel. Be sure to use the correct cables and connect them as labeled (LOM end and SER end must be connected as labeled).

Step 3 Obtain the two serial cables that connect the CONSOLE port of each Cisco 2924M Ethernet Switch to the Alarm Panel. These cables are listed in in. Step 4 Connect a serial cable between the CONSOLE port of each Cisco 2924M Ethernet Switch and the Alarm Panel serial ports as specified in. Note The two CONSOLE serial cables are specially designed for the connecting the CONSOLE ports on the Cisco 2924M Ethernet Switches to the SER ports on the Alarm Panel. Be sure to use the correct cables and connect them as labeled (SWITCH end and SER end must be connected as labeled).

Note that in some earlier installations, these cables were labeled 'SWITCH' and 'net CCN', where net CCN is treated the same as SER. Step 5 Record the necessary information on a copy of or similar document according to local procedures. Enable IRDP This section explains how to enable IRDP functionality on the Cisco BTS 10200 Softswitch and on the network router.

Create Txf File Quickbooks Online. Note This will ensure that reboot will enable the irdp daemon. Step 6 Put the following lines into the S68inet file: if [ -f /usr/sbin/in.routed ]; then mv -f /usr/sbin/in.routed /usr/sbin/in.routed.org Step 7 Repeat through for EMS Side B. Step 8 Repeat through for CA Side A. Step 9 Repeat through for CA Side B.

Enable IRDP on Adjacent Cisco Routers If you are enabling IRDP on Cisco routers adjacent to the Cisco BTS 10200 Softswitch, follow these steps. If you have any questions about setup of these routers, contact your system administrator. If you need additional assistance, contact Cisco TAC. Step 1 Verify that you have the Network Information Data Sheet (NIDS) applicable to this Cisco BTS 10200 Softswitch. If necessary, contact your network administrator to verify that you have the correct NIDS. Step 2 On default gateway interfaces for Network 1 and Network 2 (as defined in the NIDS) enable IRDP using the following commands: config t interface ip irdp ip irdp maxadvertinterval 4 ip irdp minadvertinterval 3 ip irdp holdtime 10 Step 3 Validate the configuration by performing the following command on both CA/FS hosts and both EMS hosts: login as root #netstat -rn Step 4 View the display and verify that each default route was populated dynamically by IRDP. Verify IRDP Functions Follow these steps to verify that IRDP is functioning properly on the network: CA Side A Perform through on CA Side A.

Step 1 Login to CA Side A as root. Step 2 Display the IRDP daemon status by entering the following command: ps -ef grep in.rdisc Step 3 View the display and verify that each default route was populated dynamically by IRDP. The display should include the following information: /usr/sbin/in.rdisc -s -f.

(This indicates that IRDP is running properly.) Step 4 Display the routing table by entering the following command: netstat -rn Step 5 Verify that the routing table shows two default routes, one on interface NET 0 and one on NET 1. Step 6 Unplug the interface NET 0 link at the back of CA Side A. Step 7 Display the routing table by entering the following command: netstat -rn Step 8 Verify that the route for interface NET 0 does not appear in the routing table.

Note When a link is unplugged or plugged back in, it may take 5 to 10 seconds for the IRDP function to automatically update. Step 9 Plug the interface NET 0 link back in to CA Side A.

Step 10 Display the routing table (netstat -rn) and verify that the route for interface NET 0 appears in the routing table again. Step 11 Repeat through for the interface NET 1 link.

CA Side B Repeat through for CA Side B. Verify Interfaces Follow these steps to verify that all interfaces are configured on all computing elements: Step 1 If the Cisco BTS 10200 Softswitch application software has already been installed on the system, go to. If the application has not been installed, go to. Step 2 (If the Cisco BTS 10200 Softswitch application software has already been installed on the system) check the interface configurations using the following command on each of the four platforms (two EMS units and two CA/FS units): Enter: checkCFG Step 3 The system should display the message Validating. If no errors are found during validation, the system will display the message No errors found. Verify that the No errors found message is displayed.

Note If the system does display an error, contact Cisco TAC for assistance. Step 4 If the Cisco BTS 10200 Softswitch application software has not been installed on the system, install the application using the Application Installation procedure provided by Cisco. That procedure contains the appropriate commands to check the configurations (checkCFG). Appendix A: Cable Labeling Cables are labeled at both ends with the cable numbers listed in and, as applicable.

Follow these steps to create and attach the labels. Note The steps in this section are not necessary for any cables that were provided with your system and have already been labeled.

Step 1 Make each label by copying the applicable number from (or ) onto the label. Be sure to duplicate the number several times onto the label, as shown in, to make it easier to read. (If desired, make the labels for all cables in one print run.) Step 2 On a work bench or assembly table, position a cable so that one connector is on your left and the cable goes off to the right. (See.) Step 3 Attach the appropriate label to the cable as shown in. Step 4 Turn the cable around so that the other connector is on your left with the cable going off to the right. Step 5 Repeat and for this side of the cable. The completed cable should look like the example shown in.

Step 6 Repeat these steps for all cables in the rack, using the numbers from the cable lists ( and as applicable). Figure 3 Labeling Specification. Obtaining Documentation Cisco provides several ways to obtain documentation, technical assistance, and other technical resources.

These sections explain how to obtain technical information from Cisco Systems. Cisco.com You can access the most current Cisco documentation on the World Wide Web at this URL: You can access the Cisco website at this URL: International Cisco web sites can be accessed from this URL: Documentation CD-ROM Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product.

The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

I was asked to revive an old Sun Fire V120 server and install Solaris 10 on it for some Oracle tests. The server is in a server room a couple kilometers away — I could indeed drive there, put the DVD in the drive and install it that way but I found me too lazy to lift my bottom. Instead I decided to give a Solaris Jumpstart installation a try. I never did it before so I started googling — most tutorials explained how to setup Jumpstart server on Solaris but I didn’t have another Solaris available in that subnet. Only some Linux boxes.

So I kept on googling, found some hints but not a complete tutorial on doing a Solaris Jumpstart installation from a Linux server. Following the break is my take on the How-To. Solaris Jumpstart overview Only a few articles describe how Jumpstart works under the hood. Here are my findings, all tested on an UltraSPARC based Sun Fire V120, Sun Fire V240 and Sun Fire T2000 servers: • Boot the Sun box into OpenBoot Prompt (aka ok prompt) and invoke a network boot with: boot net -v — install • rarp — The Sun box sends out a rarp request and expects to get its new an IP address in a reply. Jumpstart server runs rarpd for this task. • tftp — With IP assigned the Sun box tries to load a Solaris kernel over tftp from the server that replied to the RARP request. • bootparams — The kernel half-boots and sends out a bootparams request to find the NFS installation source.

• nfs mount & mdash; Then it tries to mount the NFS directories and invokes the installation program very similar to what you know from DVD-based installation. • Optionally you can supply a config file for a non-interactive installation.

If no config is available Jumpstart will run in an interactive mode. Required packages The machine I decided to use for this Jumpstart exercise runs OpenSUSE 11.2 — not really a server distro but good enough for the task. First of all install the required packages. In OpenSUSE use either YaST 2 or command-line tool zypper: [Linux] ~ # zypper install rarpd nfs-kernel-server You will also need rpc.bootparamd daemon.

I haven’t found an RPM built specifically for OpenSUSE however there is a CentOS 5 package bootparams where you can get this daemon. Install it with --force and it should run just fine. Alternatively compile it from (or local download) with a classic./configure && make && make install sequence. Whichever way you choose you should end up with rpc.bootpadamd installed in /usr/sbin or elsewhere. If your server is RedHat, Fedora or CentOS the situation is even easier because bootparams package is directly available: [Linux] ~ # yum install rarpd nfs-kernel-server bootparams The following procedure makes use of a lot of different ports.

Before moving on disable firewall on the Linux server either with rcSuSEfirewall2 stop on OpenSUSE or with service iptables stop on RedHat, Fedora or CentOS. Required information from the Sun box Before going on we’ll need some information from the Sun server, namely its MAC address.

It can be found on a sticker somewhere on the case, on the System Configuration Card and is also printed out during boot sequence ( ok boot net -v — install): Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 1024 MB memory installed, Serial #524012345. Ethernet address 0:3:ba:1f:ab:cd, Host ID: 831fabcd.

Also decide on the name for the server. In this example we’re going to call it simply sunfire and give it an IP address 192.168.140.205. That’s all we need for now.

Let’s configure the Linux server RARP configuration RARP, BOOTP and DHCP protocols all serve the same purpose — they assign an address-less host a new IP address. However unlike the latter ones RARP does that and only that, it provides only the IP address but not a network mask, a gateway address or any other information.

That has some interesting consequences as we’ll see in a while. However it’s the protocol used by SunFire OpenBoot environment. The mapping between Ethernet address and IP address is done in two files on the Linux host: /etc/ethers and /etc/hosts: [Linux] ~ # echo '0:3:ba:1f:ab:cd sunfire' >>/etc/ethers [Linux] ~ # echo '192.168.140.205 sunfire' >>/etc/hosts Now run the daemon in verbose mode and check the message log: [Linux] ~ # rarpd -v [Linux] ~ # tail -f /var/log/messages. Feb 19 13:08:12 linux rarpd[2383]: rarp who-is 0:3:ba:1f:ab:cd tell 0:3:ba:1f:ab:cd answer 192.168.140.205 Check out the Sun’s booting progress and you’ll see something like: Timeout waiting for ARP/RARP packet Timeout waiting for ARP/RARP packet (here rarpd was started on the Linux server) Retrying. Check TFTP server and network setup Retrying. Check TFTP server and network setup TFTP configuration The Sun server got its IP address and tries to download the kernel using TFTP protocol from the server that responded to the RARP request. The filename requested is C0A88CCD which stands for 192.168.140.205 converted to hex: [Linux] ~ # printf '%02X%02X%02X%02X ' 192 168 140 205 C0A88CCD The netboot kernel is called inetboot on the Solaris 10 DVD.

It must be copied to the TFTP directory ( /srv/tftp) and symlinked to the above hex- IP name. Then the TFTP daemon can finally be started. Let’s mount the DVD (or the ISO image in this case) to /data/jumpstart/sol10u8 on the Linux box for start: [Linux] ~ # mkdir -p /data/jumpstart/sol10u8 [Linux] ~ # mount -oro,loop /iso/sol-10-u8-ga-sparc-dvd.iso /data/jumpstart/sol10u8 There kernel is available in three versions: sun4u for the older UltraSPARC I to IV CPUs, sun4v for modern UltraSPART T1 and T2 processors and sun4us for idontknowwhat processors. Our Sun Fire V120 and V240 both need the sun4u variant while the newer Sun Fire T2000 needs sun4v. This example is about V120 so use the sun4u kernel.

[Linux] ~ # cd /srv/tftp [Linux] /srv/tftp # cp /data/iso/sol10u8/Solaris_10/Tools/Boot/platform/ sun4u/inetboot inetboot.sun4u [Linux] /srv/tftp # ln -s inetboot.sun4u C0A88CCD We’re ready to start up TFTP daemon ( /usr/sbin/in.tftpd): [Linux] ~ # /usr/sbin/in.tftpd -l -s -v -v /srv/tftp [Linux] ~ # tail -f /var/log/messages. Feb 19 13:22:52 linux in.tftpd[24576]: RRQ from 192.168.140.205 filename C0A88CCD Check out the Sun’s console again.

There should be something like: Retrying. Check TFTP server and network setup Retrying. Check TFTP server and network setup 3a000 Server IP address: 192.168.140.101 Client IP address: 192.168.140.205 Using Onboard Transceiver — Link Up. Using RARP/BOOTPARAMS. Internet address is: 192.168.140.205 [hangs here.] You may need to restart netboot on the Sun box if it doesn’t go on with TFTP by itself. BootParams configuration At this point the Solaris kernel keeps sending out broadcast packets requesting supplement boot parameters. Oh, wait, did I say “broadcast packets”?

How does it know the broadcast address if RARP wouldn’t supply the netmask?! Well the answer is it doesn’t know it. The broadcast address is derived from the IP address using the obsolete class A/B/C schema, therefore for 192.168.140.205 it’s going to use 192.168.140.255, which is correct in my LAN.

However if RARP gave it, say, IP 10.20.30.40 the kernel would use 10.255.255.255 as the broadcast, which is very likely incorrect. I don’t know if the Sun box can be told to use a different broadcast. I couldn’t find a way to do it and had to temporarily change network config of the Linux jumpstart server to 10.x.x.x/8 when I was in that situation. Now back to bootparams config. The config file is /etc/bootparams and looks like this: [Linux] ~ # cat /etc/bootparams sunfire root=linux:/sol10u8/Solaris_10/Tools/Boot install=linux:/sol10u8/ boottype=:in The root= and install= parameters are NFS paths to the mounted Solaris 10 DVD ISO image. Another catch!

Why does it say /sol10u8 instead of /data/jumpstart/sol10u8? That’s because Solaris tries NFSv4 mount first and as you may or may not be aware NFSv4 mounts all start from a specified directory and do not include the path from server’s root. For instance if we export /data/jumpstart as a NFSv4 root then linux:/ will mount /data/jumpstart/ over NFSv4. To mount the same directory over NFSv2 / NFSv3 we’d have to mount linux:/data/jumpstart but Solaris prefers NFSv4. The other option is to disable NFSv4 support entirely on the Linux server, for example in OpenSUSE set NFS4_SUPPORT='no' in /etc/sysconfig/nfs and restart the nfs server with service nfsserver restart.

In that case Solaris kernel will fall back to NFSv3 and /etc/bootparams will have full paths in there. We’ll leave NFSv4 enabled Let’s start the NFS server daemons and export the jumpstart directory: [Linux] ~ # service nfsserver start Starting kernel based NFS server: idmapd mountd statd nfsd sm-notify done [Linux] ~ # exportfs *:/data/jumpstart -o fsid=0,ro,no_root_squash,crossmnt,no_subtree_check,sync Here fsid=0 makes /data/jumpstart be the NFSv4 root and crossmnt enables the clients to see the ISO image mounted in sol10u8 subdirectory. See the manpage for exports(5) and exportfs(8) for more details. It may be a good idea to try if we can mount the path that is set in /etc/bootparams: [Linux] ~ # mount -t nfs4 linux:/sol10u8 /mnt [Linux] ~ # ls /mnt Solaris_10 boot installer platform. Almost there Reboot the Sparc server once again — either break into OpenBoot (“ok” prompt) with “break command” (Ctrl-A F in minicom or Stop-A from a Sun keyboard) or straight into LOM with “#.” (“lom>” or “sc>” prompt). In either case issue “reset” and then “boot net -v — install”. Netboot should now run smoothly right into the installation program: ok boot net -v — install Boot device: /pci@1f,0/pci@1,1/network@c,1 File and args: -v — install Using Onboard Transceiver — Link Up.

(rarpd resolving IP address) Timeout waiting for ARP/ RARP packet (tftpd serving the netboot kernel) 3a000 Server IP address: 192.168.140.101 Client IP address: 192.168.140.205 Using Onboard Transceiver — Link Up. Using RARP/ BOOTPARAMS.