IPSec Proxy-ID

Proxy-IDs are entities that are used in IPSec tunnel negotiations (Phase-2 in case of IKEv1) to select which traffic actually goes to the tunnel. The always come in pairs (a sort of tuples) as Local+Remote. So in case of Cisco ASA or IOS-based router, when you make an ACL something like:

permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

You define 192.168.1.0/24 as Local Proxy ID and 10.1.1.0/24 as remote Proxy ID. I used subnet mask as in ASA, IOS-based routers use wilcard masks for ACL statements, but the idea is the same.

When the other end device receives this data it swaps Local and Remote Proxy IDs and starts looking for  a match in its configuration. I.e. for IPSec security associacions to get established successfully the following definition needs to be found:

Local Proxy ID Remote Proxy ID
10.1.1.0/24 192.168.1.0/24

and it has to match exactly.

A common doubt is whether it is possible to configure IPSec something like this:

Peer A:

permit ip 10.1.1.0 255.255.255.128 192.168.1.0 255.255.255.0

permit ip 10.1.1.128 255.255.255.128 192.168.1.0 255.255.255.0

Peer B

permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

And have the tunnel successfully established between 10.1.1.0/24 and 192.168.1.0/24? Two statements configured on Peer A match the same set of IP-addresses as statement configured on Peer B. So everything seems to be ok.

Well, it is not. As per configuration Peer A will generate two pairs of proxy ID (10.1.1.0/25, 192.168.1.0/24) and (10.1.1.128/25, 192.168.1.0/24) and send it to Peer B. Peer B will be waiting for (10.1.1.0/24, 192.168.1.0/24) and will not accept neither of pairs received from Peer A. The opposite way same thing will happen. Peer B will be sending (192.168.1.0/24, 10.1.1.0/24) and Peer A will reject it waiting for two Proxy-IDs pairs which are exactly inverse to the ones it has configured.

You will see a message similar to this in debug output:

[IKEv1]Group = 172.16.66.46, IP = 172.16.66.46, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 192.168.1.0/255.255.255.0/0/0 local proxy 10.1.1.0/255.255.255.0/0/0 on interface outside

To see this error you have to check debug on peer who receives the Proxy-ID pair. The one that sends it will just keep sending it and failing to establish the tunnel. This is generally a good hint for IPSec troubleshooting – always try to debug at the receiver side, because this is the one that compalins and reports errors.

So, whatever equipment you use from whatever vendor. The configuration that defines proxy IDs (in case of Cisco it is done with ACL statements) on one peer always has to be the mirror of the one from another peer.

Cisco AireOS Controller: How to Configure WLAN Over CLI

Cisco WLC command-line interface can be do a good job if you want to configure something really quickly.

Below is my example on how to configure SSID with basic radio and security (Pre-Shared Key) settings using CLI. Just substitute what is in bold with your own values, copy and paste it to WLC and you are done. Much faster than browsing the GUI looking for boxes to tick.

I have also come up with very basic Python script that just asks you all the parameters needed and then generates all the necessary command lines. Feel free to contact me if you want me to share it.

RF-Profiles with lower datarates disabled

config rf-profile create 802.11b Disable-Lowrate-24GHz-rfp

config rf-profile data-rates 802.11b disabled 1  Disable-Lowrate-24GHz-rfp
config rf-profile data-rates 802.11b disabled 2  Disable-Lowrate-24GHz-rfp
config rf-profile data-rates 802.11b disabled 5.5  Disable-Lowrate-24GHz-rfp
config rf-profile data-rates 802.11b disabled 6  Disable-Lowrate-24GHz-rfp
config rf-profile data-rates 802.11b disabled 9  Disable-Lowrate-24GHz-rfp
config rf-profile data-rates 802.11b disabled 11  Disable-Lowrate-24GHz-rfp
config rf-profile data-rates 802.11b mandatory 12  Disable-Lowrate-24GHz-rfp

