Search this Blog

Thursday, February 27, 2014

Switch: How to test a cable status?

How do we check the cable status using TDR and steps involved to run the test?

Works on 29xx, 37xx, 45xx & 65xx series model switches

Checking the Cable Status Using the TDR


You can check the status of copper cables using the time domain reflectometer (TDR). The TDR detects a cable fault by sending a signal through the cable and reading the signal that is reflected back to it. All or part of the signal can be reflected back by any number of cable defects or by the end of the cable itself.


Use the TDR to determine if the cabling is at fault if you cannot establish a link. This test is especially important when replacing an existing router, upgrading to Gigabit Ethernet, or installing new cables.


The port must be up before running the TDR test. If the port is down, you cannot enter the test cable-diagnostics tdr command successfully, and the following message is displayed:

router#test cable-diagnos tdr int gig0/1

% Interface Gi0/1 is administratively down
% Use 'no shutdown' to enable interface before TDR test start.

Note: TDR can test cables up to a maximum length of 115 meters.

How to run the test?


router # test cable-diagnos tdr int gig0/1

TDR test started on interface Gi0/1
A TDR test can take a few seconds to run on an interface


To Check the Result:

'show cable-diagnostics tdr int gig0/1' will provide the TDR results.

A Sample Run Result:

switch#sh ip int bri | i up
GigabitEthernet0/1     unassigned      YES unset  up                    up     
switch#

switch#test cable-diagnostics tdr interface gigabitEthernet 0/1
TDR test started on interface Gi0/1
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
switch#
*Mar  1 01:59:05.231: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
*Mar  1 01:59:06.238: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
*Mar  1 01:59:12.772: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
*Mar  1 01:59:13.779: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
switch#

Output:

switch#show cable-diagnostics tdr interface gigabitEthernet 0/1
TDR test last run on: March 01 01:59:04

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/1     1000M Pair A     8    +/- 10 meters Pair B      Normal             
                        Pair B     8    +/- 10 meters Pair A      Normal             
                        Pair C     8    +/- 10 meters Pair D      Normal             
                        Pair D     8    +/- 10 meters Pair C      Normal             
switch#


Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

What are the methods to boot and run IOS XE software?


How do we run IOS XE Software in 3850 switch/stack?

There are 2 methods of booting and running IOS XE software in 3850 switch/stack.

By default, the switches are shipped in Install mode.



Bundle mode: Bundle mode is where we boot the switch/stack using the .bin file. This is the traditional method of booting the switch where the switch extracts the .bin file to the RAM of the switch and run from there.

Install Mode: Install mode is where we pre-extract the .bin file in the flash and boot the witch/stack using the packages.conf file created during the extraction.

Note:

Install mode is the recommended mode of running the switch. Not all features may be available in this Bundle mode





IOS XE installation and software rollback are supported only when the switch is running in “Install” mode. (ie: The commands “software install” and “software rollback”.)

Use “software expand” command to convert the switch into Install mode from Bundle mode. The steps are mentioned below.

Upgrading a stand-alone switch:

The packages and provisioning file used to boot in installed mode must reside in the flash.

Booting in installed mode from usbflash0: or TFTP is not supported.

Booting a bundle in bundle mode is just like booting a monolithic IOS image.

For example: boot flash:cat3k_caa-universalk9.SSA.03.08.83.EMD.150-8.83.EMD.bin

Hence, the boot variable should not be pointing to the .bin file. If so, the switch will boot in Bundle mode. The boot variable should be pointing to the “packages.conf” file in order for the switch to boot in Install mode.

Before doing the upgrade, we need to check the mode in which the switch is currently booted in.

C3850#show version | begin Switch Port

Switch Ports Model              SW Version        SW Image              Mode

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

*    1 32    WS-C3850-24T       03.03.01SE        cat3k_caa-universalk9 INSTALL •ß Install mode

Upgrading from Install mode:

By default, switches are shipped in Install mode.

In order to upgrade the switch from Install mode, please follow the below-mentioned procedure.

  • •1.       Download the new image from the TFTP server to the flash / USB on the switch. (optional)

Copy tftp: flash:

   (or)

