MPLS NAT Aware Sample Configurations

 

Internet access is perhaps one of the most popular services that Service Providers offer their customers. Customers have flexibility to purchase MPLS VPN services Internet connectivity from separate Service Providers. Customers can alternatively offer Internet connectivity directly from their network may it be from one of their remote sites or the central site. In the latter case, the Internet Service Provider (ISP) does not need to distinguish customer’s Internet and VPN traffic, because all traffic traversing through a Service Provider network would be MPLS VPN traffic.

In MPLS based BGP-VPNs (RFC 2547),  ISPs offered customers an interface that was capable of carrying intranet and internet traffic.

Traffic between intranet and internet in a MPLS BGP-VPNs requires NAT Services at the customer edge router, between the customer private addresses and a globally routable address.

Traditional NAT operation can be summarized as follows:

  • NAT’s interfaces are classified as either inside or outside interfaces
  • Typically inside interface(s) connect to private address space and outside interface connect to global address space.
  • NAT occurs after routing for traffic from inside-to-outside interfaces.
  • NAT occurs before routing for traffic from outside-to-inside interfaces.
  • Routing information must be populated in the next-hop router for prefixes used in the NAT pool that is used for translation, for routing return traffic.

Topology

R3#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#
R3(config)#ip vrf 23
R3(config-vrf)#rd 23:23
R3(config-vrf)#route-t 23:23
R3(config-vrf)#
R3(config-vrf)#ip vrf 13
R3(config-vrf)#rd 13:13
R3(config-vrf)#route-t 13:13
R3(config-vrf)#
R3(config-vrf)#int s0/0
R3(config-if)#ip vrf for 13
R3(config-if)#ip add 10.1.13.3 255.255.255.0
R3(config-if)#ip nat inside
R3(config-if)#no sh
R3(config-if)#
R3(config-if)#int s0/1
R3(config-if)#ip vrf for 23
R3(config-if)#ip add 10.1.23.3 255.255.255.0
R3(config-if)#ip nat inside
R3(config-if)#no sh
R3(config-if)#
R3(config-if)#int s0/2
R3(config-if)#ip add 10.1.34.3 255.255.255.0
R3(config-if)#ip nat out
R3(config-if)#no sh
R3(config-if)#exit
R3(config)#access-list 1 permit any
R3(config)#ip route vrf 13 1.1.1.1 255.255.255.255 10.1.13.1
R3(config)#ip route vrf 13 0.0.0.0 0.0.0.0 10.1.34.4 global
R3(config)#
R3(config)#ip route vrf 23 2.2.2.2 255.255.255.255 10.1.23.2
R3(config)#ip route vrf 23 0.0.0.0 0.0.0.0 10.1.34.4 global
R3(config)#
R3(config)#ip nat pool MYPOOL 10.1.34.50 10.1.34.255 netmask 255.255.255.0
R3(config)#ip nat inside source list 1 pool MYPOOL vrf 13
R3(config)#
R3(config)#ip nat inside source list 1 pool MYPOOL vrf 23
R3(config)#

Inside to Outside packet flow:

NatIntoOUt

NAT get hold of the packet, and does the translation (static or dynamic) and also stores the VRF table ID in the translation entry.

R3#show ip nat translations verbose
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.1.34.50:5      10.1.23.2:5        4.4.4.4:5          4.4.4.4:5
create 00:00:10, use 00:00:00 timeout:60000, left 00:00:59, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : 23, entry-id: 3, lc_entries: 0
--- 10.1.34.50         10.1.23.2          ---                ---
create 00:16:50, use 00:00:11 timeout:86400000, left 23:59:48, Map-Id(In): 2,
flags:
none, use_count: 1, VRF : 23, entry-id: 1, lc_entries: 0

Outside to Inside packet flow:

image

NAT receives the packet before routing and performs lookup on the translation table. NAT performs the reverse translation, and also sets the VRF table ID in the packet descriptor header. This enables the subsequent route lookup to occur on the right Forwarding Information Block (FIB). If the outgoing interface is in a VRF on the same PE, then the packet is forwarded as an IP packet. If the destination is on a remote PE, then the packet is imposed with labels and forwarded on the core facing interface.

A Networker Blog

%LDP-4-PWD: MD5 protection is required!

MPLS LDP messages (discovery, session, advertisement, and notification messages) are exchanged between LDP peers through two channels:

  • LDP discovery messages are transmitted as User Datagram Protocol (UDP) packets to the well-known LDP port.
  • Session, advertisement, and notification messages are exchanged through a TCP connection established between two LDP peers.

The MPLS LDP—Lossless MD5 Session Authentication feature allows an LDP session to be password-protected without tearing down and reestablishing the LDP session.

Old Style

New Style

R2(config)#mpls ldp neighbor 1.1.1.1 password 123
R2(config)#! 
R2(config-if)#interface Ethernet  1/0
R2(config-if)#  ip address 192.168.1.2  255.255.255.0
R2(config-if)#  mpls ip

R2(config)#access-list 99  permit 1.1.1.1
R2(config)#mpls ldp password required for 99
R2(config)#mpls ldp password option 1 for 99 KC
R2(config)#!
R2(config)#key chain KC
R2(config-keychain)#key 1
R2(config-keychain-key)#  key-string password
R2(config-keychain-key)#!
%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP

The disadvantage of using the old method is that when new password is required for a session,  this change would require the LDP session to be tear down. With this feature New passwords can be implemented/changed  without having to tear down the existing LDP session

KeyChain4LDP

A Networker Blog

My First EEM Applet Script


Cisco IOS Embedded Event Manager (EEM)
is a powerful tool integrated with Cisco IOS Software for system management from within the device itself. EEM offers the ability to monitor events and take informational, corrective, or any desired action when the monitored events occur or when a threshold is reached. Capturing the state of the router during such situations can be invaluable in taking immediate recovery actions and gathering information to perform root-cause analysis. Network availability is also improved if automatic recovery actions are performed without the need to fully reboot the routing device.

Ok let try to Prevent someone turning off Loopback Zero! 🙂

The Script:

event manager applet Lo0
event syslog occurs 2 pattern "Loopback0, changed state to admin"
action 1.0 syslog msg "Hey Someone shutdown my loopback0 - Turning it back on"
action 1.1 syslog msg "I am a Smart Router, i will turn my lo0 back up again"
action 1.2 cli command "enable"
action 1.3 cli command "configure ter"
action 1.4 cli command "int lo0"
action 1.5 cli command "no shut"
action 1.6 syslog msg "OK should be back up again"

EMMScript

Thanks to The Cisco Learning Network for this tip!

A Networker Blog

MPLS LDP Time to Converge

When a link flaps, it could take a long time for LDP to reexchange labels, off course a network can use the FIB in the meanwhile, but this could present several problems with applications that leverage the use MPLS, line MPLS VPN to say at least one. With MPLS LDP Session Protection, we can provide faster LDP convergence when a link recovers from an outage, and this is done maintaining the LDP session for a period of time.

Now when a link fails, we know that in frame mode mpls LDP would store all the labels in the LIB, even if they are not used, this is because the IGP could decide to use another path, but the real problem here, comes into play when the link is recovered, when the IGP determines that the link is available could probably change the next hop is the path to reach the network is better. The problem here is the POP action used in the LFIB table of the router while the LDP tries to establish again the session, adding to our networks, more time to converge, since the LIB might not contain the label from the new next hop, by the time the IGP had converged.

We have 2 ways to solve the convergence issues that we are faced on flapping links, the first solution is to use MPLS LDP Session Protection and the second one is to use MPLS TE make before.

MPLS Fundamentals Book by Luc de Ghen CCIE 1897 states:

A common problem in networks is flapping links. The flapping of links can have several causes, but it is not the goal of this book to look deeper into this. Flapping links do have an important impact on the convergence of the network. Because the IGP adjacency and the LDP session are running across the link, they go down when the link goes down. This is unfortunate, especially because the link is usually not down for long. The impact is pretty severe though, because the routing protocol and LDP can take time to rebuild the neighborship. LDP has to rebuild the LDP session and must exchange the label bindings again. To avoid having to rebuild the LDP session altogether, you can protect it. When the LDP session between two directly connected LSRs is protected, a targeted LDP session is built between the two LSRs. When the directly connected link does go down between the two LSRs, the targeted LDP session is kept up as long as an alternative path exists between the two LSRs. The LDP link adjacency is removed when the link goes down, but the targeted adjacency keeps the LDP session up. When the link comes back up, the LSR does not need to re-establish the LDP session; therefore, the convergence is better. The global command to enable LDP Session Protection is this:

mpls ldp session protection [vrf vpn-name] [for acl] [duration seconds]

A Networker Blog

CME SIP Trunk Configuration Example.


version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname CMERouter
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
memory-size iomem 5
ip cef
!
!
no ip dhcp use vrf connected
!
ip dhcp pool ITS
network 192.168.9.0 255.255.255.0
option 150 ip 192.168.9.254
default-router 192.168.9.254
!
!
ip ftp username cisco
ip ftp password cisco
ip name-server 192.168.2.1
!
!
!
!
!
!
voice service voip
allow-connections sip to sip
sip
registrar server expires max 3600 min 600
!
!
!
!
!
!
!
!
!

voice translation-rule 6
rule 1 /^9/ //
!
voice translation-rule 666
rule 1 /300/ /17772028487/
!
!
voice translation-profile OUT
translate calling 666
translate called 6

!
!
!
!
username cisco privilege 15 password 0 cisco
!
!
!
!
!
!
interface Loopback0
ip address 10.1.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface FastEthernet0/0
ip address 192.168.9.254 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.2.102 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 192.168.2.1
!
!
ip http server
no ip http secure-server
ip http path flash:
ip nat inside source list 101 interface FastEthernet0/1 overload
!
access-list 101 deny   ip 10.0.0.0 0.255.255.255 192.168.2.0 0.0.0.255
access-list 101 deny   ip 10.0.0.0 0.255.255.255 192.168.9.0 0.0.0.255
access-list 101 permit ip any any
!
!
!
tftp-server flash:P00405000700.bin
tftp-server flash:P00405000700.sbn
tftp-server flash:P00308000500.bin
tftp-server flash:P00308000500.loads
tftp-server flash:P00308000500.sb2
tftp-server flash:P00308000500.sbn
!
control-plane
!
!
!
dial-peer voice 901 voip
translation-profile outgoing OUT
destination-pattern 9.T
session protocol sipv2
session target dns:callcentric.com
dtmf-relay sip-notify rtp-nte
codec g711ulaw
!
sip-ua
authentication username 17772028487 password 1313591A07 realm callcentric.com
no remote-party-id
retry invite 4
retry response 3
retry bye 2
retry cancel 2
retry register 5
timers register 250
registrar dns:callcentric.com expires 3600
sip-server dns:callcentric.com
!
!
telephony-service
max-ephones 10
max-dn 100
ip source-address 10.1.1.1 port 2000
calling-number local secondary
timeouts interdigit 2
create cnf-files version-stamp Jan 01 2002 00:00:00
max-conferences 4 gain -6
web admin system name cisco secret 5 $1$Z2bp$.Ty2WFXnYAi4j7SI5vBHG/
transfer-pattern .T
secondary-dialtone 9
!
!
ephone-dn  1  dual-line
number 300 secondary 17772028487
label CIPC
!
!
ephone  2
mac-address 0025.B370.971B
type CIPC
button  1:1
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
exec-timeout 0 0
privilege level 15
logging synchronous
no login
!
!
end

which results in:

A Networker Blog

Some MPLS Features.-

image

image

Check whether TDP or LDP is enabled on the routers and that the neighbors use the same protocol. TDP and LDP are not compatible with each other.

image

IP

This field shows that MPLS IP is configured for an interface. The Label Distribution Protocol (LDP ) appears in parentheses to the right of the IP status. The LDP is either:

  • Tag Distribution Protocol (TDP), which the Cisco Tag Switching architecture defines
  • LDP RFC 3036

Tunnel

This field indicates the capacity of traffic engineering on the interface.

Operational

This field shows the status of the LDP.

    The establishment of an LDP session between two routers requires a session TCP connection by which label advertisements can be exchanged between the routers. To establish the session TCP connection, each router must know the transport address (IP address) of the other router.

    The LDP discovery mechanism provides the means for a router to advertise the transport address for its end of a session TCP connection.

    The transport address advertisement itself may be explicit, in which case it appears as part of the contents of discovery hello messages sent to the peer, or implicit, in which case it does not, and the peer uses the source IP address of received Hello messages for the peer’s transport address.

    The mpls ldp discovery transport-address command provides the means to modify the default behavior described in the Defaults section of this document.

    When the interface keyword is specified, LDP advertises the IP address of the interface in LDP discovery hello messages sent from the interface. When the IP-address argument is specified, LDP advertises the specified IP address in LDP discovery hello messages sent from the interface.

    image

    image

  • mpls ldp autoconfig

To enable Label Distribution Protocol (LDP) on interfaces for which an Open Shortest Path First (OSPF) instance or Intermediate System-to-Intermediate System (IS-IS) instance has been defined

image or to disable LDP on selected interfaces, use the no mpls ldp igp autoconfig command.

image

To cause a router to advertise an Explicit Null label in situations where it would normally advertise an Implicit Null label

image

image The Implicit Null label causes the previous hop (penultimate) router to do penultimate hop popping. Situations exist where it might be desirable to prevent the penultimate router from performing penultimate hop popping and to force it to replace the incoming label with the Explicit Null label

image When you issue the mpls ldp explicit-null command, Explicit Null is advertised in place of Implicit Null for directly connected prefixes permitted by the prefix-acl argument to peers permitted by the peer-acl argument.

image now on R3

image

This configuration guarantees that packets with a ToS bit precedence value of 6 receive a specified percentage of the bandwidth of the designated outgoing links. Second, if you still experience a problem, use the mpls ldp tcp pak-priority command.

before applying the command.

image

after,

image

image

To bind a prefix to a local or remote label, use the mpls static binding ipv4 command in global configuration mode.

The mpls static binding ipv4 command pushes bindings into Label Distribution Protocol (LDP).  LDP then needs to match the binding with a route in the Routing Information Base (RIB) or Forwarding Information Base (FIB) before installing forwarding information.

The mpls static binding ipv4 command installs the specified bindings into the LDP Label Information Base (LIB). LDP will install the binding labels for forwarding use if or when the binding prefix or mask matches a known route.

Static label bindings are not supported for local prefixes, which are connected networks, summarized routes, default routes, and supernets. These prefixes use implicit-null or explicit-null as the local label.

If you do not specify the input or output keyword, input (local label) is assumed.

For the no form of the command:

If you specify the command name without any keywords or arguments, all static bindings are removed.

Specifying the prefix and mask but no label parameters removes all static bindings for that prefix or mask.

image

image

now after the reload

image

and in one LDP Neigh

image

A Networker Blog