config rf-profile create 802.11a Disable-Lowrate-5GHz-rfp
config rf-profile data-rates 802.11a disabled 6  Disable-Lowrate-5GHz-rfp
config rf-profile data-rates 802.11a disabled 9  Disable-Lowrate-5GHz-rfp
config rf-profile data-rates 802.11a mandatory 12  Disable-Lowrate-5GHz-rfp

Dynamic interface

config interface create Dynamic-Interface-Name VLAN-ID
config interface address dynamic-interface Dynamic-Interface-Name 10.1.1.16 255.255.255.0 10.1.1.1
config interface dhcp dynamic-interface Dynamic-Interface-Name primary 172.23.1.25 secondary 172.23.1.26

WLAN:

config wlan create WLAN-ID SSID-prf SSID-Name
config wlan interface WLAN-ID SSID-Name
config wlan security wpa wpa2 ciphers aes enable WLAN-ID
config wlan security wpa akm 802.1x disable WLAN-ID
config wlan security wpa akm psk enable WLAN-ID
config wlan security wpa akm psk set-key ascii SecurePreSharedKey WLAN-ID

AP Group:

config wlan apgroup add APGroup-Name
config wlan apgroup description APGroup-Name APGroup-Description

Dynamic interface and APs to AP group mapping

config wlan apgroup interface-mapping add APGroup-Name WLAN-ID Dynamic-Interface-Name

config ap group-name APGroup-Name AP1-Name

config ap group-name APGroup-Name AP2-Name

config ap group-name APGroup-Name AP3-Name

Enabling WLAN

config wlan enable WLAN-ID

PIM Sparse-Mode

My short study of how PIM Sparse-Mode multicast works:

Lab Topology
Lab Topology

The Sender

Here is what happens when sender originates streaming to a multicast group.

R4#ping 224.88.88.88 repeat 100

The router that is a PIM DR for this network segment (R6) sends Register message to the rendezvous-point:

R6#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       10.0.46.6       YES manual up                    up
GigabitEthernet2       10.0.56.6       YES manual up                    up
GigabitEthernet3       unassigned      YES unset  administratively down down
GigabitEthernet4       10.0.67.6       YES manual up                    up
Loopback0              6.6.6.6         YES manual up                    up
Tunnel0                10.0.56.6       YES unset  up                    up
R6#show ip pim interfaceAddress          Interface                Ver/   Nbr    Query  DR         DR
Mode   Count  Intvl  Prior
10.0.56.6        GigabitEthernet2         v2/S   1      30     1          10.0.56.6
10.0.67.6        GigabitEthernet4         v2/S   1      30     1          10.0.67.7
10.0.46.6        GigabitEthernet1         v2/S   0      30     1          10.0.46.6(R6 Gi1 IP)

R6#debug ip pim

PIM(0): Send v2 Data-header Register to 3.3.3.3 for 10.0.46.4, group 224.88.88.88

The router that has one of its interfaces configured as a rendezvous-point checks the reverse path, creates the PIM tunnel and responds with Register-Stop message:

R3#debug ip pim

PIM(0): Check RP 3.3.3.3 into the (*, 224.88.88.88) entry
PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (*, 224.88.88.88).
PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (10.0.46.4, 224.88.88.88).
PIM(0): Send v2 Register-Stop to 10.0.56.6 for 10.0.46.4, group 224.88.88.88

Here is how these messages look:

PIM-Register Message
PIM-Register Message
PIM-Register-Stop Message
PIM-Register-Stop Message

Notice the structure of PIM Register – it is a unicast IP packet that carries PIM datagram together with original ICMP packet sent by R4 to the multicast group.

R3 now has (*,G) and (S, G) entries created.

R3#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.88.88.88), 00:01:30/stopped, RP 3.3.3.3, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(10.0.46.4, 224.88.88.88), 00:01:30/00:01:29, flags: P
  Incoming interface: Ethernet0/1, RPF nbr 10.0.235.5
  Outgoing interface list: Null

