DOM Digital Optical Monitoring

 

The DOM is only applied on new SFP (SFP-GE-S/L) and not on old SFP(GLC-SX-MM/GLC-LH-SM). Below are the description of DOM found from wiki.

Digital diagnostics monitoring

Modern optical SFP transceivers support digital diagnostics monitoring (DDM) functions according to the industry-standard SFF-8472. This feature is also known as digital optical monitoring (DOM). This feature gives the end user the ability to monitor real-time parameters of the SFP, such as optical output power, optical input power, temperature, laser bias current, and transceiver supply voltage.

Understanding Layer 2 Trunk Failover

Layer 2 trunk failover, also known as link-state tracking, is a feature that provides Layer 2 redundancy in the network when used with server NIC adapter teaming. When the server network adapters are configured in a primary or secondary relationship known as teaming, if the link is lost on the primary interface, connectivity is transparently switched to the secondary interface.

When you enable Layer 2 trunk failover on the switch, the link state of the internal downstream ports are bound to the link state of one or more of the external upstream ports. An internal downstream port is an interface that is connected to the server. An external upstream port is an interface that is connected to the external network. When you associate a set of downstream ports to a set of upstream ports, if all of the upstream ports become unavailable, trunk failover automatically puts all of the associated downstream ports in an error-disabled state. This causes the server primary interface to failover to the secondary interface.

When Layer 2 trunk failover is not enabled, if the upstream interfaces lose connectivity, (the external switch or router goes down, the cables are disconnected, or link is lost), the link state of the downstream interfaces remain unchanged. The server is not aware that external connectivity has been lost and does not failover to the secondary interface.

An interface can be an aggregation of ports (an EtherChannel), or a single physical port in access or trunk mode. Each downstream interface can be associated with one or more upstream interfaces. Upstream interfaces can be bundled together, and each downstream interface can be associated with a single group consisting of multiple upstream interfaces. These groups are referred to as link-state groups.

In a link-state group, the link states of the downstream interfaces are dependent on the link states of the upstream interfaces. If all of the upstream interfaces in a link-state group are in the link-down state, the associated downstream interfaces are forced into the link-down state. If any one of the upstream interfaces in the link-state group is in a link-up state, the associated downstream interfaces can change to or remain in the link-up state.

Figure 28-4 Typical Layer 2 Trunk Failover Configuration

In Figure 28-4, downstream interfaces 1, 3, and 5 are defined in link-state group 1 with upstream interfaces 19 and 20. Similarly, downstream interfaces 2, 4, and 6 are defined in link-state group 2 with upstream interfaces 21 and 22.

If link is lost on upstream interface 19, the link states of downstream interfaces 1, 3, and 5 do not change. If upstream interface 20 also loses link, downstream interfaces 1, 3 and 5 go into a link-down state. Downstream interfaces 2, 4, and 6 do not change states.

You can recover a downstream interface link-down condition by removing the failed downstream port from the link-state group. To recover multiple downstream interfaces, disable the link-state group.

Configuring Layer 2 Trunk Failover

These sections describe how to configure trunk failover ports:

•Default Layer 2 Trunk Failover Configuration

•Layer 2 Trunk Failover Configuration Guidelines

•Configuring Layer 2 Trunk Failover

Default Layer 2 Trunk Failover Configuration

There are no link-state groups defined, and trunk failover is not enabled for any group.

Layer 2 Trunk Failover Configuration Guidelines

Follow these guidelines to avoid configuration problems:

•Do not configure a cross-connect interface (gi0/23 or gi0/24) as a member of a link-state
group.

•Do not configure an EtherChannel as a downstream interface.

•Only interfaces gi0/1 through gi0/16 can be configured as downstream ports in a specific link-state group.

•Only interfaces gi0/17 through gi0/24 can be configured as upstream ports in a specific link-state group.

•An interface that is defined as an upstream interface cannot also be defined as a downstream interface in the same or a different link-state group. The reverse is also true.