Copy tftp: usbflash0:

  • •2.       Use the command “software install” to install the newly downloaded image (or) the image present in the network.



C3850-01#software install file : new



The “new” keyword is used so that that the post-install package set should contain only the packages being installed. The old packages file will be renamed for future rollback purpose.  Without this option, the post-install package set is a merged set of the currently installed software and the new packages being installed. 



The source can be

  • flash:  or usbflash0: (or a sub-directory of these)
  • The network via tftp, ftp or http

NOTE:  When performing ‘software install’ on a switch with a source bundle that resides in the network, the source bundle is first downloaded to RAM on switch.  The source bundle is deleted from RAM when the operation completes.

Refer to the configuration guide to know about the other optional parameters of this command,

Example:

C3850#dir flash:

Directory of flash:/

<>

29511  -rwx   220716072  Oct 15 2012 12:57:59 +00:00  cat3k_caa-universalk9.SSA.03.08.88.EMP.150-8.88.EMP.bin

C3850#software install file flash:cat3k_caa-universalk9.SSA.03.08.88.EMP.150-8.88.EMP.bin

<>

[1 ]: Creating pending provisioning file

[1 ]: Finished installing software.  New software will load on reboot.

[1 ]: Committing provisioning file

[1 ]: Do you want to proceed with reload? [yes/no]: n

C3850#

Once the installation is completed, reload the switch and it will boot into the newly installed IOS XE image.

From Bundle mode:

                If the switch is currently running in “Bundle” mode, then we need to use the “software expand” command to convert the switch into the Install mode first and then install the new IOS XE.

The ‘software expand’ exec command is used to extract the package files and the provisioning file (packages.conf) from a source bundle (possibly the running bundle) and copy them to the specified destination directory in a local storage device.

This command will typically be used to convert from the bundle running mode to the installed running mode.

NOTE:  When performing ‘software expand’ on a switch with a source bundle that resides in local storage, the source bundle is first copied to the corresponding local storage device on the switch.  The source bundle used for the expand operation is left intact after it is expanded.

NOTE:  When performing ‘software expand’ on a switch with a source bundle that resides in the network, the source bundle is first downloaded to RAM of the switch.  The source bundle is deleted from RAM on the switch when the operation completes.

This example uses the following steps to prepare a switch for booting in installed mode, i.e., booting a package provisioning file (packages.conf)

  1. Boot      in bundle mode using ‘boot flash:

Can also boot from usbflash0: or via tftp

  1. Use the      ‘software clean file flash:’ command to remove any unused package, bundle      and provisioning files from flash:
  2. Use      the ‘software expand running to flash:’ command to expand the running      bundle to flash:
  3. Reload      the switch
  4. Boot      the installed packages using ‘boot flash:packages.conf’



Software Rollback:

The 'software rollback' exec command can be used to revert to a previous version of the installed software package set (i.e., an older packages.conf file)

This functionality relies on the existence of one or more 'rollback provisioning files’ in flash:, along with all of the .pkg files listed in the rollback provisioning file(s)

  • The rollback provisioning files are visible in flash: as packages.conf.00-, packages.conf.01-, etc.
  • packages.conf.00- is a snapshot of the packages.conf file as it looked prior to the last installation operation
  • packages.conf.01- is a snapshot of the packages.conf file as it looked two installations ago
  • And so on

When the 'software rollback' command is used, packages.conf.00- becomes packages.conf.  packages.conf.01- becomes packages.conf.00-.  And so on

Note:  If the 'software clean' command is used, future attempts to do a software rollback are likely to fail

Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

Sunday, February 23, 2014

Top 5 Tech Support questions for Cisco System's products - Weekly Update Feb 17th

The most actively discussed Tech Support questions on the web for Cisco System's products (Week of Feb 17/2014)

1. What are the CUCM Traces to Lookup for different scenarios?
2. How to Configure and Troubleshoot Call Forward to the PSTN using SIP Trunks ?
3. What are the methods to obtain tracelog for ASR1000 series routers?
4. What are the steps in configuring MPP On IOS XR To Control Network Management Traffic?
5. Log messages not appearing on telnet?


Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

Tuesday, February 18, 2014