Both entries have P-flag. This means that the traffic for this multicast group is pruned, because there are no receivers. For the same reason (S,G) entry has Null in Outgoing interface. Incoming interface is already known at this stage.

 

The receiver

Make a receiver join the group:

R1#debug ip igmp
IGMP debugging is on
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int e0/0
R1(config-if)#ip igmp join-group 224.88.88.88

IGMP(0): WAVL Insert group: 224.88.88.88 interface: Ethernet0/0 Successful
IGMP(0): Send v2 Report for 224.88.88.88 on Ethernet0/0

And it sends the IGMP membership report frame structure:

IGMP Membership Report
IGMP Membership Report

This basicaly says “I want to listen to this group”.

The router that receives IGMP Report messages sends PIM-Join Message to the RP:

PIM Join Message
PIM Join Message

On RP we now can see outgoing interface in (*,G) entry. This is where it sees the receiver.

R3#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.88.88.88), 00:18:09/00:03:00, RP 3.3.3.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:18:09/00:03:00

(10.0.46.4, 224.88.88.88), 00:01:59/00:01:11, flags: PT
Incoming interface: Ethernet0/1, RPF nbr 10.0.235.5
Outgoing interface list: Null

(*, 224.0.1.40), 01:00:34/00:03:26, RP 3.3.3.3, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 01:00:33/00:03:26

Now, if we start sending traffic to the group again we see get replies from the receiver:

R4#ping 224.88.88.88 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 224.88.88.88, timeout is 2 seconds:Reply to request 0 from 10.0.12.1, 62 ms
Reply to request 1 from 10.0.12.1, 8 ms

But on the RP we still have the trafic for 224.88.88.88 pruned and no record that has both incoming and outgoing interface.

R3#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.88.88.88), 00:49:35/00:03:03, RP 3.3.3.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 00:03:44/00:03:03

(10.0.46.4, 224.88.88.88), 00:01:01/00:02:09, flags: PT
Incoming interface: Ethernet0/1, RPF nbr 10.0.235.5
Outgoing interface list: Null

(*, 224.0.1.40), 01:32:00/00:03:19, RP 3.3.3.3, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 01:32:00/00:03:19

This is because the traffic has switched to Shortest-Path Tree which doesn’t include R3. R6 forwards packets coming from 10.0.46.4 out interface GigabitEthernet2 (Towards R5):

R6#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.88.88.88), 00:02:19/stopped, RP 3.3.3.3, flags: SPF
Incoming interface: GigabitEthernet2, RPF nbr 10.0.56.5
Outgoing interface list: Null

(10.0.46.4, 224.88.88.88), 00:02:19/00:01:21, flags: FT
  Incoming interface: GigabitEthernet1, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:02:19/00:03:08

(*, 224.0.1.40), 01:31:36/00:03:09, RP 3.3.3.3, flags: SJCL
Incoming interface: GigabitEthernet2, RPF nbr 10.0.56.5
Outgoing interface list:
GigabitEthernet4, Forward/Sparse, 01:29:43/00:03:09

Then R5 forwards them out GigabitEthernet1 (Towards R2):

R5#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.88.88.88), 00:04:29/stopped, RP 3.3.3.3, flags: SP
Incoming interface: GigabitEthernet1, RPF nbr 10.0.235.3
Outgoing interface list: Null

(10.0.46.4, 224.88.88.88), 00:04:29/00:02:52, flags: T
  Incoming interface: GigabitEthernet2, RPF nbr 10.0.56.6
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:04:29/00:03:02

(*, 224.0.1.40), 01:34:39/00:03:16, RP 3.3.3.3, flags: SJCL
Incoming interface: GigabitEthernet1, RPF nbr 10.0.235.3
Outgoing interface list:
GigabitEthernet2, Forward/Sparse, 01:33:47/00:03:16

Which forwards them to the receiver (R1) out Ethernet0/0:

