Archives for posts with tag: commands

Some time ago I setup SIP trunking , I had to configure voice translation rules on the CUBE. Here’s are a few I setup that might help you (numbers changed). Once the numbers were translated they would match dial-patterns and be routed respectively.

Using regular expression.

Number 1 translates an incoming call to a 4 digit extension.

voice translation-rule 1
rule 1 /^02081234567/ /1111/

R1#test voice translation-rule 1 02081234567
Matched with rule 1
Original number: 02081234567 Translated number: 1111

Number 2 takes any number and adds a 9 to the beginning.

voice translation-rule 2
rule 1 /^.*/ /9\0/

R1#test voice translation-rule 2 02081234567
Matched with rule 1
Original number: 02081234567 Translated number: 902081234567

Number  3 translates a dialed number beginning with +44 or + to 90 or 900.

voice translation-rule 3
rule 1 /^\+44/ /90/
rule 2 /^\+/ /900/

R1#test voice translation-rule 3 +442081234567
Matched with rule 1
Original number: +442081234567 Translated number: 902081234567

R1#test voice translation-rule 3 +1123456789
Matched with rule 2
Original number: +1123456789 Translated number: 9001123456789

Number 4 translates a 4 digit number beginning with 5, drops the 5 and appends a country code and an area code.

voice translation-rule 4
rule 1 /^5\(…$\)/ /00442081234\1/

R1#test voice translation-rule 4 5678
Matched with rule 1
Original number: 5678 Translated number: 00442081234678

Number 5 translates any number beginning with 901* to 0044 and any number beginning with 900* drops the 9.

R1#test voice translation-rule 5 9020812345678
Matched with rule 1
Original number: 9020812345678 Translated number: 004420812345678

R1#test voice translation-rule 5 90012345678910
Matched with rule 2
Original number: 90012345678910 Translated number: 0012345678910


I was asked question about MPLS labels within a VRF. Well the question was ” when I type the command ‘show mpls ldp bindings vrf xxx‘ ” I don’t see any labels for my remote site prefixes.

In this case these labels aren’t assigned by LDP they are assigned by BGP.

The command he was looking for was “show ip bgp vpnv4 vrf xxx labels” I think a light went on in his head when i explained this to him!

If your still confused , imagine the LSP (unidirectional) R1 -> R4 is basically a virtual connection if you like , where R4 is the egress LSR for the packet. The packet will travel via R1 -> R2 -> R3 -> R4. The next hop actually is listed as R4 even though it has to pass through R2 and R3. Which by the way has it own labels to add on top of bottom of stack label for R4.


R1 pushes on the label 1234 for R4 and another label on top for R2 which is 22, next R2 removes its own label (22) and adds the label for R3 which is 33, R3 removes its own label (33) and forwards the packet with the label 1234 to R4. Bottom of stack bit is set to 1, R4 removes the label and forwards.


It’s worth making some notes on this subject to clear up a few misconceptions I found online.

Firstly I setup a lab to confirm what i’m about to say, the reason we use this command is to allow QoS to correctly classify or view the packets based on the original header, if the packet is encapsulated  it’s  treated the same as any other encapsulated packet. The original header and its QoS value is now unknown to the forwarding device.

So by enabling this command we can apply the classification before the encapsulation or tunneling happens.

Apply the command “qos pre-classify” to a tunnel interface, a crypto-map or a virtual tunnel interface.

Classification based on layer3 and layer4 information is the exact reason we would consider using this feature, classification based on TOS or DSCP values do not need to use this feature, that’s because of TOS byte preservation inherently built into IPSEC.

Once you’ve added the pre-classify command, apply a service-policy to the physical interface outbound, then all IP packets will be classified pre-encapsulation on any tunnels egressing that physical interface. In other words you will see hits on the policy-map individual classes.

A really great resource I found online is this QoS values calculator check it out………….


Neighbours with the lowest BGP router identifier will establish the connection to the remote peer via TCP port 179, the source port will be random. We can modify this behaviour with a few simple commands.

For example we want R1 to be a passive peer. That means that R2 and R3 will actively look to establish the session.



So from R1 if we leave everything as default then we can work out that R1 it the lowest router identifier, courtesy of a loop-back interface which is So it will look to actively establish the connection with any configured peers.

R1#sh ip bgp summary
BGP router identifier, local AS number 500

We can verify this with the following command.

R1#sh ip bgp neighbors | i host
Local host:, Local port: 57717
Foreign host:, Foreign port: 179
Local host:, Local port: 63542
Foreign host:, Foreign port: 179

Lets modify this behaviour, use the commands.

router bgp 500
 neighbor transport connection-mode passive
 neighbor transport connection-mode passive

Then clear the BGP session with clear ip bgp *

Now use the same command as before.

R1#sh ip bgp neighbors | i host
Local host:, Local port: 179
Foreign host:, Foreign port: 34121
Local host:, Local port: 179
Foreign host:, Foreign port: 32711

This shows us that foreign host has established the bgp connection sourcing from random port to port 179 on our local router.

RFC4271 which is the holy grail for BGP-4 states that.

When a BGP speaker is configured as active,
it may end up on either the active or passive side of the connection
that eventually gets established.  Once the TCP connection is
completed, it doesn’t matter which end was active and which was passive.
The only difference is in which side of the TCP connection has port number 179.

There exists a period in which the identity of the peer on the other
end of an incoming connection is known, but the BGP identifier is not
known.  During this time, both an incoming and outgoing connection
may exist for the same configured peering.  This is referred to as a
connection collision.



This blog will cover setting up 2 Cisco ASA firewall’s Active / Standby, so if one of the firewalls has a power issue or hardware failure, the standby firewall will wait a set amount of time before taking over from the failed device and resuming the traffic as if nothing happened. You can use stateful failover to resume IPsec sessions, NAT xlate, TCP, UDP, ARP etc. From version 8.4 routing information is also replicated.

The first thing you should know is you only need to set up 1 individual firewall, so my recommendation would be to get a firewall fully functional with all the configuration necessary, then the secondary firewall only needs a few commands before taking an entire copy of the primary firewall’s config, and becoming a standby firewall.

Before we begin lets take a look at the diagram, I used GNS3 but if you require to do this in real-life you would use crossover cables between the failover interfaces.This diagram depicts a single point of failure as the LAN switch but this is not the point of the blog, You would have more than one switch within your core design.


We will just use the basic config of the firewall, in my setup i have an IPsec tunnel between my ASA and R3, I used this to confirm that IPsec tunnel failover was working as expected.
You will need to decide beforehand which address space you will use for your failover interfaces, and your standby IP’s must be another useable IP within your primary IP subnet.

On ASA 1 use a console or SSH session and input the following commands. Be sure to use “no shutdown” on any interfaces you decide to use.

interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address standby
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address standby
failover lan interface lan_fail1 gig3
failover interface ip lan_fail1 standby
failover link stateful_fail2 gig2
failover interface ip stateful_fail2 standby
failover key cisco123
failover lan unit primary
failover replication http
prompt hostname priority state

Once that is complete, you can now configure the secondary firewall, you can use the command “clear config all” on the secondary firewall to clear all config before you input the commands below. This is the absolute minimum you require to get the secondary firewall up and running, again be sure to use “no shutdown” on any interfaces you need.

interface gig3
no shutdown
failover lan interface lan_fail1 gig3
failover interface ip lan_fail1 standby
failover key cisco123
failover lan unit secondary

After you enter the commands you will see the message “detected and active mate” this will confirm the 2 firewalls can see each other. The firewalls will begin to synchronise their configurations, the primary ASA will send over the configuration to the secondary. You will notice the prompt changes to ASA1/sec/stby# we use the command “prompt hostname priority state” for this purpose, so we can be sure which firewall is which.
The primary firewall prompt will be ASA1/pri/act#.

After this point you only need to make changes to the primary unit and any changes to the configuration and “write memory” you do on the primary will also be replicated to the standby unit.

The command “show failover” will provide you with all the necessary information you require should you need to troubleshoot or confirm your configuration is working as expected.

To manually failover the devices you can use the command “no failover active” on the active firewall or from the standby you can use ” failover active” note that when the primary unit recovers from a failure it does not automatically assume the active role.

You can have the ASA alert you when a failover has taken place by setting up email alerts.

logging mail critical
logging from-address
logging recipient-address
smtp-server x.x.x.x

This was one of my favourite blogs to write because the with the Cisco ASA everything just “works”


I will follow-up my notes with some labs over the coming weeks.

Enabled on the router with “ip multicast-routing
reserved range for IPv4, FF00::/8 for IPv6

If multiple PIM routers on the same LAN only one can forward the join and prune messages to the RP, so there is an election on the Designated Router (DR) uses the highest IP.

PIM Dense-Mode – uses a push method to all routers and if no hosts need the stream the router prunes off, this repeats every 3 minutes so not ideal for a large deployments.

Bi Directional PIM – uses shared trees (*, G) , this is useful for large scale deployment saves the RP building multiple source tree entries. The emphasis on location of the RP is critical in this mode, to ensure loop free path there is a designated forwarder (DF) role, this is worked out by the lowest cost unicast path to the RP.

PIM Sparse-Mode – uses on demand mechanism, clients will send a join message. Requires a Rendezvous Point (RP) Initially the multicast source will send traffic and the RP will build the source tree (S,G), once a client requests the stream the RP builds the shared tree (*,G) and source receives the traffic, if there is a better unicast path to the source the router (RP)will build the source tree (show ip mroute) and begin using that path.

PIM Sparse Mode Message Process.

Uses 7 messages , Hello, Bootstrap, Candidate RP-advertisement, Join/Prune, Assert, Register, Register-Stop, Neighbour discovery uses hello messages on PIMv2

Source sends traffic to destination multicast address, first router will see this and send a PIM register to the RP, RP acknowledges with register-stop, the RP now has the (S,G) entry in mroute table

Receivers send an IGMP join to the LAN the Designated Router (DR) will send the PIM join message to the RP, each router adds the OIL (outgoing interface list)back towards the receiver for (*, G)

Once the receiver knows about the RP and the source knows about the receiver, they will look to then build the source tree (S,G) entry.

RPF- Reverse path forwarding.

Loop prevention method for multicast, checks the multicast source address against the unicast routing table to see if it should be coming from there if not it will drop the packets.

Rendezvous Point

Statically assign this on each router with command “ip pim rp-address x.x.x.x”, this must be done on each router participating in multicast.

Auto-RP – we use commands to assign the mapping-agent and the candidate RP, we could have redundant RP’s or limit each RP to a certain Multicast address with filtering using ACL’s
we use “ip pim send-rp-announce [interface] scope [0-255]” , the scope is the number of hops we allow this to travel or TTL. Once configured it will begin to send RP-Announce message to the every 60 seconds

Next the mapping agent listens for RP-Announce messages from the C-RP’s and selects the RP’s. It then advertises the RP’s t the rest of the PIM domain RP-Discovery messages to every 60 seconds. “ip pim send-rp-discovery [interface] scope [0-255] interval [seconds]”

We can change the intervals at which RP announce and discovery messages are sent out by using the interval command at the end of the command. Shown above.

Cisco use the “ip pim auto rp listener” command to overcome the sparse mode problem with routers adding the RP. Use this on non RP routers. This is known as the chicken and the egg scenario. You need multicast to run multicast.
This enables the sparse-mode interface to dense flood only the rp-annoucne and rp-discovery messages on , enabling the RP to be elected on a sparse-mode network.

PIM BSR – Boot Strap Protocol – open standard compared to auto-rp , uses the all PIM routers address of and TTL of 1. So we select the BSR using the command “ip pim bsr-candidate [interface]” next we can set the candidate rp using “ip pim rp-candidate [interface]”

When router is configured as candidate BSR it sets timer to 130secs then listens for other BSR candidate messages, it advertises its priority 0-255 and IP address, highest priority wins, and then begins sending out BSR messages every 60 secs. When a PIM router receives a BSR message it floods out all interfaces except the one it received it on, this ensures the rest of the multicast routers know who is the BSR.

Once the BSR is know the C-RP begins sending candidate-RP-advertisement messages to the BSR (unicast) they contain the priority 0-255, RP IP address and the Multicast group address for which the RP is an originator for.

Hash function is useful for large multicast deployments where lots of sources are used, when we use the hash feature the RP’s can be load-balanced, the BSR advertises advertise a hash mask in its messages and the receiving routers run the algorithm that can assign a consecutive number of group addresses to one C-RP then it will assign the next group to the next C-RP, much like a standard subnet mask would work. This is specified in the “ip pim bsr-candidate” command.

RPF with Tunnel – This is implemented when need to load-balance traffic over to equal-cost path’s but with the RPF this prevents load balancing over physical links. So for example we would build a tunnel between the two routers that pass traffic through the two links, using per-destination or per packet balancing. (no ip route-cache) on the interfaces. This used along with the ip mroute command should see it work

Source Specific Multicast – Defined in RFC 4607, enables you to identify a set of multicast sources not only by group address but the sources as well, the SSM group is called a channel this is identified using the (S,G) the reserved group address’s for SSM and the IPv6 range FF3x::/32.
SSM channel is defined by a source and a group address so multiple sources can be assigned to the same group for examples. ( , then ( , this is a unique channel for each multicast group. Hosts will only receive traffic from the requested sources. Can help to protect against DOS attacks.

No RP is needed in this mode as Source Trees are built directly towards the source, because the source is already known. This uses the unicast routing table for forwarding decisions, The multicast source must be manually inputted in advance.

Enabled with “ip pim ssm default” also relies on IGMPv3 so “ip igmp version 3” this command is used at interface level

IGMP – Internet Group Management Protocol

IGMP is the protocol that functions between the hosts, it allows the router to know that a host is interested in the receiving the multicast stream for specific group.

Routers acts as a querier checking to see if host are still interested in a stream, on a LAN segment when more than one router exists.

IGMP is enabled when PIM is enabled has a TTL of 1 and are restricted to the LAN

IGMP 1 – RFC 1112, sends IGMP queries to (all-hosts multicast address) has no election as the IGMP querier, only one host per multicast address replies to the query all other suppress, no mechanism to leave the group. could take up to 3 minutes after the client has stopped listening before the traffic flow will stop.

IGMP 2- RFC 2236, querier election mechanism based on IP address ensures one router per segment sends IGMP.leave group message host send message to leave group when no longer requires the traffic. Leave latency reduced when compared to V1, when a host wants to leave the multicast stream is sends the leave message to (all routers multicast)

IGMP 3 – This version added support for SSM (source specific multicast) which allows for the client to not only specify the group they want to subscribe to but also the source of that traffic (useful if there are many sources in the same group).


Well Known Multicast Address

————————————————————- All host group which contains all devices on the same network All multicast routers group which contains all routers on the same network PIMv1 All OSPF All OSPF DR EIGRP PIM v2 all PIM routers multicast address. IGMP Version 3 Cisco Auto-RP-Announce address Cisco Auto-RP-Discovery address

MSDP – Multicast Source Discovery Protocol

Purpose is to discover multicast sources in other PIM domains, what happens is your own RP’s exchange information with RP’s in other domains. Just like BGP each peer must be explicitly configured. When a PIM DR registers a source with the RP, the RP sends out a SA (Source Active) message to all its MSDP peers.

SA message contains.
Address of the source
group address to which the source is sending
Originating IP

Uses TCP port 639 for peering connections

Every MSDP peer that receives a Source Active message floods those downstream to its own peers from the originator. If the RP receives more than one copy of a SA, the RP will consult the BGP next hop database to determine the next hop towards the SA originator. If AS is non-transit or stub the consult of BGP next hop database still applies to override this we use the command “ip msdp default-peer” so RPF checks are not necessary. One path – no possible loops.

MSDP Mesh Groups are used effectively when multiple RP’s are present in a single domain sources always register to certain RP’s but members must find any source. Every RP has a peering to all other RP’s in the domain. Mesh groups are configured with the command “ip msdp mesh-group [WORD] [IP address]”


Inbound – here is an example of an inbound SA from msdp, only allows SA messages for group from the source
access-list 101 permit ip host host
ip msdp sa-filter in list 101

Outbound – here is an example of an outbound SA filter which only sends SA messages to peer from specific group from source
access-list 102 permit ip host host
ip msdp sa-filter out list 102

Locally originated sources can be filtered with the command same idea as above.
ip msdp redistribute list xxx


A simple explanation of anycast is packets can be sent to a single IP and any number of devices can respond. When PIM-SM is brought into the mix what this means is we can map a single group to multiple RP’s all with the same “virtual IP” we cannot achieve this without MSDP.



The last item on our list is the service-policy, this is the part where we apply our policy-map to an interface and specify the direction for the policy.

To help you visualise how the command is used and which direction see the picture below.


QOS is being applied to traffic coming from inside our network going outbound to the WAN.

Your interface will look something like this.

interface FastEthernet0/0
 description WAN_interface
 bandwidth 20000
 ip address
 ip nbar protocol-discovery
 service-policy output QOS_Egress

To confirm the QOS is working you would use the command “show policy-map interface fastethernet 0/0” this will give you a whole bunch of information, see below for an example of how this might look.

Service-policy output: QOS_Egress

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 331150787/112001702019

Class-map: voice_traffic (match-all)
266055005 packets, 57655712122 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Priority: 7% (1400 kbps), burst bytes 35000, b/w exceed drops: 0
QoS Set
dscp ef
Packets marked 266055059

Class-map: voip_signal (match-any)
78149834 packets, 7487646866 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:  dscp cs3 (24) af31 (26)
78149834 packets, 7487646866 bytes
5 minute rate 0 bps
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 78149832/7487645664
bandwidth 3% (600 kbps)
QoS Set
dscp af31
Packets marked 78149834

Class-map: class-default (match-any)
9073254895 packets, 3302249852254 bytes
5 minute offered rate 998000 bps, drop rate 0 bps
Match: any
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/16751970/0
(pkts output/bytes output) 569664615/3424829483864
QoS Set
dscp default
Packets marked 9071570170
shape (average) cir 16000000, bc 160000, be 160000
target shape rate 16000000

As you can see it gives lots of information on how your QOS is performing, the default-class shows some drops that means its had to drop some packets when the link was congested and in fact means your QOS policy is doing its job if the drops were excessive you would increase the values or decrease whichever suits your network.

If you just want to view an indivdual class then you would use the command “show policy-map interface fastethernet 0/0 output class web_traffic” for example.

When using the “service-policy input QOS_Egress” you will receive an error stating that you cannot apply this to the interface, this is becuase CBWFQ is a mechanism for traffic queuing in the outbound direction, never for the inbound direction.

I hope my 3 part blog has gone some way to helping you understand QOS.