Cisco Catalyst 4224 How to use

Corporate Headquarters:
Copyright © 2001. Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Release Notes for Cisco Catalyst 4224
Access Gateway Switch for
Cisco IOS Release 12.1(5)YE3
October 8, 2001
Note You can find the most current Cisco IOS documentation on Cisco.com. This set of electronic
documents may contain updates and modifications made after the hard-copy documents were printed.
These release notes for the Cisco Catalyst 4224 Access Gateway Switch describe the enhancements
provided in Cisco IOS Release 12.1(5)YE3. These release notes are updated as needed.
Contents
These release notes describe the following topics:
•Introduction, page 2
•System Requirements, page 2
•New and Changed Information, page 3
•Important Notes, page 5
•Caveats, page 12
•Related Documentation, page 13
•Obtaining Documentation, page 24
•Obtaining Technical Assistance, page 25

2
Introduction OL-1798-01
Introduction
Introduction
The Cisco Catalyst 4224 Access Gateway Switch is an Ethernet switching router that provides Voice
over IP (VoIP) gateway and IP telephony services. It is designed to be part of a centralized
Cisco CallManager application.
System Requirements
This section describes the system requirements for Cisco IOS Release 12.1(5)YE3 and includes the
following sections:
•Memory Recommendations, page 2
•Supported Hardware, page 2
•Determining the Software Version, page 2
Memory Recommendations
Supported Hardware
Cisco IOS Release 12.1(5)YE3 supports:
•Cisco Catalyst 4224 Access Gateway Switch
Determining the Software Version
To determine the version of Cisco IOS software running on your Cisco Catalyst 4224 Access Gateway
Switch, log in to the Cisco Catalyst 4224 Access Gateway Switch and enter the show version EXEC
command:
Router> show version
Cisco Internetwork Operating System Software
IOS (tm) 12.1(5) Software (c4224-isx3-mz), Version 12.1(5)YE3, RELEASE SOFTWARE
Table 1 Minimum Memory Recommendations for the Cisco Catalyst 4224 Access Gateway Switch
Platforms Image Name Software Image
Flash
Memory
Recommended
DRAM
Memory
Recommended Runs From
Cisco c4224 IP Plus (standard) c4224-isx3-mz 32 MB Flash 64 MB DRAM RAM
IP Plus / FW c4224-io3sx3-mz 32 MB Flash 64 MB DRAM RAM
IP Plus / IPsec 56 c4224-isx356i-mz 32 MB Flash 64 MB DRAM RAM
IP Plus / IPsec 56 / FW c4224-io3sx356i-mz 32 MB Flash 64 MB DRAM RAM
IP Plus / 3DES c4224-ik2sx3-mz 32 MB Flash 64 MB DRAM RAM
IP Plus / 3DES / FW c4224-ik2o3sx3-mz 32 MB Flash 64 MB DRAM RAM

3
New and Changed Information
OL-1798-01
New and Changed Information
New and Changed Information
The following sections list the new hardware and software features as well as bug fixes in Cisco IOS
Release 12.1(5)YE and subsequent releases.
New Hardware Features in Cisco IOS Release 12.1(5)YE
Cisco IOS Release 12.1(5)YE supports the Catalyst 4224 Access Gateway Switch.
New Software Features in Cisco IOS Release 12.1(5)YE1
Cisco IOS Release 12.1(5)YE1 supports Survivable Remote Site Telephony (SRST).
New Software Features in Cisco IOS Release 12.1(5)YE2
Cisco IOS Release 12.1(5)YE2 supports:
•CLI to disable 8 Port FXS Module voice ports
•Inline power for 24 phones of 7910/7940/7960 family
•Firewall feature set: NAT, Proxy, CBAC, and IDS
Bug Fixes
This section lists bugs that have been fixed or resolved in the various software releases for the
Catalyst 4224.
Bug Fixes in Cisco IOS Release 12.1(5)YE2
The following reported bugs have been fixed or resolved in Cisco IOS Release 12.1(5)YE2:
•CSCdu66264
New DSP (3.3.81) with echo canceller fix and FAX relay fix.
•CSCdu68219
Ports do not work after reloading the gateway.
•CSCdu89151
Loss of IP connectivity within the same VLAN of the Catalyst 4224.
The Catalyst 4224 connects multiple devices within the same VLAN. At some point, a device can
lose IP connectivity to other devices connected to the same switch; however, this same device retains
IP connectivity to the switch itself. Other devices connected directly to this switch lose IP
connectivity to the failed device, yet these other devices maintain IP connectivity with each other.
Remote devices maintain IP connectivity to all devices connected to the switch.