How to Configure and Troubleshoot Call Forward to the PSTN using SIP Trunks ?


All outbound PSTN SIP calls are validated by the SIP Trunk provider to ensure the calls are valid and not toll fraud attempts.  The methods of call validation can vary from provider to provider, and many involve multiple methods for the same call.  This becomes a concern when using the default settings in a CUCM w/CUBE topology and attempting to call forward an inbound PSTN call back out to the PSTN.  One of the most common validation methods is for the SIP provider to examine the "From" field in the incoming INVITE of a call and make sure it matches to a known DID number for that customer.  The default setting in CUCM for forwarding calls is to maintain the CLID of the calling originator.  This causes the "From" field of an outgoing INVITE to contain the CLID number of the original PSTN caller, and not a valid DID belonging to the customer.  When the provider sees this with no additional information, it typically will reject the call setup attempt or ignore it completely.

There are three common solutions to this issue. 

The first is to alter the "From" field so that the CUCM will send the information of the redirecting number instead of the call originator.  In this scenario the "From" field will contain a valid customer DID number, and the call will validate.  The advantage of this technique is that it works with virtually all SIP providers.  The disadvantage is that the receiving party of the forwarded call will only see the caller-ID of the number that was set to forward (typically their own office DID number).  They will not see the caller-ID of the original caller, and therefore will not know who is calling prior to answering the call. 

Here are the steps to use the first method:
-Navigate to the SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Change the value in the drop down entitled "Calling Party Selection" to "Last Redirect Number (External)"
-Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours)

A second method is also often used, though it requires the SIP provider to validate calls through a different method.  This technique involves adding a p-asserted identity line in the outbound INVITE containing a valid DID.  The advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.  The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the p-asserted identity value instead of the "from" field value. 

Here are the steps to use the second technique when using a CUBE gateway:
-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.  Also make sure to use a valid DID number and SBC URL information.)

voice class sip-profiles 1
request INVITE sip-header P-Asserted-Identity add "P-Asserted-Identity:1111111111@sbc.sipprovider.com
>"

-Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider.  Also, most providers will look for a fully qualified domain name in the PAI, as opposed to an IP address.  Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address.

The third method is similar to the second but instead of a PAI line, this uses a Diversion Header.  The Diversion Header is added to the outbound INVITE and contains a DID number that the provider can validate the call with.  Like with the second option, the advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.  The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the diversion header value instead of the "from" field value. 

Here are the steps to use the third technique when using a CUBE gateway:
-Navigate to SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Check the "Redirecting Diversion Header Delivery - Outbound" Check box
-Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours)
-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.  Also make sure to use a valid DID number and SBC URL information.)

voice class sip-profiles 1
request INVITE sip-header Diversion modify "" "1111111111@sbc.sipprovider.com
>"

-Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider.  Also, most providers will look for a fully qualified domain name in the diversion header, as opposed to an IP address.  Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address.

Troubleshooting
The following debugs are useful in this call scenario:
debug ccsip messages
debug voip ccapi inout
When reading these debugs keeping the different call legs straight can get confusing.  It is recommended to use an application such as Notepad ++, and to mark the Call ID of each call leg traversing the CUBE.  The goal of these debugs is to check that the outbound INVITE for the forwarded call contains either the correct "from" field, or the correct "p-asserted identity" or "diversion header" field.  If using the "from" field method, check that the SIP INVITE coming from the CUCM contains the full 10 digit DID number for the last redirecting party, and that this value is the same in the INVITE going to the provider.  If using either the "p-asserted identity" method or the "diversion header" method, make sure that the outgoing call is matching the correct dial-peer that has the voice-class sip profile set on it.  If it is matching a different dial-peer, add the sip profile to that dial-peer.

Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

Saturday, February 15, 2014

What are the steps in configuring MPP On IOS XR To Control Network Management Traffic?


What are the features of MPP and how can we configure MPP on IOS XR to Control Network Management Traffic?

Management plane refers to a router’s architectural components involved in the processing of traffic that is meant for the management of the routing platform. Management Plane Protection (MPP) is a feature was introduced in Release 3.5.0. It helps to control the interfaces on which network management traffic can enter the router. This helps to enhance the router-level security and allows the network administrator better granularity in controlling management access to the router.

