Archives for posts with tag: router

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

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.

Capture

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.

https://tools.ietf.org/html/rfc3107

RH

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

This post will show you how to configure a DHCP scope on your Cisco device.

DHCP uses the transport layer protocol UDP. DHCP server uses port 67 and the client uses port 68. DHCP would fall into layer 7 application layer protocols.

Create your pools just like below and add any options in you require i’ve shown 2 different option types one is IP and one is ASCII. You can add as many options as you need.

ip dhcp pool vlan10
network 10.10.10.0 255.255.255.0
update dns both override
domain-name mydomain.com
dns-server 10.1.1.111 10.2.2.222
netbios-name-server 10.1.1.111 10.2.2.222
default-router 10.10.10.1
option 137 ascii http://myserver.com/update
option 150 ip 192.168.101.1
lease 3
!
ip dhcp pool vlan16
network 10.10.16.0 255.255.255.0
update dns both override
domain-name mydomain.com
dns-server 10.1.1.111 10.2.2.222
netbios-name-server 10.1.1.111 10.2.2.222
default-router 10.10.16.1
option 150 ip 192.168.101.1
option 137 ascii http://myserver.com/update
lease 3
!

To add static DHCP reservations you need to add the MAC address as below. Note they start with ’01’ and in dotted hexadecimal. The ’01’ means that its Ethernet media type.

ip dhcp pool static-user1
host 10.10.10.54 255.255.255.0
client-identifier 01bb.cccc.dddd.ff
!
ip dhcp pool staticuser2
host 10.10.16.53 255.255.255.0
client-identifier 01xx.yyyy.zzzz.aa

The above configuration would be added to your switch that contains your SVI’s.

Confirm your configuration by using these commands below.

show ip dhcp binding – This will show all assigned IP’s and MAC address.
show ip dhcp pool [pool name] – This will show information on number of IP’s leased.
show ip dhcp conflict – This will show any conflicts in your pools.
clear ip dhcp binding | conflict [x.x.x.x] | * – This will clear the pool of the address you specify or all in the case of *.

DHCP

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 lab is set up for Source Specific Multicast (SSM) for this to work we need to enable our PIM interfaces for IGMPv3 as this supports source filtering which is fundamental for SSM. The IANA have reserved the 232.0.0.0/8 for SSM. With SSM we don’t require a RP.
SSM is enabled on your router with the command “ip pim ssm default” you can specify a range but if you choose default then the 232.0.0.0/8 range will apply. Then on each interface participating in PIM we use the command under interface configuration “ip igmp version 3”

 

SSM Topology

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

We can verify the IGMP groups from the DR to do this we use the command “show ip igmp membership x.x.x.x” on R3, in our case we can see SSM entries for 232.1.1.1

Channel/Group                 Reporter       Uptime   Exp. Flags Interface
/*,232.1.1.1                   10.10.10.4     03:16:22 stop 3MA   Fa0/0
15.15.15.2,232.1.1.1                           03:16:22 02:44 RA     Fa0/0
56.56.56.1,232.1.1.1                           03:16:22 02:44 RA     Fa0/0

To verify our SSM is working correctly let’s generate some traffic from the specific source in the above output. I will source traffic from 15.15.15.2 to 232.1.1.1 and we should see some replies.

R2#ping 232.1.1.1 source 15.15.15.2 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 15.15.15.2

Reply to request 0 from 10.10.10.4, 32 ms
Reply to request 1 from 10.10.10.4, 80 ms
Reply to request 2 from 10.10.10.4, 68 ms

Now let’s source the traffic from the same router but a different interface source address and see what happens………………… no replies.

R2#ping 232.1.1.1 source 56.56.56.2 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 56.56.56.2

Running a packet capture on the DR router shows the IGMPv3 membership report / Join Group from R4. This is sent to the multicast address of 224.0.0.22. This lists the group record for our multicast address and the sources from which we want to receive.

PCAP IGMPv3

PCAP IGMPv3

Some other points to mention, when we use source specific multicast we can re-use an existing address an example would be as above the group 232.1.1.1 is used twice as it’s from a different source this is sometimes referred to as channels. For example (15.15.15.2 , 232.1.1.1) is a different SSM “channel” from (56.56.56.1 , 232.1.1.1).

With SSM the last hop router will continue to send (S , G) join messages if they still exist on the receivers side, therefore the shortest path tree (SPT) from host to source will be maintained even if the source is no longer sending traffic.

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