4
Bug Fixes OL-1798-01
New and Changed Information
•CSCdv01742
IP phones in fallback mode connected to the Catalyst 4224 are unable to transfer calls.
When IP phones are connected to the Catalyst 4224 and they are operating in fallback mode, these
phones lose the ability to transfer calls. If a user tries to transfer to an invalid directory number, the
transferring phone receives a reorder tone but is able to resume the original call. However, if the user
enters a valid directory number, both the calling phone and the transferring phone are disconnected.
•CSCdv02746
ISDN BRI on the Catalyst 4224 cannot receive calls on the second B-channel.
This problem occurs in a Catalyst 4224 with an ISDN BRI interface module. The first B-channel of
the BRI interface module can receive calls, but the second B-channel cannot. When a call is sent to
the second B-channel number, the router sees two ISDN SETUP messages approximately 3 seconds
apart. For the first SETUP message, the router does not answer. For the second SETUP message, the
router responds with a DISCONNECT with Cause i = 0x80A2 (No circuit/channel available). All
the ISDN SETUP messages for both calls contain the channel id = 0x89.
At this point, if someone tries to call the first B-channel number again, the call will not work. You
have to perform a shut/no shut to the BRI interface before the first B-channel can receive calls
again. In addition, you will have to wait for some time before you can call the router. If you call the
first B-channel right after Layer 2 is up, the router will respond with a DISCONNECT message with
Cause i = 0x80AF (Quality of service unavailable). This error occurs because the VTSP still shows
that the router is in the S_CONNECT state. Only after a while does the router go back to a normal
state, and call can be place to the first B-channel again. This behavior is cyclical.
From the show and debug commands, it appears that the router did not release the CCB for the first
call to the first B-channel. The sh isdn status command shows that there are no Layer 3 calls active,
but there is still a CCB present for the VOICE. This occurs only after a call is placed to the second
B-channel of the BRI interface.
•CSCdv08920
FXO supervisor disconnect fails on incoming calls.
Incoming calls to the FXO port may ring a device such as an IP phone connected to the
Catalyst 4224. If the caller goes back on-hook within a few seconds, the called phone continues to
ring. The remote on-hook is apparently not being detected.
•CSCdv12080
IP phones are not getting powered up.
Bug Fixes in Cisco IOS Release 12.1(5)YE3
The following reported bugs have been fixed or resolved in Cisco IOS Release 12.1(5)YE3:
•CSCds63736
ATM interface crash due to CSCdr56182.
Fixed the interface null reference that caused the router to crash at boot time.
•CSCdu64055
ipx help not available.
Fixed CLI help function so that help text now displays for the ipx command.