•An interface cannot be a member of more than one link-state group.

•You can configure only two link-state groups per switch.

Configuring Layer 2 Trunk Failover

Beginning in privileged EXEC mode, follow these steps to configure a link-state group and to assign an interface to a group:

This example shows how to create a link-state group and configure the interfaces:

Switch# configure terminal 

Switch(config)# link state track 1

Switch(config)# interface range gigabitethernet0/21 - 22

Switch(config-if)# link state group 1 upstream

Switch(config-if)# interface gigabitethernet0/1 

Switch(config-if)# link state group 1 downstream

Switch(config-if)# interface gigabitethernet0/3 

Switch(config-if)# link state group 1 downstream

Switch(config-if)# interface gigabitethernet0/5 

Switch(config-if)# link state group 1 downstream

Switch(config-if)# end

---

Note If the interfaces are part of an EtherChannel, you must specify the port channel name as part of the link-state group, not the individual port members.

---

This example shows how to create a link-state group using ports in an EtherChannel:

Switch# configure terminal 

Switch(config)# link state track 1

Switch(config)# interface P01

Switch(config-if)# link state group 1 upstream

Switch(config-if-range)# interface range gigabitethernet0/1, gigabitethernet0/3, 
gigabitethernet0/5

Switch(config-if)# link state group 1 downstream

Switch(config-if)# end

To disable a link-state group, use the no link state track number global configuration command.

Displaying Layer 2 Trunk Failover Status

Use the show link state group command to display the link-state group information. Enter this command without keywords to display information about all link-state groups. Enter the group number to display information specific to the group. Enter the detail keyword to display detailed information about the group.

This is an example of output from the show link state group 1 command:

Switch> show link state group 1

Link State Group: 1      Status: Enabled, Up

This is an example of output from the show link state group detail command:

Switch> show link state group detail

Link State Group: 1      Status: Enabled, Up

Upstream Interfaces   : Po1(Up)

Downstream Interfaces : Gi0/3(Up) Gi0/4(Up)

Link State Group: 2      Status: Disabled, Down

Upstream Interfaces   :

Downstream Interfaces :

(Up):Interface up   (Dwn):Interface Down   (Dis):Interface disabled

 

這個功能可以用在 loop-free 的 topology 來避免因為 access-layer lost up-link 時所造成的 traffic black-holing。

Reference:

http://www.cisco.com/en/US/docs/switches/blades/3020/software/release/12.2_25_sef1/configuration/guide/swethchl.html#wp1346176

Erlang Description

Erlang - a unit of traffic

An Erlang is a unit of telecommunications traffic measurement.  Strictly speaking, an Erlang represents the continuous use of one voice path.  In practice, it is used to describe the total traffic volume of one hour.

For example, if a group of user made 30 calls in one hour, and each call had an average call duration of 5 minutes, then the number of Erlangs this represents is worked out as follows:

Minutes of traffic in the hour=number of calls x duration

Minutes of traffic in the hour=30 x 5

Minutes of traffic in the hour=150

Hours of traffic in the hour=150 / 60

Hours of traffic in the hour=2.5

Traffic figure=2.5 Erlangs

Erlang traffic measurements are made in order to help telecommunications network designers understand traffic patterns within their voice networks.  This is essential if they are to successfully design their network topology and establish the necessary trunk group sizes.

Erlang traffic measurements or estimates can be used to work out how many lines are required between a telephone system and a central office (PSTN exchange lines), or between multiple network locations.

Erlang traffic models

Several traffic models exist which share their name with the Erlang unit of traffic.  They are formulae which can be used to estimate the number of lines required in a network, or to a central office (PSTN exchange lines).  A formula also exists to model queuing situations, and lends itself well to estimating the agent staffing requirements of call centers.

The main Erlang traffic model are listed below, with links to the free online calculators on this Web site:

• Erlang B
  This is the most commonly used traffic model, and is used to work out how many lines are required if the traffic figure (in Erlangs) during the busiest hour is known.   The model assumes that all blocked calls are immediately cleared.