R2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.88.88.88), 00:55:17/stopped, RP 3.3.3.3, flags: SJC
Incoming interface: Ethernet0/1, RPF nbr 10.0.235.3
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:09:26/00:02:05

(10.0.46.4, 224.88.88.88), 00:06:43/00:02:13, flags: JT
  Incoming interface: Ethernet0/1, RPF nbr 10.0.235.5
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:06:43/00:02:05

(*, 224.0.1.40), 01:39:03/00:02:59, RP 3.3.3.3, flags: SJCL
Incoming interface: Ethernet0/1, RPF nbr 10.0.235.3
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 01:39:01/00:02:59

All of the multicast routes the packets are following have SPT-bit set (T-flag in multicast routing table) which means they are part of Shortest Part Tree.

Make your devices more foolproof with EEM

One of the possible applications of Cisco Embedded Event Manager applets is to protect your network from faulures caused by human error. This can be done by blocking some CLI patterns.

One of the cases I met was a Campus LAN with large layer-2 domains. So it was not uncommon for a tecnitian when he or she wanted to add a new VLAN to a trunk to type switchport trunk allowed vlan <VLAN#> and by doing this disrupt communications for all the rest of the VLANs across this trunk.

I came up with this applet:

event manager applet no_allow_vlan
 event cli pattern "switchport trunk allowed vlan [1-9]" sync no skip yes
 action 1.0 syslog priority warnings msg "*** INTENTO DE EJECUTAR SWITCHPORT ALLOW VLAN SIN ADD ***"

It blocks switchport trunk allowed vlan <VLAN#> command while still allowing you to use switchport trunk allowed vlan add <VLAN#> and switchport allowed vlan remove <VLAN#>.

Wi-Fi Interference – Microwave Oven

For those who didn’t see, this is how microwave oven looks on spectrum analyzer diagrams taken on a foodcourt, about 15m from kitchens:

Duty Cycle Diagram
Duty Cycle Diagram

Here is an example taken about 1m from working microwave oven:

RSSI and Duty Cycle Diagrams
RSSI and Duty Cycle Diagrams

Duty cycle is close to 100% so it severely affects Wi-Fi channels it crosses.

TranslatorX – Analyzer for Cisco Voice Debugs and Traces

TranslatorX is a very nice and simpre tool that allows you to parse and browse through text debug/trace outputs. It works with CUCM Trace outputs and Call Detail Records as well as SIP, H.323, MGCP and Q.931 debugs from Voice Gateways.

Here is an example of TXT-file with debug ccsip messages opened with the tool:

TranslatorXSIP1

Based on this it can present you a call flow ladder:

TranslatorXSIP2

Here is an example for Q.931 debug:

Q931Msg1

Q931Msg2

Different colors here mean different calls.

By clicking on message string or arrow in the diagram you get the message text:

Q931Msg3

More info and download on www.translatorx.org

MPLS L3 VPN. Part 2 – MP-BGP

This is my second post on MPLS VPN. The first one that described Virtual Routing and Forwarding can be found here. Now I want to move on to MP-BGP component.

Why do we need MP-BGP?

We know that VRF instances are local for each router. Two different routers that have VRF instances configured for the same VPN have no idea that these two VRF instances belong to the same VPN even though these instances names or Route Distinguishers may match. But they need to exchange routes belonging to this VPN between themselves, i.e. send and receive them and insert received routes into correct VRF instance. How can we manage this? Well, this is what MP-BGP is used for. It permits exchanging routing information from different VRF together with VPN identification information.

Route Distinguishers and Route Targets

To differentiate routes belonging to different VRF instances MP-BGP uses Route Distinguishers and Route Target Import/Export parameters. The difference between RD and RT is the following:

Route Distinguisher is appended to IPv4-prefixes belonging to different VPNs when you set up MP-BGP and it makes the prefixes unique. Two 10.0.0.0/8 prefixes belonging to different VPNs will exist as something like RD1:10.0.0.0/8 and RD2:10.0.0.0/8 so BGP process won’t mix them up within the same physical router. However, this will not have any influence on whether these routes will be installed into certain VRFs in the peer routers that they will be sent to.

