Cisco ASA 9.5 – Remote Access VPN in Multiple Context Mode

For those who might have missed. Finally ASA got remote access VPN support for multiple context mode. This is what release notes on 9.5 software say:

Screen Shot 02-21-16 at 04.17 PM 001

I.e. with Apex Subscription License you can now have SSL VPN.

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