5
Limitations and Restrictions
OL-1798-01
Limitations and Restrictions
•CSCdv28941
The ibd feature set is bundled with snasw; they need to be separated.
The ibd feature set is now available as a separate image or bundled with snasw.
•CSCdv45074
Serial TXCLK on SCC2 not programmed correctly.
The serial transmit clock was reprogrammed to produce the proper output signal.
Limitations and Restrictions
The following MIBs are supported:
•SNMP MIB-II
•ENTITY-MIB
•IF-MIB
•BRIDGE-MIB
The following Cisco proprietary MIBs are supported:
•CISCO-PROCESS-MIB
•CISCO-MEMORY-POOL-MIB
•CISCO-CDP-MIB
The following MIB will be supported later:
•CISCO-STACK-MIB
Important Notes
The following sections contain important notes about Cisco IOS Release 12.1(5)YE3 that can apply to
the Cisco Catalyst 4224 Access Gateway Switch.
Hardware Change in Catalyst 4224
Cisco IOS Release 12.1(5)YE3 is being shipped in conjunction with a hardware Engineering Change
Order (ECO) for the Catalyst 4224 platform. Cisco IOS Release 12.1(5)YE3 is backward compatible
with previous non-ECO hardware versions of the Catalyst 4224.
Note Cisco recommends that you do not run software releases prior Cisco IOS Release 12.1(5)YE3 on the
ECO hardware because serial WICs running in slot 1 might not operate correctly.
You can recognize ECO hardware by running the cookie command from ROMMON and looking at the
hardware revision level. All boards with a revision level of 1.3 (Major 01/Minor 03) or greater are ECO
hardware.

6
Tighten Screws on VICs and WICs OL-1798-01
Important Notes
Tighten Screws on VICs and WICs
You must tighten the screws when installing the interface cards in the Catalyst 4224 Access Gateway
Switch. If you do not tighten the screws properly, the VIC or WIC can malfunction.
TDM Clocking
The TDM clock reference on the Catalyst 4224 Access Gateway Switch can be derived from one of seven
sources. Each VIC slot that contains an E1/T1 card has five free running on-board clock sources and two
recovered clock sources.
The default reference is the on-board clock. You can use the frame-clock-select command to select one
of the E1/T1 ports as the primary reference. You can also use this command to select up to three
prioritized backups if the primary clock fails. Switching over to a backup source is non-revertive. The
system does not switch back to a higher priority clock if it recovers after a failure.
The frame-clock-select command has the following syntax:
[no] frame-clock-select priority E1/T1 slot/port
The clock source with priority one is the primary reference and the clock with priority four is the lowest
priority backup.
The clock reference selection that uses the frame-clock-select command is independent from the clock
selection between lines or internal on an E1/T1 controller. Framing and CRC errors due to clock slips
can be observed on E1/T1 interfaces if the on-board clock is used as the reference.
Need to Support 56 Kbps Operation for Slot 3 WIC
The 8260 Rev1A device in the Catalyst 4224 Access Gateway Switch has a defect that can cause data
corruption when configuring the MCC SI Ram for 2 entries (7 bits forming the 56-kbps channel and 1
bit being discarded).
As a workaround, 3 SI RAM entries would have to be used, but the Catalyst 4224 Access Gateway
Switch does not have enough available space. Therefore, only 64-kbps channels are supported.
If absolutely required, you could implement this feature in slots 1 and 2 using the SCCs and limit it to
two channels or super-channels per slot. This feature requires more design work and will not be
addressed unless really needed.
Customers that need 56 kbps should use the WIC-56K4 WIC.
Survivable Remote Site Telephony Marks Control Packets Differently
The Survivable Remote Site Telephony software feature marks the control traffic as a 10100000 or dscp
of cs5. Non-Survivable Remote Site Telephony IOS software marks it as 01101000.