This other part is manupulated by Route Target parameter. Source router decides whether it wants to export certain Route Targets and then RT is sent within BGP Update as extended BGP community. At the receiving PE router VRF configuration determines routes with which RT it wants to import. Here is a configuration example:

R4 R5
ip vrf network-a
rd 64650:10
route-target export 64650:1
route-target import 65600:1ip vrf network-b
rd 64700:10
route-target export 64700:1
route-target import 64750:1		 ip vrf network-a
rd 65650:10
route-target export 65600:1
route-target import 64650:1ip vrf network-b
rd 64600:10
route-target export 64750:1
route-target import 64700:1

R4 will export routes from VRF network-a assigning them an RT of 64650:1 and R5 will install these routes into its network-a VRF as it has RT 64650:1 configured for import. R4 in turn will install routes coming from R5 with RT 65600:1 into network-a VRF. Similar exchange process will happen with network-b VRF.

MP-BGP Peering. Not to confuse with PE-CE VRF

PE router may have BGP peering with CE routers in order to exchange routes between Customer network and a VRF on PE router that is used to connect this Customer to Provider network. The terms Customer and Provider are applicable if we are talking of actually transporting some customer networks across some service provider network. MPLS VPN can be used in other circumstances where transport network and VPN networks belong to the same organization and the whole solution is used just to virtualize the networks. The concept, however, stays the same:

  • Between PE routers and MP-BGP (VPNv4) peering is used
  • Between PE and CE router classical IPv4 BGP peering is used but it is configured inside each customers (private network) VRF

BGP peering looks the following way (a lab example):

BGP-Peering
BGP Peering Diagram

Full BGP configuration examples:

R4

router bgp 64600
bgp router-id 10.4.4.4
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.5.5.5 remote-as 64600
neighbor 10.5.5.5 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 10.5.5.5 activate
neighbor 10.5.5.5 send-community extended
exit-address-family
!
address-family ipv4 vrf network-a
neighbor 10.0.47.2 remote-as 64650
neighbor 10.0.47.2 activate
exit-address-family
!
address-family ipv4 vrf network-b
neighbor 10.0.114.2 remote-as 64700
neighbor 10.0.114.2 activate
exit-address-family

R5

router bgp 64600
bgp router-id 10.5.5.5
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.4.4.4 remote-as 64600
neighbor 10.4.4.4 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 10.4.4.4 activate
neighbor 10.4.4.4 send-community extended
exit-address-family
!
address-family ipv4 vrf network-a
neighbor 10.0.58.2 remote-as 64651
neighbor 10.0.58.2 activate
exit-address-family
!
address-family ipv4 vrf network-b
neighbor 10.0.105.2 remote-as 64750
neighbor 10.0.105.2 activate
exit-address-family

Here is all neighbors status:

R4

#sh bgp vpnv4 all neighbors | inc BGP
BGP neighbor is 10.0.47.2, vrf network-a, remote AS 64650, external link
BGP version 4, remote router ID 172.16.1.1   <--- R7 (IPv4 VRF network-a)
BGP state = Established, up for 00:00:07
BGP table version 14, neighbor version 14/0
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
BGP neighbor is 10.0.114.2, vrf network-b, remote AS 64700, external link
BGP version 4, remote router ID 10.0.114.2   <--- R11 (IPv4 VRF network-b)
BGP state = Established, up for 00:37:19
BGP table version 14, neighbor version 14/0
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
BGP neighbor is 10.5.5.5, remote AS 64600, internal link
BGP version 4, remote router ID 10.5.5.5   <--- R5 (VPNv4)
BGP state = Established, up for 00:37:18
BGP table version 14, neighbor version 14/0
Last reset 00:37:25, due to BGP protocol initialization
BGP neighbor is 10.6.6.6, remote AS 64600, internal link
  

 

 

 

R5

