Basic PIM Sparse Mode Configuration



PIM sparse mode (PIM SM)  the traffic from sources to the RP initially flows encapsulated in Register messages.

This activity is very intensive because of encapsulation/de-encapsulation mechanisms, also an SPT is built between the RP and the source (initiated by the RP), which results in (*, G) and (S, G) entries created between the RP and the source.


For the moment lets have this scenario



There are two commands that you need for simple PIM sparse mode (PIM SM) deployment (assuming that the rendezvous point [RP] is learned automatically via Auto-RP or bootstrap router [BSR] mechanisms; if not, the RP address has to be manually configured (using the ip pim rp-address).

  • Global command ip multicast-routing enables support for IP multicast on a router.
  • Interface command ip pim sparse-mode enables PIM SM operation on the selected interface.

An additional command is the SPT threshold,  the default  value (0) results in switching to the shortest-path tree (SPT) soon after receipt of the first multicast packet for the group.

If this switching is not desired for some or all groups, we can use the ip pim spt-threshold (in kbps) command, and optional standard access list defining the affected groups; if the infinity keyword is used, no switchover is allowed for those groups, and only shared trees will be used.

on R1,


on R3,


on R4,


on R6,


The RP address for sparse mode groups may be defined manually, or one of the mechanisms for automatic distribution of RP information (Auto-RP or BSR) may be used. To manually define the IP address of an RP for multicast groups, use the ip pim rp-address command.


we should do the same configuration on R3, R6, and on the RP (R4).


in Resume, only 3 steps are necessary to configure basic PIM SM:

  • Add the ip multicast-routing global command to the configuration.
  • Add the ip pim sparse-mode interface command to each interface in the router configuration to enable IP multicasting using PIMSM.
  • Configure the IP address of the rendezvous point (RP) using the ip pim rp-address address global command.


If there are any problems (no multicast flow, entries missing in multicast forwarding table, PIM Neighbors not seen, and so on) use the following two debugging commands to show information:

  • debug ip mrouting―Shows the activity in creating, maintaining, or deleting entries in the multicast forwarding table
  • debug ip pim―Shows PIM control messages and associated activity



The debug output of PIM messages for group,  a Join/Prune message for active group ( is composed and sent periodically (every 60 s) to the RP, and routers  by which the Join (Join-list) is received they propagated this to the upstream PIM Neighbor, until it hits the RP.

The RP (rendezvous point), WC (wildcard), and S (sparse) bits are set – meaning that the message travels upstream toward the RP, that the message relates to (*, G), and that G is sparse mode group.

On the RP, the Join is received on the serial interface, which is added to an Outgoing Interface List (OIL), or, if already there, the interface timers are “refreshed.”


The RP periodically send the RP-reachability message and propagates it down the shared tree to inform the nodes that RP is still reachable.


now if a source is present on the network:

on R1,


on the RP (R4),


on R3, image

Upon receiving the first multicast packet from the source, the first-hop router consults the RP mapping cache and finds the RP address for the group (

The first-hop router then encapsulates the data in a Register message and sends it in unicast manner directly to the RP.

The RP already has a shared tree state for the group and immediately reacts with the (S, G) Join message toward the source. It also de-encapsulates the data from the Register and forwards it down the shared tree.

When (S, G) Join reaches the first-hop router, the shortest-path tree (SPT) is built between the RP and the first-hop router, and the traffic is now forwarded natively (down the already built tree) toward the RP (in addition to registering it).

When the first multicast packet arrives natively at the RP, the RP sends a Register-Stop message to instruct the first-hop router to stop registering. The Registering flag is cleared.

The router where the SPT and shared trees diverge was inspected. (S, G) Join was received, entry created (interface was added to the OIL) and Join propagated toward the source. At the same time, (S, G) Prune with RPT-bit was forwarded toward the RP to stop it from sending (S, G) traffic down the shared tree. (S, G) traffic will flow directly via the SPT from the source to the receiver segments.

On the RP, the periodic (*, G) Join was received, and the timer was refreshed. Additionally, (S, G) Prune with the RPT-bit arrived on a serial interface that was deleted from the OIL for (S, G) entry (if already existed; otherwise the entry is created first and the interface deleted immediately).


A Networker Blog

High Availability Site-to-Site IPSec VPNs

In this post we will describe high-availability for site-to-site IPSec VPN networks, Hot Standby Router Protocol (HSRP) is often used to track routers’ interface status to achieve failover between routers.



Here we define ISAKMP policy and IKE pre-shared key for IKE authentication, Note that is the HSRP virtual IP address of the remote HSRP routers.


The trick here is with the IKE keepalive to detect the IPSec liveness of the remote VPN router. When HSRP failover happens, IKE keepalive will detect the HSRP router switchover.

Now on R3/R4 we can configure the following:


in here, we define HSRP under the interface. HSRP will track the internal interface. Now an HSRP group name must be  and will be used for IPSec configuration.  The “redundancy” keyword in the crypto map command specifies the HSRP group to which IPSec will be configured. 

if we test this configuration:


we get on R4 the following


Lets do R3 configuration now:


Now in This example we are going to demonstrate how HSRP and IPSec failover work together using the above setup and configuration, now in  normal operation,


and here we see that R3 is the Active router for HSRP.






When failover occurs on the R3 the primary HSRP router, becomes a standby router. Existing ISAKMP and IPSec SAs are torn down. The R4 becomes active and establishes new IPSec SAs with R1.




A Networker Blog

Types of Ephone-dns

The Ephones is the basic building block of the Call Manager express now days called Cisco Unified Communication Manager Express System, and you can combine 6 types of ephones-dns for different call situations, in this post I will only cover the 3 most basic ephone types and latter this week I will write about the other 3 ephone types.

  • Single-Line ephone-dn

Only 1 call to or from this ephone-dn can occur at one time, there is no support for call waiting, and is commonly used on paging, intercoms, call parking, MOH feeds, it is important to note that with this ephone-dn we create a virtual voice port.


  • Dual-line ephone-dn

Using this ephone type we can have 2 calls connections at the same time, since it has 2 channels, it could have 1 number or 2 ( – Dual-number ephone-dn – primary and secondary), with this type of ephone you can have features like call waiting, call transfer and conferencing, it is important to know that you should not use dual-line for call waiting, call transfer or conferencing.

 Dual-line ephone-dn

  • Shared ephone-dn

here, the ephone appers on 2/more different phones, but using the same ephone-dn and number, all the ephones configured with this ephone-dn will rings when a call arrives at the ephone-dn, and when a call is placed on hold any phone can retrieve it.

Shared ephone-dn

other ephone-dn types are  Multiple ephone-dns on 1 ephone,  Multiple ephone-dns on Different ephones and Overlay ephone-dn

A Networker Blog



Dijkstra’s algorithm requires a virtual router (a pseudonode), represented by the Designated Intermediate System (DIS), in order to build a directed graph for broadcast media. Criteria for DIS selection are, first, highest priority (the priority value is configurable) and, second, highest SNPA (on LANs the SNPA is the MAC address).


A selected router is not guaranteed to remain the DIS. Any adjacent IS with a higher priority automatically takes over the DIS role. This behavior is called preemptive, There is no backup DIS. Contrast this with OSPF, where the DR and backup designated router (BDR) are selected, and the other routers on the LAN establish full adjacencies with the DR and BDR. In case of DR failure, the BDR is promoted to DR and a new BDR is elected.


Unlike OSPF, IS-IS does not use a backup DIS, and routers on a LAN establish adjacencies both with the DIS and with all other routers,Rather than having each router connected to the LAN advertise an adjacency with every other router on the LAN, each router (including the DIS) just advertises a single adjacency to the pseudonode. Otherwise, each IS on a broadcast network with n connected I Ss would require (n) (n – 1) / 2 adjacency advertisements.

In IS-IS a broadcast link itself is modeled as a pseudonode (represented by the DIS.) that connects all attached routers to a star-shaped topology, The DIS generates the pseudonode LSPs ( equivalent of a network link-state advertisement (LSA) in OSPF).

(Traffic received by R4)


(traffic going out the interface s0/0 on R1)



An IS-IS update process is responsible for flooding the LSPs throughout the IS-IS domain. An LSP is typically flooded to all adjacent neighbors except the neighbor from which it was received. Level 1 LSPs are flooded within their local areas. Level 2 LSPs are flooded throughout the backbone.

Each IS originates its own LSP (one for Level 1 and one for Level 2). These LSPs are identified by the system ID of the originator and an LSP fragment number starting at 0. If an LSP exceeds the maximum transmission unit (MTU), it is fragmented into several LSPs, numbered 1, 2, 3, and so on.

IS-IS maintains the Level 1 and Level 2 LSPs in separate LSDBs.

When an IS receives an LSP, it examines the checksum and discards any invalid LSPs, flooding them with an expired lifetime age. If the LSP is valid and newer than what is currently in the LSDB, it is retained, acknowledged, and given a lifetime of 1200 seconds.

The age is decremented every second until it reaches zero (0), at which point the LSP is considered to have expired. Once the LSP has expired, it is kept for an additional 60 seconds before it is flooded as an expired LSP.

Sequence number PDUs (SNPs) are used to acknowledge the receipt of LSPs and to maintain LSDB synchronization. There are two types of SNPs: CSNP and PSNP. The use of SNPs differs between point-to-point and broadcast media.

CSNPs and PSNPs share the same format; that is, each carries summarized LSP information. The main difference is that CSNPs contain summaries of all LSPs in the LSDB, while PSNPs contain only a subset of LSP entries.

Adjacent IS-IS routers exchange CSNPs to compare their LSDB. In broadcast subnetworks, only the DIS transmits CSNPs. This CSNPs are periodically multicast (every 10 seconds) by the DIS on a LAN to ensure LSDB accuracy. If there are too many LSPs to include in one CSNP, the LSPs are sent in ranges. The CSNP header indicates the starting and ending LSP ID in the range. If all LSPs fit in the CSNP, the range is set to default values.


All adjacent neighbors compare the LSP summaries received in the CSNP with the contents of their local link-state databases to determine if their LSDBs are synchronized (in other words, they have the same copies of LSPs as other routers for the appropriate levels and area of routing)

Adjacent IS-IS routers use PSNPs to acknowledge the receipt of LSPs and to request transmission of missing or newer LSPs. On point-to-point networks, CSNPs are sent when the link comes up to synchronize the LSDBs.

A Networker Blog

Change the language on the Phones/CUE – UC520

Changing the Language for the Phones in the UC

Download the UC500 IP Phone Localization @

Save the file in C:\Program Files\Cisco Systems\CiscoSMB\Cisco Configuration Assistant\appdata\phoneloads\

Which is specified in the CCA on Configure -> Telephony -> Region : Location of Language Files


Select the Language you need to use, and click apply

Setting the Voice Mail Language

Using WinRAR or similar software, extract file from 


extract all the contents of file into any folder on CCA PC. Copy the cue-vm-de_DE-langpack.ise.7.0.3.prt1 that is available @ to the same folder. 

Go to Maintenance > Software Upgrade window. Select UC500 you want to localize, and

click “Upgrade Settings.”  Select cue-vm-k9.ise.x.x.x.pkg file, click Open 


Click Yes and then Upgrade

 And wait for 40 min

Until everything is completed 

 And save the configuration!

A Networker Blog

Call Manager Express with Dynamips.

With this easy steps you can have running Call Manager Express on your Emulated CME Router !!

The first thing to do, is to extract the content of the CME .ZIP File downloaded from in one folder.

Now we need to compress all the files that are inside this folder (except for the .Tar files that are inside this folder) into a new tar file, and upload this Tar into the CME router.


It´s important to not compress the other tar files into the new .tar created or you will have something like this:


now, each the .TAR files  must be uploaded 1 by 1  into the CME Router.


ok, once you have uploaded all *or at least the one you need * TARs , we are good to test this!

please bear  with me that I am not an expert in CME CLI, so I must use the Wizard *for the moment* to the the basic setup 🙂


and after some test here are there, I found that my DHCP Pool was incorrect, :-P,  so I changed it to use the network, with the correct default Gateway, and the TFTP 150 option manually configured on the IP Phone, and voila, the IP Communicator is here, registered in the CME.




A Networker Blog

The Down Bit

The down bit in the options field of the OSPF LSA header.


The sending PE  router redistributes the  OSPF route into  MP-BGP, copies the OSPF cost into  the MED  attribute,and  sets the  BGP extended  community  to indicate the LSA type from which the route was derived.

The receiving PE  router redistributes the   MP-BGP route back  into OSPF and  uses the original  LSA type  and the MED attribute  to generate an  interarea summary LSA, an interarea   summary LSA or  type  3 LSA  is always  generated because the receiving PE router   acts as an  ABR  between the  superbackbone  and  the  OSPF area (or areas).

When OSPFv2 is used on a PE-CE link that belongs to a particular VPN, the  PE router must redistribute  to that VPN’s  OSPFv2 instance certain  routes that have been installed in  the BGP routing table.   Similarly, a PE router  must redistribute to BGP routes that have been installed in the VPN-specific  OSPF  routing tables.
When the PE receives, from a CE router, a type 3, 5, or 7 LSA with the DN bit  set, the information  from that LSA  MUST NOT be  used during the  OSPF route  calculation.  As a result, the LSA  is not translated into a BGP  route.  The DN bit MUST be ignored in all other LSA types.

The down bit  is used between  the PE routers  to indicate which  routes were  inserted into the OSPF topology database from the MPLS VPN superbackbone  and  thus shall not be  redistributed back in the  MPLS VPN superbackbone. The  PE router that redistributes  the MP-BGP route  as an OSPF  route into the  OSPF topology database sets the down bit. The other PE routers use the down bit to  prevent this route from being redistributed back into MP-BGP


This prevents routes learned via  BGP from being redistributed to  BGP. (This restriction is analogous to the usual OSPF restriction that inter-area routes that are learned from area 0 are not passed back to area 0.)


Note that the DN bit has no other effect on LSA handling.  In particular,  an  LSA  with the  DN bit  set will  be put  in the  topological database,  aged,  flooded, etc., just as if DN were not set.


But to prevent  the customer  sites from  acting as  transit parts  of the   MPLS  VPN network, the OSPF route selection rules in PE routers need to be changed.   The PE routers  have  to ignore   all OSPF  routes  with  the down   bit set,  because these routes originated in  the MP-BGP backbone and the  MP-BGP route should be used  as the optimum route toward the destination.

This rule is  implemented with the  routing bit in  the OSPF LSA.  For routes   with the  down bit  set, the  routing bit  is cleared  and these routes never  enter the IP routing  table—even if they are  selected as the best  routes by  the shortest path first (SPF) algorithm. no capability vrf –


The down bit stops  the routing loops between  MP-BGP and OSPF. The  down bit   cannot, however, stop the routing loops when redistribution between  multiple  OSPF domains is involved

A Networker Blog