7
MTP Not Used on Cisco CallManager Unless Transcoding is Required
OL-1798-01
Important Notes
MTP Not Used on Cisco CallManager Unless Transcoding is Required
All H.323 gateways that use IOS 12.0(7) or later support H.323 Version 2. Prior to H.323 Version 2, MTP
was required for H.323 gateways. Ordinarily, the MTP box on Cisco CallManager should not be checked
when defining the Catalyst 4224 as an H.323 gateway. You should check the MTP box on
Cisco CallManager only if transcoding is required at the central site. For example, transcoding would be
required when the Catalyst 4224 uses G.729 for IP WAN calls and the voice mail system at central site
only supports G.711.
With the MTP box checked on Cisco CallManager for the H.323 gateway definition for Catalyst 4224,
a locally connected analog FXS phone call to a local IP phone must traverse the IP WAN because the
call between the analog FXS phone and the IP phone is anchored by the transcoding device at the central
site. This behavior is normal for an IOS H.323 gateway when the MTP box on Cisco CallManager is
checked, but this behavior is obviously not optimal. Therefore, unless transcoding is required, the MTP
box should not be checked on the H.323 gateway definition for Catalyst 4224.
Connecting the Catalyst 4224 as a Gateway Over a Low Speed Serial Link
Use the h323-gateway voip bind srcaddr command to connect the Catalyst 4224 as a gateway over a
low speed serial link.
To configure the Catalyst 4224 as an H.323 gateway, use the following configuration:
interface Loopback1
description h323 gateway address
ip address 10.253.1.1 255.255.255.0
h323-gateway voip bind srcaddr 10.253.1.1
This configuration provides the IP address for the H.323 end point. Use the same address in
Cisco CallManager to configure the H.323 gateway. This address can be attached to a physical interface.
Portfast Command Not Supported for Trunks
If the Catalyst 422410/100 Ethernet ports are configured in trunk mode, the portfast command is not
supported. The workaround is to use the global configuration commands for each VLAN to reduce the
forwarding timers to a minimum value of 4 seconds.
spanning-tree portfast bpduguard
spanning-tree vlan 60 forward-time 4
spanning-tree vlan 160 forward-time 4
Warning If you connect the Catalyst 4224 to another switch, ensure that the timers are the same
on both links. Otherwise, you might experience spanning tree issues.

8
Use the Portfast Command with a Separate VLAN for Voice and Data OL-1798-01
Important Notes
Use the Portfast Command with a Separate VLAN for Voice and Data
To use the portfast command, configure the Catalyst 4224 ports with an access VLAN for data and a
separate VLAN for voice. The following configuration provides an example:
interface FastEthernet5/22
no ip address
duplex auto
speed auto
switchport access vlan 60
switchport voice vlan 160
snmp trap link-status
spanning-tree portfast
Note Trunking should be used only to connect to another switch.
Configuring a Single PVC on Frame Relay with CBWFQ
To configure a single PVC on Frame Relay with CBWFQ until LLQ becomes available, see the following
notes.
Note LLQ is currently disabled.
The Catalyst 4224 currently supports LLQ/CBWFQ only on a PPP or HDLC encapsulated serial link.
The Catalyst 4224 supports LFI on MLPPP links but not LLQ/CBWFQ or ip rtp priority.
LLQ/CBWFQ are not currently supported for Frame Relay. The Service Policy output command is
currently disabled. Therefore, currently only ip rtp priority is supported as a voice priority queuing
scheme. FRF.12 is also supported on Frame Relay links.
The following configuration example is recommended for FRF.12 and ip priority.
Define the map class:
map-class frame-relay VOIP_256
no frame-relay adaptive-shaping
frame-relay cir 250000
frame-relay bc 1000
frame-relay be 0
frame-relay mincir 250000
frame-relay fair-queue
frame-relay fragment 320
frame-relay ip rtp priority 16384 16383 170
Apply the map class to a frame-relay sub interface:
interface Serial0/0.300 point-to-point
ip address 1.1.1.1
frame-relay interface-dlci 300
frame-relay class VOIP_256
Apply frame-relay shaping to the main interface:
interface ser0/0
encapsulation frame-relay
frame-relay traffic-shaping

9
IGMP Snooping Support
OL-1798-01
Important Notes
IGMP Snooping Support
One or more users might need to connect to local/remote server(s) via IP WAN or other LAN connection
to access a MULTICAST application, such as IPTV or WEBCast. The Catalyst 4224 should send the
multicast stream only to the requesting user PC and should not flood the rest of user PCs with such
streams.
IGMP is a multicast protocol that directly affects PCs (hosts). IGMP allows hosts to inform Layer 3
devices (routers) that they want to receive multicast traffic for a specific multicast group address.
Multicast Address Range
The multicast address range includes any IP address in the range 224.0.0.0 to 239.255.255.255. The
range of addresses between 224.0.0.0 and 224.0.0.255 (inclusive) is RESERVED for the use of routing
protocols and other low-level topology discovery or maintenance protocols.
Any multicast server defined in the network will be part of one or more multicast groups.
Whenever a user’s PC (referred to as host) requests the services of a multicast server, for example, it asks
for an application (such as a movie channel), and it will send a message to join the particular group
(join-group) the server uses to multicast (transmit) such movie.
The Catalyst 4224 will send the movie stream only to the hosts that have sent a join request. The
Catalyst 4224 keeps track of the multicast entries via two tables known as Multicast address count and
IGMP snooping count. As in any system, these tables are finite, and specifically in the Catalyst 4224
their max valueis 255. Once this value is reached, further joins (join-group) or VLAN definitions cannot
be executed.
Other IGMP Requirements
In order to enable IGMP within the Catalyst 4224, a multicast protocol such as PIM must be configured
for the corresponding interface(s), which are mainly VLAN interfaces. The user cannot enable IGMP
directly as it is done in other Cisco switches.
TIPS on how to keep track of the multicast tables to prevent them from getting full (based on test
observations),
•For every VLAN added to the system, the multicast address count will increase by 4. (IGMP
snooping address Count does not get impacted by VLAN addition.)
•Whenever a multicast protocol is added (for example, ip pim dense-mode) both counters increase
by 3. (The first instance will increase counters by 4 because Multicast group 224.0.1.40 is added
too.)
•You can add up to 62 VLANs without IGMP support. Any additional VLAN will get added, but cdp
and EIGRP for these VLANs will not work (among other things).
•When a multicast group is added via the join-group command, both counters are increased by 1.
•When you delete a VLAN interface that was multicasting (for example, pim) no counters get
decreased. (A bug report exists for this issue.)
•When you delete a multicast protocol (for example, no ip pim value) from an interface, the counters
get increased by 1.
•When a multicast group leaves (via the no ip igmp join-group ip-address), both counters get properly
decremented by 1. This is the case when a host finishes using the multicast application, like viewing
a movie.

10
IP Phones Running SRST Fail to Get DHCP Reply OL-1798-01
Important Notes
Design
The Catalyst 4224 hardware is designed to support many IGMP groups and VLAN interfaces, as long as
the multicast address count is <= 255 and/or IGMP snooping address count is <= 255.
Note When the table limit is exceeded, no friendly message is displayed.
IP Phones Running SRST Fail to Get DHCP Reply
This section explains what happens when the lease time expires for IP phones running Survivable
Remote Site Telephony (SRST) that are assigned by the DHCP server in a central site.
IP Phones will try to renew the lease, but they will fail to get any DHCP replies due to the WAN failure.
Eventually IP phones will not only lose IP addresses but also lose phone services. Resetting or power
cycling the phones will not clear this situation. IP address and phone services cannot be restored until a
valid DHCP response is received by the IP Phone or the phone's IP address is manually configured
(DHCP is disabled).
When the IP address leased from the DHCP server is not infinite, the DHCP client will start sending
DHCP renew messages to extend the lease before the lease expires. When the lease time expires, IP
phones will start sending DHCP request messages and go to DHCP init state after a certain amount of
time without receiving DHCP replies from the server (this time is configurable). In the case when IP
phones already register with the SRST router in Cisco CallManager fall back mode, renewing the IP
address request will not be replied unless the SRST router itself is a DHCP server or there is a DHCP
server that can be reached. IP phones will lose their IP addresses assigned by the DHCP server in the
central site due to WAN failure, and hence lose the phone services, which cannot be recovered until a
valid DHCP response is received by the IP phone or the phone's IP address is manually configured, thus
disabling the DHCP service.
Note that loosing the lease is not the same as resetting. If the phone resets, it comes up in the
INIT-REBOOT state; this is the state where it has an IP address stored in flash. If it cannot contact the
DHCP server, it will use its stored address and continue to do DHCP Discovers in the background until
the server responds. In the case were the lease expires, the phone clears the IP address stored in flash
and goes to the INIT state. It cannot reinitialize until it gets a response from the DHCP server. This
behavior is as specified in the DHCP protocol RFC 2131.