In the context of MPP, an in-band management interface is an interface that receives and processes management packets as well as forwards Internet traffic. This interface also referred to as a shared management interface.

An out-of-band interface allows only management protocol traffic to be forwarded or processed. This type of interface does not process or receive any customer or Internet traffic and, therefore, has lower potential for becoming a victim of a DoS attack. Out-of-band interfaces are usually also the last hop interfaces in the life of a packet, and these packets are then processed by higher-layer protocols on the router.

Following are the features of MPP:


  •      Enhances the manageability and security aspects of IOS XR.
  •      Helps alleviate the need to configure more access lists in controlling router access.
  •      Management ports on RP and DRP are not configurable under MPP because they are out of band by default.
  •      Controls incoming traffic for protocols, such as TFTP, Telnet, Simple Network Management Protocol (SNMP), SSH, and HTTP.
  •      Allows control for both in-band and out-of-band interfaces.
  •      Can specify a peer IPv4 or IPv6 address or subnet from which traffic is allowed, thus providing more control.
  •      Prevention of packet floods on switching and routing interfaces from reaching the CPU.

Configuration Example:


Default all interfaces accept the management traffic for the service you defined.

RP/0/0/CPU0:Router2#conf t
Wed May 15 22:09:17.316 UTC
RP/0/0/CPU0:Router2(config)#control-plane
RP/0/0/CPU0:Router2(config-ctrl)#management-plane
RP/0/0/CPU0:Router2(config-mpp)#inband
RP/0/0/CPU0:Router2(config-mpp-inband)#int gig0/0/0/1
RP/0/0/CPU0:Router2(config-mpp-inband-if)#allow telnet
RP/0/0/CPU0:Router2(config-mpp-inband-if)#exit
RP/0/0/CPU0:Router2(config-mpp-inband)#exit
RP/0/0/CPU0:Router2(config-mpp)#out-of-band
RP/0/0/CPU0:Router2(config-mpp-outband)#vrf MGMT
RP/0/0/CPU0:Router2(config-mpp-outband)#interface Gig 0/0/0/3
RP/0/0/CPU0:Router2(config-mpp-outband-if)#allow ssh peer
RP/0/0/CPU0:Router2(config-ssh-peer)#address ipv4 1.1.1.1
RP/0/0/CPU0:Router2(config-ssh-peer)#address ipv4 192.168.1.0/24
RP/0/0/CPU0:Router2(config-ssh-peer)#exit
RP/0/0/CPU0:Router2(config-mpp-outband-if)#allow SNMP peer address ipv4 192.168.1.1
RP/0/0/CPU0:Router2(config-mpp-outband-if)#commit
Wed May 15 22:11:38.607 UTC
RP/0/0/CPU0:Router2(config-mpp-outband-if)#end
RP/0/0/CPU0:Router2#

The above MPP configuration shows the Telnet protocol is enabled for only one in-band interface gig0/0/0/1, and the out-of-band management interface gig0/0/0/0/3 under vrf MGMT is enabled for SSH and SNMP.

Verification:


RP/0/0/CPU0:Router2#sh mgmt-plane
Wed May 15 22:16:02.529 UTC


Management Plane Protection

inband interfaces
----------------------

interface - GigabitEthernet0/0/0/1
       telnet configured -
               All peers allowed

outband interfaces
----------------------
interface - GigabitEthernet0_0_0_3/
       ssh configured -
               peer v4 allowed - 1.1.1.1
               peer v4 allowed - 192.168.1.0/24
       snmp configured -
               peer v4 allowed - 192.168.1.1
RP/0/0/CPU0:Router2#

MPP Show command:

1) RP/0/0/CPU0:Router2#sh mgmt-plane interface
2) RP/0/0/CPU0:Router2#sh mgmt-plane inband
3) RP/0/0/CPU0:Router2#sh mgmt-plan out-of-band

MPP debug Commands:

  • debug management-plane detail
  • debug management-plane errors
  • debug management-plane events
  • debug management-plane detail job
  • debug management-plane errors job
  • debug management-plane events job

Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.
 
/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */