Archives for posts with tag: protocol

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

RH

Advertisements

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………….

http://www.netcontractor.pl/blog/?p=371

RH

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.

BGP

BGP

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 10.4.1.1. So it will look to actively establish the connection with any configured peers.

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

We can verify this with the following command.

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

Lets modify this behaviour, use the commands.

router bgp 500
 neighbor 150.1.1.1 transport connection-mode passive
 neighbor 150.1.1.5 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: 150.1.1.2, Local port: 179
Foreign host: 150.1.1.1, Foreign port: 34121
Local host: 150.1.1.6, Local port: 179
Foreign host: 150.1.1.5, 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.

8.2.1
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.

Interesting.

RH

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.

Active-Standby

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 192.168.1.1 255.255.255.0 standby 192.168.1.2
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 172.16.1.1 255.255.255.0 standby 172.16.1.2
!
failover lan interface lan_fail1 gig3
failover interface ip lan_fail1 10.2.2.1 255.255.255.252 standby 10.2.2.2
!
failover link stateful_fail2 gig2
failover interface ip stateful_fail2 10.1.1.1 255.255.255.252 standby 10.1.1.2
!
failover key cisco123
!
failover lan unit primary
!
failover replication http
!
prompt hostname priority state
!
failover

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 10.2.2.1 255.255.255.252 standby 10.2.2.2
!
failover key cisco123
!
failover lan unit secondary
!
failover

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 asa1@yourdomain.com
logging recipient-address rh@mydomain.com
smtp-server x.x.x.x

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

RH.

This lab is setup for Multicast Source Discovery Protocol (MSDP) I will also be applying Source Active (SA) filtering on our Rendezvous Points (RP). On this occasion I will use Auto-RP to discover RP on each domain then use MSDP to enable us to share SA messages about our multicast sources. The SA filtering will be applied to R2 and R3. When using MSDP setup a multicast boundary, imagine a line between domains where you create an access-list which permits or allows any multicast address which you specify.

The reason I am using Auto-RP is to show the significance of using the multicast boundary, we will block the Auto-RP multicast address of 224.0.1.39 and 224.0.1.40 this will guarantee the boundaries between our domains, but not limited to only that purpose.

The main commands you will need are “ip msdp peer [ip address] connect-source [interface]” for SA filtering use the command “ip msdp sa-filter in | out [peer ip] list [access-list]” for the multicast boundary under interface use the command “ip multicast boundary [access-list] in | out filter-autorp” My previous blog “Multicast Notes” will provide a little more detail, and also some examples of access-lists.

MSDP Topology

MSDP Topology

 

Attached are the config’s for each router (Router Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Verify our msdp peers with the command “show ip msdp summary” from R3 shows we have 2 MSDP peers, both show as UP. All is looking good at this point.

R3#sh ip msdp summary
MSDP Peer Status Summary
Peer Address     AS   State   Uptime/  Reset    SA   Peer Name
Downtime Count  Count
10.255.255.2     2     Up         00:09:29      0          0            ?
10.255.255.6     6     Up         00:10:19      0          0            ?

We can also use the command “show ip msdp peer 10.255.255.2” from R3 to show us is if any SA filtering is being applied and also how many SA messages received from the peer. In our example we have received 1 SA message from our peer 10.255.255.2 highlighted in red, and we are filtering inbound SA messages, also highlighted in red.

MSDP Peer 10.255.255.2 (?), AS 2
Connection status:
State: Up, Resets: 0, Connection source: Loopback1 (10.255.255.3)
Uptime(Downtime): 00:17:41, Messages sent/received: 18/19
Output messages discarded: 0
Connection and counters cleared 00:19:31 ago
SA Filtering:
Input (S,G) filter: 101, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 1
Input queue size: 0, Output queue size: 0
Message counters:
RPF Failure count: 0
SA Messages in/out: 1/0
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 0/0

To display any SA messages the router has received we use the command “show ip msdp sa-cache” this will display the source tree entry for any multicast sources our neighbour is aware of, bearing in mind all SA messages are flooded to MSDP neighbours unless filtered by an SA-filtering

R3#sh ip msdp sa-cache
MSDP Source-Active Cache – 1 entries
(74.74.74.5, 239.4.4.4), RP 2.2.2.2, BGP/AS 2, 00:01:50/00:05:04, Peer 10.255.255.2

Now let’s consider SA-filtering, as per my multicast notes blog I will use this to filter messages sent from R2 to R3. The scenario is as follows, R5 is the multicast source of 239.4.4.4 and 232.8.8.8 but R7 doesn’t need to receive multicast traffic from R5 on 232.8.8.8 only traffic from R5 239.4.4.4 is required. So on R2 which is the nearest RP to R5 I will filter outbound messages to R3. In reverse we could do an inbound filter on R2. Configuration is as follows on R2.

access-list 101 permit ip host 74.74.74.5 host 239.4.4.4
!
ip msdp sa-filter out 10.255.255.3 list 101

Let’s test this with a ping to the multicast address.

R5#ping 239.4.4.4 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds:
Reply to request 0 from 74.74.74.1, 28 ms
Reply to request 0 from 17.17.17.7, 156 ms
Reply to request 1 from 74.74.74.1, 52 ms
Reply to request 1 from 17.17.17.7, 180 ms
Reply to request 2 from 74.74.74.1, 48 ms
Reply to request 2 from 17.17.17.7, 176 ms

R5#ping 232.8.8.8 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 232.8.8.8, timeout is 2 seconds:
Reply to request 0 from 74.74.74.1, 52 ms
Reply to request 1 from 74.74.74.1, 48 ms
Reply to request 2 from 74.74.74.1, 40 ms

So as you can see above R7 replies to 239.4.4.4 but not 232.8.8.8, so the filter works as expected.

Also on R2 I used an inbound SA-Filter this does the opposite from an outbound filter. So the commands will only accepts SA-messages from peer 10.255.255.3 with (10.10.10.4 , 232.8.8.8).

ip msdp sa-filter in 10.255.255.3 list 102
access-list 102 permit ip host 10.10.10.4 host 232.8.8.8

Below you can see some packet captures on the routers showing the source active messages being sent from R2 to R3 and also from from R3 to R6.

MSDP SA from R2 -> R3

MSDP SA from R2 -> R3

MSDP SA from R3 -> R6

MSDP SA from R3 -> R6

RH

This lab is set up for the bootstrap protocol, for this to work we specify the candidate BSR router (C-BSR) and the candidate RP (C-RP). I have set the same router to provide both functions.
The command “ip pim bsr-candidate [interface] [0-32] [0-255]” sets the router as candidate BSR, the 0-32 is the hash mask value, and the 0-255 is the priority. The hash value can be used to distribute group addresses evenly among multiple C-RP. The next command needed is “ip pim rp-candidate [interface]” this allows the router to send candidate rp advertisements to the BSR.

BSR Topology

The C-BSR will send bootstrap messages to all PIMv2 on address 224.0.0.13, once the C-RP’s receive this they unicast their C-RP messages to the BSR. The BSR doesn’t select the RP it just lists them and the PIMv2 routers choose the RP. See the picture below from a packet capture the BSR sends the bootstrap message to all PIMv2 routers with the group and C-RP’s. This is how the Bootstrap Protocol differs from Auto-RP.

BSR Message

BSR Message

I’ve used an access-list in my example to show that we can distribute certain groups among multiple RP’s. For example I’ve only allowed this C-RP to become RP for the groups 232.1.1.1 and 232.4.4.4.

Attached are the config’s for each router (Router-Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Now let’s confirm configurations with some well-known commands

Run “debug ip pim bsr” from R3 this will show us the C-RP announcing to the BSR that it has 2 prefix’s and its IP address. Next the BSR sends out the message to set the RP for each of the RP’s prefix’s, it also sends the originating address.

*Mar 1 01:40 PIM-BSR(0): Build v2 Candidate-RP advertisement for 10.10.10.3 priority 0, holdtime 150
*Mar 1 01:40 PIM-BSR(0): Candidate RP’s group prefix 232.1.1.1/32
*Mar 1 01:40 PIM-BSR(0): Candidate RP’s group prefix 232.4.4.4/32
*Mar 1 01:40 PIM-BSR(0): Send Candidate RP Advertisement to 10.10.10.3
*Mar 1 01:40 PIM-BSR(0): RP 10.10.10.3, 2 Group Prefixes, Priority 0, Holdtime 150
!
*Mar 1 01:40 PIM-BSR(0): RP-set for 232.1.1.1/32
*Mar 1 01:40 PIM-BSR(0):   RP(1) 10.10.10.3, holdtime 150 sec priority 0
*Mar 1 01:40 PIM-BSR(0): RP-set for 232.4.4.4/32
*Mar 1 01:40 PIM-BSR(0):   RP(1) 10.10.10.3, holdtime 150 sec priority 0
*Mar 1 01:40 PIM-BSR(0): Bootstrap message for 10.10.10.3 originated

From R2 use the command “show ip pim rp mapping” this will show us the group address and the RP responsible for that group, also listed is via bootstrap. You may wonder what the (?) is for? All this means is that the router cannot resolve a DNS name for the IP.

Group(s) 232.1.1.1/32
RP 10.10.10.3 (?), v2
Info source: 10.10.10.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:43:43, expires: 00:02:13
Group(s) 232.4.4.4/32
RP 10.10.10.3 (?), v2
Info source: 10.10.10.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:43:43, expires: 00:02:13

From R3 run the command “show ip pim bsr”, this will show all the information regarding our bootstrap setup, including the BSR, C-RP, uptime and any ACL’s associated.

PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 10.10.10.3 (?)
Uptime:     01:46:19, BSR Priority: 0, Hash mask length: 0
Next bootstrap message in 00:00:45
Candidate RP: 10.10.10.3(FastEthernet0/0)
Holdtime 150 seconds
Advertisement interval 60 seconds
Next advertisement in 00:00:22
Group acl: 20

Generate some traffic from the source R1 to the groups listed then you can use the “show ip mroute” command from a PIM enable router and see the source tree entry.

(*, 232.4.4.4), 00:00:15/stopped, RP 10.10.10.3, flags: SPF
Incoming interface: FastEthernet0/1, RPF nbr 15.15.15.3
Outgoing interface list: Null

(56.56.56.1, 232.4.4.4), 00:00:15/00:03:21, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 56.56.56.1
Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:00:15/00:03:16

RH

This lab is set-up for Auto-RP, for this to work we must specify an RP-Candidate “ip pim send-rp-announce [interface] scope [0-255] and RP-Mapping “ip pim send-rp-discovery [interface] scope [0-255] interval [seconds]”

“ip pim auto rp listener” This command needs to be on any other routers participating in PIM, what this does is allow the dense-mode flooding of RP-Announce (224.0.1.39) and RP-Discovery (224.0.1.40) messages thus allowing the RP to be elected on a Sparse-Mode network.

Auto-RP topology

Attached are the config’s for each router (Router Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Now lets confirm configurations with some well-known commands.

Run ” debug ip pim auto-rp” from the mapping agent this shows us the RP-Announce received from R3 and also shows the mapping agent R2 sending RP-Discovery messages out both PIM enabled interfaces.

*Mar 1 00:06:28.719: Auto-RP(0): Received RP-announce packet of length 48, from 15.15.15.3, RP_cnt 1, ht 181
*Mar 1 00:06:28.723: Auto-RP(0): Update (224.0.0.0/4, RP:15.15.15.3), PIMv2 v1
*Mar 1 00:07:21.475: Auto-RP(0): Send RP-discovery packet of length 48 on FastEthernet0/1 (1 RP entries)
*Mar 1 00:07:21.475: Auto-RP(0): Send RP-discovery packet of length 48 on FastEthernet0/0(*) (1 RP entries)

From R1 run the command “sh ip pim rp mapping” this shows that the RP was elected via Auto-RP

Group(s) 224.0.0.0/4
 RP 15.15.15.3 (?), v2v1
 Info source: 56.56.56.2 (?), elected via Auto-RP
 Uptime: 00:09:37, expires: 00:02:17

Confirm the auto-rp multicast address’ are in the mroute table with the command “show ip mroute” this shows the source tree entries for the mapping-agent (224.0.1.40) and the RP-Announce (224.0.1.39)

(15.15.15.3, 224.0.1.39), 00:00:28/00:02:31, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 56.56.56.2
Outgoing interface list: Null

(56.56.56.2, 224.0.1.40), 00:12:39/00:02:14, flags: PLT
Incoming interface: FastEthernet0/0, RPF nbr 56.56.56.2
Outgoing interface list: Null

Generate some traffic from R1 multicast source 232.4.4.4, R4 has already sent the IGMP join message to the RP for the group, so will have the IGMP connected group and begin to build the initial shared tree then eventually the source tree to R1.

 (*, 232.4.4.4), 03:23:51/stopped, RP 15.15.15.3, OIF count: 1, flags: SJC
(56.56.56.1, 232.4.4.4), 00:00:04/00:02:55, OIF count: 1, flags:

This confirms our multicast setup is working correctly.

RH