• Extended Erlang B
  This model is similar to Erlang B, but takes into account that a percentage of calls are immediately represented to the system if they encounter blocking (a busy signal).  The retry percentage can be specified.
• Erlang C
  This model assumes that all blocked calls stay in the system until they can be handled.  This model can be applied to the design of call center staffing arrangements where, if calls cannot be immediately answered, they enter a queue.

Further reading

To investigate the traffic unit Erlang, and the Erlang traffic models, we suggest the following sources of information on this Web site:

1. Free online Erlang traffic Calculators
   These online calculators allow you to perform Erlang traffic calculations now.  The Call Minutes Calculator does not even require an understanding of the Erlang traffic unit, and allows entries in minutes rather than Erlangs.  Detailed information is available in the Help area (press the Help button).
2. Dimensioning Trunk Groups
   This white paper discusses a method of optimising the number of lines in a trunk group based on the traffic carried by that trunk group. This is known as dimensioning a trunk group, and uses the Erlang B traffic model.
3. Call Centre Design
   This white paper describes the steps involved in assessing the staffing requirements of a call centre and estimating the number of trunks (central office lines) required to serve a call centre for incoming calls.  The suggested method uses both Erlang B and Erlang C.

A.K. Erlang - a tribute

Agner Krarup Erlang was born in 1878 in Lønborg, Denmark.   He was a pioneer in the study of telecommunications traffic and, through his studies, proposed a formula to calculate the fraction of callers served by a village exchange who would have to wait when attempting to place a call to someone outside the village.

In 1909, he published his first work: The Theory of Probabilities and Telephone Conversations.  He gained worldwide recognition for his work, and his formula was accepted for use by the General Post Office in the UK.

Erlang never married.  He worked for the Copenhagen Telephone Company for twenty years, until his death in 1929.  During the 1940s, the Erlang became the accepted unit of telecommunication traffic measurement, and his formula is still used today in the design of modern telecommunications networks.

Reference:

http://www.erlang.com/whatis.html

CUCM deployment and DNS

Network Services
The deployment of an IP Communications system requires the coordinated design of a well structured,
highly available, and resilient network infrastructure as well as an integrated set of network services
including Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Trivial File
Transfer Protocol (TFTP), and Network Time Protocol (NTP).

Domain Name System (DNS)
DNS enables the mapping of host names and network services to IP addresses within a network or
networks. DNS server(s) deployed within a network provide a database that maps network services to
hostnames and, in turn, hostnames to IP addresses. Devices on the network can query the DNS server
and receive IP addresses for other devices in the network, thereby facilitating communication between
network devices.
Complete reliance on a single network service such as DNS can introduce an element of risk when a
critical Unified Communications system is deployed. If the DNS server becomes unavailable and a
network device is relying on that server to provide a hostname-to-IP-address mapping, communication can and will fail. For this reason, in networks requiring high availability, Cisco recommends that you do
not rely on DNS name resolution for any communications between Unified CM and the Unified
Communications endpoints.

For standard deployments, Cisco recommends that you configure Unified CM(s), gateways, and
endpoint devices to use IP addresses rather than hostnames. For endpoint devices, Cisco does not
recommend configuration of DNS parameters such as DNS server addresses, hostnames, and domain
names. During the initial installation of the publisher node in a Unified CM cluster, the publisher will
be referenced in the server table by the hostname you provided for the system. Before installation and
configuration of any subsequent subscribers or the definition of any endpoints, you should change this
server entry to the IP address of the publisher rather than the hostname. Each subscriber added to the
cluster should be defined in this same server table via IP address and not by hostname. Each subscriber
should be added to this server table one device at a time, and there should be no definitions for
non-existent subscribers at any time other than for the new subscriber being installed.
During installation of the publisher and subscriber, Cisco recommend that you do not select the option
to enable DNS unless DNS is specifically required for system management purposes. If DNS is enabled,
Cisco still highly recommend that you do not use DNS names in the configuration of the IP
Communications endpoints, gateways, and Unified CM servers. Even if DNS is enabled on the servers
in the cluster, it is never used for any intra-cluster server-to-server communications and is used only for
communications to devices external to the cluster itself.
Cisco Unified CM 5.0 and later releases do not permit the manual configuration of HOSTS or LHOSTS
files. A local version of the HOSTS table is automatically built by the publisher in each cluster and
distributed to all subscriber nodes via a secure communications channel. This local table is used for
managing secure intra-cluster communications and does not contain addresses or names of any endpoints
other than the Unified CM servers themselves. LMHOSTS files do not exist and are not used by Cisco
Unified CM 5.0 and later releases.