#sh bgp vpnv4 unicast all neighbors | inc BGP
BGP neighbor is 10.0.58.2, vrf network-a, remote AS 64651, external link
BGP version 4, remote router ID 172.16.2.1   <--- R8 (IPv4 VRF network-a)
BGP state = Established, up for 04:00:16
BGP table version 20, neighbor version 20/0
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
BGP neighbor is 10.0.105.2, vrf network-b, remote AS 64750, external link
BGP version 4, remote router ID 10.0.105.2   <--- R10 (IPv4 VRF network-b)
BGP state = Established, up for 00:38:08
BGP table version 20, neighbor version 20/0
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
BGP neighbor is 10.4.4.4, remote AS 64600, internal link
BGP version 4, remote router ID 10.4.4.4   <--- R5 (VPNv4)
BGP state = Established, up for 00:31:54
BGP table version 20, neighbor version 20/0
Last reset 00:32:01, due to BGP Notification received of session 1, Administrative Reset

Here is an example of BGP VPNv4 Update message carrying both Route Distinguisher whithin NLRI and Route Target as Extended Community attribute for networks belonging to two configured VRF:

BGPUpd1

BGPUpd2

Route Distinguisher is carried together with network prefix information and Route Target – as an Extended BGP Community. AS-numbers are presented in asdot format so they look different from what is seen in the configuration.

Finally both routers have VPN routes from the other side present in correspondent VRF instances (local “customer” routes come from IPv4 session).

R4 VRF network-a

#sh ip route vrf network-a

Routing Table: network-a
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.47.0/30 is directly connected, Ethernet0/1
L 10.0.47.1/32 is directly connected, Ethernet0/1
172.16.0.0/24 is subnetted, 2 subnets
B 172.16.1.0 [20/0] via 10.0.47.2, 00:27:34
B 172.16.2.0 [200/0] via 10.5.5.5, 00:25:55

R4 VRF network-b

#sh ip route vrf network-b

Routing Table: network-b
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.114.0/30 is directly connected, Ethernet0/2
L 10.0.114.1/32 is directly connected, Ethernet0/2
B 192.168.1.0/24 [20/0] via 10.0.114.2, 00:27:36
B 192.168.2.0/24 [200/0] via 10.5.5.5, 00:25:57

R5 VRF network-a

#sh ip route vrf network-a

Routing Table: network-a
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.58.0/30 is directly connected, Ethernet0/1
L 10.0.58.1/32 is directly connected, Ethernet0/1
172.16.0.0/24 is subnetted, 2 subnets
B 172.16.1.0 [200/0] via 10.4.4.4, 00:00:06
B 172.16.2.0 [20/0] via 10.0.58.2, 00:28:30

R5 VRF network-b

#sh ip route vrf network-b

Routing Table: network-b
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.105.0/30 is directly connected, Ethernet0/2
L 10.0.105.1/32 is directly connected, Ethernet0/2
B 192.168.1.0/24 [200/0] via 10.4.4.4, 00:27:42
B 192.168.2.0/24 [20/0] via 10.0.105.2, 00:28:33

One More Digit Manipulation Case

Recently I’ve got an interesting task modify calling number on CUBE the following way:

An original calling number #919XXX3803

Had to be translated into 3XXX

The case could be interesting for those who like me struggle to understand better the regular expressions syntax.

Rule application

We have some outgoing dial-peer, that has outgoing translation profile configured:

dial-peer voice 777 voip
 description Test-Outgoing-DialPeer
 translation-profile outgoing Test-Translation-Profile

Translation profile has a rule configured for calling number manipulation:

voice translation-profile CUBE>IP-PBX
 translate calling 24

This rule is actually a set of regular expressions that calling number is checked against:

voice translation-rule 24
 rule 1 <regular expression>
 rule 2 <regular expression>

The regular expression format is the following:

rule 1 /match-pattern/ /replace-pattern/

The Match-Pattern

