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:
I.e. with Apex Subscription License you can now have SSL VPN.
Month: March 2016
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-brd 64700:10route-target export 64700:1route-target import 64750:1 |
ip vrf network-a rd 65650:10 route-target export 65600:1 route-target import 64650:1ip vrf network-brd 64600:10route-target export 64750:1route-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):
Full BGP configuration examples:
R4
router bgp 64600 |
R5
router bgp 64600 |
Here is all neighbors status:
R4
#sh bgp vpnv4 all neighbors | inc BGP |
|
R5
#sh bgp vpnv4 unicast all neighbors | inc BGP |
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:
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
|
R4 VRF network-b
#sh ip route vrf network-b
|
R5 VRF network-a
#sh ip route vrf network-a
|
R5 VRF network-b
#sh ip route vrf network-b
|
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 #9197773803Matched with rule 1Original number: #9197773803 Translated number: 3777Original number type: none Translated number type: noneOriginal 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=calling2091547: //-1/3CE0EAE998BB/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 242091548: //-1/3CE0EAE998BB/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 242091549: //-1/3CE0EAE998BB/RXRULE/sed_subst: Successful substitution; pattern=#9197773803 matchPattern=^\#919(...)3803 replacePattern=3\1 replaced pattern=37772091550: //-1/3CE0EAE998BB/RXRULE/regxrule_subst_num_type: Match Type = none, Replace Type = none Input Type = unknown2091551: //-1/3CE0EAE998BB/RXRULE/regxrule_subst_num_plan: Match Plan = none, Replace Plan = none Input Plan = unknown2091552: //-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 translationVoIP Translation Rule debugging is enabledZA-IP_IPGW2-DC2#test voice translation-rule 24 #9198883803Matched with rule 1Original number: #9198883803 Translated number: 3888Original number type: none Translated number type: noneOriginal number plan: none Translated number plan: noneZA-IP_IPGW2-DC2#sh logg2092003: Jan 19 17:30:01.529: //-1/xxxxxxxxxxxx/RXRULE/sed_subst: Successful substitution; pattern=#9198883803 matchPattern=^\#919(...)3803 replacePattern=3\1 replaced pattern=38882092004: Jan 19 17:30:01.529: //-1/xxxxxxxxxxxx/RXRULE/regxrule_subst_num_type: Match Type = none, Replace Type = none Input Type = none2092005: 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 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).