Deploying Unified CM with DNS
There are some situations in which configuring and using DNS might be unavoidable. For example, if
Network Address Translation (NAT) is required for communications between the IP phones and
Unified CM in the IP Communications network, DNS is required to ensure proper mapping of NAT
translated addresses to network host devices. Likewise, some IP telephony disaster recovery network
configurations rely on DNS to ensure proper failover of the network during failure scenarios by mapping
hostnames to secondary backup site IP addresses.
If either of these two situations exists and DNS must be configured, you must deploy DNS servers in a
geographically redundant fashion so that a single DNS server failure will not prevent network
communications between IP telephony devices. By providing DNS server redundancy in the event of a
single DNS server failure, you ensure that devices relying on DNS to communicate on the network can
still receive hostname-to-IP-address mappings from a backup or secondary DNS server.
Hostname resolution within the cluster via either the local HOSTS file or DNS queries is performed only
at subsystem initialization (that is, when a server is booted up). As a result, in order for a server within
the cluster to resolve a DNS name that has been changed in either the HOSTS file or the DNS server,
the Cisco CallManager Service must be restarted on all servers within the cluster.

Reference:

CUCM7 SRND

What is Greenfield deployment?

 

-Greenfield deployment

Enterprise Voice provides new businesses or even new office sites for existing businesses with the opportunity to implement a full-featured VoIP solution without having to worry about PBX integration or incurring the substantial deployment and maintenance costs of an IP PBX infrastructure. This solution supports both onsite and remote workers.

In this scenario, all calls are routed over the IP network. Calls to the PSTN are routed to the appropriate media gateway. Communicator serves as a softphone. RCC is unavailable in this scenario because Communicator Phone Edition, like Communicator, provides click-to-call capability. Voice mail and auto-attendant services are available through the optional deployment of Exchange Unified Messaging.

Note:

In addition to the network infrastructure that is required to support Communications Server 2007, a greenfield deployment might require a small PBX to support fax machines and analog or ISDN devices. In certain scenarios, this might require a new PRI (Primary Rate Interface) link with a new set of numbers.

The following figure shows a typical topology for a greenfield deployment.

Figure 14. Greenfield deployment option

 

Deployment Scenarios

The Cisco Unified Communications system can help you take full advantage of your existing IP network to deliver new communications services. Whether implemented individually or in combination, the products help you reap the highest possible productivity and cost-savings benefits and achieve a fast, measurable ROI in a variety of deployment scenarios, including:

• Greenfield : A new telephone system is installed to serve a new or relocating facility
• Centrex Replacement: The recurring costs of an outsourced service are replaced by an internally owned telephone system
• Multisite Centralized Call Processing: Replacin g separate systems within a company or region with centralized call processing presents significant potential for reducing costs, consolidating redundant infrastructure, and standardizing network services
• Single-site PBX and ACD Replacement: The need to replace aging or obsolete voice infrastructure often begins the migration to IPC
• IP Telephony: Cisco products can integrate with existing PBX and key systems to help you migrate gradually to IP telephony while protecting current technology investment

 

Reference:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns165/net_business_benefit0900aecd80472efb.html

http://technet.microsoft.com/en-us/library/bb803630.aspx