Again, we need to match #919XXX3803, where X is any single digit. The symbol for single digit in regular expression syntax is . (dot), so the string will be #919…3803

/#919...3803/

To be able to extract the digits contained in … and use them in the replace-pattern we have to put the dots in between brackets:

/#919(...)3803/

But the brackets are also a symbol to match in regular expression syntax. In order to have them treated as a separator we have to “escape” them with \ so the final match-pattern syntax will be

/#919\(...\)3803/

The Replace-Pattern

The replace pattern will be just those three digits that we get from the middle of matched number with 3 prepended. Match-pattern fragments that we put in brackets are numbered sequentially (1,2,3…) to place them in replace-pattern. The part we need is the first (and the only) one, so it will get number 1.  With 3 prefix the Replace-Pattern should look like:

/31/

But if we put it this way, 1 will just mean the 1 digit, not the match-pattern fragment and as a result we will get 31, not 3XXX we want. 1 should be escaped with \ so the replace-pattern will look the following way:

/3\1/

The whole translation rule looks like this:

voice translation-rule 24
 rule 1 /^\#919\(...\)3803/ /3\1/

Verification

The first and easiest thing to do is to execute test command and check the original and translated numbers:

#test voice translation-rule 24 #9197773803
Matched with rule 1
Original number: #9197773803    Translated number: 3777
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Then run debug voip translation command, make a call and check the output:

2091546: //-1/3CE0EAE998BB/RXRULE/regxrule_profile_translate_internal: number=#9197773803 type=unknown plan=unknown numbertype=calling
2091547: //-1/3CE0EAE998BB/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 24
2091548: //-1/3CE0EAE998BB/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 24
2091549: //-1/3CE0EAE998BB/RXRULE/sed_subst: Successful substitution; pattern=#9197773803 matchPattern=^\#919(...)3803 replacePattern=3\1 replaced pattern=3777
2091550: //-1/3CE0EAE998BB/RXRULE/regxrule_subst_num_type: Match Type = none, Replace Type = none Input Type = unknown
2091551: //-1/3CE0EAE998BB/RXRULE/regxrule_subst_num_plan: Match Plan = none, Replace Plan = none Input Plan = unknown
2091552: //-1/3CE0EAE998BB/RXRULE/regxrule_profile_translate_internal: xlt_number=3777 xlt_type=unknown xlt_plan=unknown

Note, that if you run debug voip translation an then execute test command, apart from giving you the test result, this command also produces debug output:

ZA-IP_IPGW2-DC2#debug voip translation
VoIP Translation Rule debugging is enabledZA-IP_IPGW2-DC2#test voice translation-rule 24 #9198883803
Matched with rule 1
Original number: #9198883803    Translated number: 3888
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: noneZA-IP_IPGW2-DC2#sh logg
2092003: Jan 19 17:30:01.529: //-1/xxxxxxxxxxxx/RXRULE/sed_subst: Successful substitution; pattern=#9198883803 matchPattern=^\#919(...)3803 replacePattern=3\1 replaced pattern=3888
2092004: Jan 19 17:30:01.529: //-1/xxxxxxxxxxxx/RXRULE/regxrule_subst_num_type: Match Type = none, Replace Type = none Input Type = none
2092005: Jan 19 17:30:01.529: //-1/xxxxxxxxxxxx/RXRULE/regxrule_subst_num_plan: Match Plan = none, Replace Plan = none Input Plan = none

GRE and IPIP Encapsulation – What Is The Difference?

We know that both GRE and IPIP encapsulate an IP packet into another IP packet, we know neither GRE nor IPIP provide encryption. But what is the difference between them?

Here it is:

IPIP
IPIP packet

 

GRE
GRE Packet

IPIP is really just another IP header on top of the original IP header, whilst GRE apart from traditional IP header data inserts GRE header that may contain checksum, authentication key, control the number of encapsulations, packet sequence, etc. The overhead for IPIP header is 20 bytes versus 24-36 bytes for GRE (the actual overhead depends on which GRE header data is being carried).