Monday 20 January 2014

Any Transport Over MPLS (AToM)

Any Transport over MPLS (AToM) will transport layer 2 frames over a MPLS (Multiprotocol Label Switching) network. This will allow service providers to connect layer 2 networks of customers transparently by using their MPLS backbone. AToM can transport the following:
  • ATM AAL5
  • ATM Cell Relay
  • Ethernet
  • Frame Relay
  • PPP
  • HDLC
I will give you an example how to configure AToM to transport Ethernet over the MPLS backbone, we will use the following topology to do this:
MPLS Atom Ethernet
Above you see a small MPLS backbone that consists of the PE1, P and PE2 router. This ISP only has one customer that has a HQ and Branch. The customer wants to have the HQ and Branch router to be in the same layer 2 segment.

Configuration

First we will enable OSPF to advertise the loopback interfaces, these will be used as the router ID for MPLS LDP:
PE1(config)#router ospf 1
PE1(config-router)#network 192.168.12.0 0.0.0.255 area 0
PE1(config-router)#network 1.1.1.1 0.0.0.0 area 0
P(config)#router ospf 1
P(config-router)#network 192.168.12.0 0.0.0.255 area 0
P(config-router)#network 192.168.23.0 0.0.0.255 area 0
P(config-router)#network 2.2.2.2 0.0.0.0 area 0
PE2(config)#router ospf 1
PE2(config-router)#network 192.168.23.0 0.0.0.255 area 0
PE2(config-router)#network 3.3.3.3 0.0.0.0 area 0
Now we will enable MPLS LDP on the interfaces connecting the PE1, P and PE2 routers:
PE1(config)#interface fastEthernet 0/1
PE1(config-if)#mpls ip
P(config)#interface fastEthernet 0/0
P(config-if)#mpls ip

P(config)#interface fastEthernet 0/1
P(config-if)#mpls ip
PE2(config)#interface fastEthernet 0/0
PE2(config-if)#mpls ip
Just to be sure let’s verify that we have LDP neighbors:
P#show mpls ldp neighbor | include Peer
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0
That seems to be the case! Now we can configure AToM so that the HQ and Branch router are able to reach each other:
PE1(config)#interface fastEthernet 0/0
PE1(config-if)#xconnect 3.3.3.3 13 encapsulation mpls
PE2(config)#interface fastEthernet 0/1
PE2(config-if)#xconnect 1.1.1.1 13 encapsulation mpls
We need to use the xconnect command between PE1 and PE2. The VC ID (13) has to be the same on both routers.

Verification

First we will check our LDP peers:
PE1#show mpls ldp neighbor 3.3.3.3
Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 1.1.1.1:0
TCP connection: 3.3.3.3.64567 - 1.1.1.1.646
State: Oper; Msgs sent/rcvd: 15/15; Downstream
Up time: 00:05:19
LDP discovery sources:
Targeted Hello 1.1.1.1 -> 3.3.3.3, active, passive
Addresses bound to peer LDP Ident:
192.168.23.3 3.3.3.3
PE2#show mpls ldp neighbor 1.1.1.1
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0
TCP connection: 1.1.1.1.646 - 3.3.3.3.64567
State: Oper; Msgs sent/rcvd: 15/15; Downstream
Up time: 00:05:38
LDP discovery sources:
Targeted Hello 3.3.3.3 -> 1.1.1.1, active, passive
Addresses bound to peer LDP Ident:
192.168.12.1 1.1.1.1
PE1 and PE2 are LDP neighbors, now we’ll verify that they are transporting our Ethernet traffic:
PE1#show mpls l2transport binding 
Destination Address: 3.3.3.3, VC ID: 13
Local Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
PE2#show mpls l2transport binding 
Destination Address: 1.1.1.1, VC ID: 13
Local Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
A label has been assigned to this virtual circuit, you can see it says “Ethernet”. There’s another useful command that lets us check the AToM configuration:
PE1#show mpls l2transport vc 

Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Fa0/0 Ethernet 3.3.3.3 13 UP
PE2#show mpls l2transport vc

Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Fa0/1 Ethernet 1.1.1.1 13 UP
Above you have a nice overview with the interfaces, transport type, virtual circuit ID and the status. Everything is looking good to let’s give it a test drive:
HQ#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/40 ms
Our ping is successful, we can verify the number of packets that have been sent as following:
PE1#show mpls l2transport vc detail            
Local interface: Fa0/0 up, line protocol up, Ethernet up
Destination address: 3.3.3.3, VC ID: 13, VC status: up
Next hop: 192.168.12.2
Output interface: Fa0/1, imposed label stack {17 19}
Create time: 00:09:46, last status change time: 00:09:41
Signaling protocol: LDP, peer 3.3.3.3:0 up
MPLS VC labels: local 19, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 84, send 83
byte totals: receive 9445, send 9045
packet drops: receive 0, seq error 0, send 0
That’s how you configure AToM to transport Ethernet. I hope this has been useful to you, if you enjoyed this article please share it with your friends.

Cisco IOS NAT on a Stick Configuration Example

NAT (Network Address Translation) is most commonly used to let users on our LAN access the Internet using a single public IP address but it can be used for some more interesting scenarios. Recently I encountered an interesting CCIE R&S task that had the following requirement:
"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface"
This sounds easy enough but there’s no such thing as a “traceroute source loopback 0″ command or anything alike. To make this work we have to configure the NAT on a stick feature. In this tutorial I’ll show you this is done. First of all, this is the topology that we will use:
Two Routers R2 Loopback Interface
There are only two routers that are directly connected to each other. R2 has a loopback 0 interface with IP address 2.2.2.0 /24. Let’s configure these IP addresses first:

R1(config)#interface fa0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R2(config)#interface fa0/0
R2(config-if)#no shutdown
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#interface loopback0
R2(config-if)#ip address 2.2.2.2 255.255.255.0
Before we dive into the NAT configuration let’s do a trace and look at the output:
R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

1 192.168.12.2 0 msec 4 msec *
As expected R2 responds with the IP address on its FastEthernet interface. The task requires this output to show the 2.2.2.2 address from the loopback interface. To achieve this we’ll configure NAT on R2:
R2(config)#access-list 100 permit icmp any any time-exceeded
R2(config)#access-list 100 permit icmp any any port-unreachable

R2(config)#ip nat inside source list 100 interface loopback0 overload

R2(config)#interface fastethernet 0/0
R2(config-if)#ip nat inside

R2(config)#interface loopback 0
R2(config-if)#ip nat outside
The configuration above defines the FastEthernet interface as NAT inside and the loopback interface as NAT outside. An access-list is used to permit the ICMP time-exceeded and port-unreachable packets that are used as a response to a traceroute. The NAT configuration itself is complete but we still have a problem with this setup, take a look at the following picture:
Cisco Traceroute ReplyIf you look closely at the image above you can see that whenever R1 does a trace, R2 will reply with its FastEthernet 0/0 interface. In order for NAT to work traffic has to flow from the inside interface to the outside interface. To fix this we can configure policy based routing on R2 to forward traffic to the loopback 0 interface:
R2(config)#route-map FORWARD_TO_L0
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback0
R2(config)#ip local policy route-map FORWARD_TO_L0
This route-map matches on the interface that we created before and forwards the traffic towards the loopback 0 interface. We also require the ip local policy command to apply the route-map to self-generated traffic. Let’s enable a debug on R2 and try that traceroute again from R1:
R2#debug ip policy 
Policy routing debugging is on

R2#debug ip nat
IP NAT debugging is on
Time to trace!
R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

1 2.2.2.2 0 msec 4 msec *
Excellent, we now see IP address 2.2.2.2 from R2 in our traceroute. Let’s take a look at the debug on R2:
R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: local to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [17]
The first line is the ICMP packet from R2 towards R1 that it wants to send as a reply to the traceroute. It matches the route-map so it is being policy based routed towards the loopback 0 interface. Since the loopback 0 interface is configured for NAT outside, IP address 192.168.12.2 is translated to 2.2.2.2 and then routed towards R1. Basically it looks like this:
Cisco NAT on a Stick Example
Great! it’s working as it should…what if we make this scenario a little bit more interesting by changing the task as following:
"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface, you are not allowed to configure NAT on the FastEthernet interface but you may configure an additional interface and IP address."
No problem! We can still make this work but we’ll have to use another interface that is configured with the “IP NAT inside” command. Traffic still has to flow from a NAT inside interface to a NAT outside interface in order to be translated. To accomplish this we will create a new loopback interface that has the “IP NAT inside” command. We will send traffic from the FastEthernet interface to the new loopback and then forward it to the first loopback interface. I know this sounds funky so let me help you visualize it:
Cisco NAT on a Stick Two Loopback Interfaces
Just follow the arrows starting at R1.  This is what we have to configure:
  1. Configure policy based routing so that the ICMP replies are forwarded from the FastEthernet interface to the new loopback 1 (NAT inside) interface.
  2. Configure policy based routing so that the ICMP replies are forwarded from the loopback 1 interface to the loopback 0 (NAT outside) interface.
First we’ll remove the NAT configuration from the FastEthernet interface and I’ll also get rid of the policy based routing configuration:
R2(config)#interface fa0/0
R2(config-if)#no ip nat inside
R2(config)#no ip local policy route-map FORWARD_TO_L0
Let’s create a new loopback interface. I just made up an IP address, it really doesn’t matter what we configure here as long as there’s something. Don’t forget to add IP NAT inside:
R2(config)#interface loopback 1
R2(config-if)#ip address 22.22.22.22 255.255.255.0
R2(config-if)#ip nat inside
We will create a new route-map that forwards ICMP traffic to the loopback 1 interface:
R2(config)#ip local policy route-map FORWARD_TO_L1
R2(config)#route-map FORWARD_TO_L1
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback 1
The route-map that we created before can now be applied to the loopback 1 interface. This ensures that traffic is forwarded to the loopback 0 interface:
R2(config)#interface loopback1
R2(config-if)#ip policy route-map FORWARD_TO_L0
That should do it. Let’s try our trace again:
R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

1 2.2.2.2 4 msec 4 msec *
Excellent, it’s working! What does the debug look like now?
R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L1, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback1), len 56, policy routed
IP: local to Loopback1 192.168.12.1
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: Loopback1 to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [21]
Look closely at the debug and you can see that the ICMP traffic is forwarded to the loopback 1 interface, then to the loopback 0 interface and because it flowed from a NAT inside to a NAT outside interface it can now be translated.
That’s all I have for you now, hopefully you enjoyed this tutorial! If you have any questions feel free to leave a comment.


Read more: http://networklessons.com/network-services/cisco-ios-nat-stick-configuration-example/#ixzz2r0GlbUxU

Site-to-Site IPSEC VPN Between Two Cisco ASA – one with Dynamic IP

isco ASA 5500 Series appliances deliver IPsec and SSL VPN, firewall, and several other networking services on a single platform. Cisco ASA 5520, a member of the Cisco ASA 5500 Series, is shown in Figure 1 below.
asa5520 picture
Figure 1 Cisco Adaptive Security Appliance (ASA)

In this article, we will focus on site-to-site IPsec implementation between two Cisco ASA 5520 appliances, as shown in Figure 2. The outside interface of ASA1 is assigned a dynamic IP addressby the service provider over DHCP, while the outside interface of ASA2 is configured with astatic IP address. Basic IP address configuration and connectivity exists and we will build IPsec configuration on top of this. Although this tutorial was tested on ASA5520, the configuration commands are exactly the same for the other ASA models with no difference.
cisco asa site to site ipsec vpn
Figure 2  Cisco ASA-ASA IPsec Implementation
IP Security (IPsec) can use Internet Key Exchange (IKE) for key management and tunnel negotiation. IKE involves a combination of ISAKMP/Phase 1 and IPsec/Phase 2 attributes that are negotiated between peers. If any one of the attributes is misconfigured, the IPsec tunnel fails to establish. Therefore, it is mandatory to make sure that all these parameters are identical on the two appliances we are using as IPsec peers.
We will start with a preconfiguration checklist to make our life easier. This checklist would serve as a reference for configuration and troubleshooting.
Table 1   Configuration Checklist: ISAKMP/Phase-1 Attributes
AttributeValue
EncryptionAES 128-bit
HashingSHA-1
Authentication methodPreshared keys
DH groupGroup 2 1024-bit field
Lifetime86,400 seconds
After discussing Phase 1 attributes, it is important to highlight Phase 2 attributes of the IPsec VPN connection, that are used to encrypt and decrypt the actual data traffic.
Table 2   Configuration Checklist: IPsec/Phase-2 Attributes
AttributeValue
EncryptionAES 128-bit
HashingSHA-1
Lifetime28,800 seconds4,608,000 kB
ModeTunnel
PFS groupNone
Now that we have determined what Phase 1 and Phase 2 attributes to use, we’re ready to configure the site-to-site IPsec tunnel between ASA1 and ASA2.
Let’s start with configuring ASA1:
! ISAKMP Phase 1
crypto ikev1 policy 10
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400

!
crypto ikev1 enable outside
tunnel-group 173.199.183.2 type ipsec-l2l
tunnel-group 173.199.183.2 ipsec-attributes
ikev1 pre-shared-key Cisc0
! IPsec Phase 2
access-list RED permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0
crypto ipsec ikev1 transform-set ESP-AES128-SHA esp-aes esp-sha-hmac
crypto map VPN-MAP 10 match address RED
crypto map VPN-MAP 10 set peer 173.199.183.2
crypto map VPN-MAP 10 set ikev1 transform-set ESP-AES128-SHA
crypto map VPN-MAP interface outside
Here goes the configuration for ASA2:
! Create ISAKMP policy
crypto ikev1 policy 10
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
crypto ikev1 enable outside
! Define the pre-shared key within the dynamic map tunnel group
tunnel-group DefaultL2LGroup ipsec-attributes
ikev1 pre-shared-key Cisc0
!
crypto ipsec ikev1 transform-set ESP-AES128-SHA esp-aes esp-sha-hmac
access-list BLUE permit ip 10.0.0.0 255.255.255.0 192.168.1.0 255.255.255.0
! Create a dynamic-map
crypto dynamic-map DYN-MAP 20 match address BLUE (OPTIONAL)
crypto dynamic-map DYN-MAP 20 set ikev1 transform-set ESP-AES128-SHA
! Assign the dynamic-map to crypto map
crypto map VPN-MAP 10 ipsec-isakmp dynamic DYN-MAP
crypto map VPN-MAP interface outside
The above commands conclude the IPSEC VPN configuration. However, if we have NAT in our network (which is true most of the times), we still have some way to go. We must configure NAT exemption for VPN traffic. That is, traffic that will pass through the VPN tunnel (i.e traffic between the LAN networks 192.168.1.0/24 10.0.0.0/24) must be excluded from NAT operation.
Configure NAT Exemption on ASA1
ASA1(config)# object network obj-local 
ASA1(config-network-object)# subnet 192.168.1.0 255.255.255.0 
ASA1(config-network-object)# exit
ASA1(config)# object network obj-remote 
ASA1(config-network-object)# subnet 10.0.0.0 255.255.255.0
ASA1(config-network-object)# exit
ASA1(config)# object network internal-lan 
ASA1(config-network-object)# subnet 192.168.1.0 255.255.255.0 
ASA1(config-network-object)# exit
! Exclude traffic from LAN1 to LAN2 from NAT operation
ASA1(config)# nat (inside,outside) source static obj-local obj-local destination static obj-remote obj-remote
! Configure Port Address Translation (PAT) using the outside ASA interface. This will perform dynamic NAT on internal LAN hosts so that they can access the Internet.
ASA1(config)# object network internal-lan 
ASA1(config-network-object)# nat (inside,outside) dynamic interface
Configure NAT Exemption on ASA2
ASA2(config)# object network obj-local 
ASA2(config-network-object)# subnet 10.0.0.0 255.255.255.0 
ASA2(config-network-object)# exit
ASA2(config)# object network obj-remote 
ASA2(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA2(config-network-object)# exit
ASA2(config)# object network internal-lan 
ASA2(config-network-object)# subnet 10.0.0.0 255.255.255.0 
ASA2(config-network-object)# exit
! Exclude traffic from LAN2 to LAN1 from NAT operation
ASA2(config)# nat (inside,outside) source static obj-local obj-local destination static obj-remote obj-remote
! Configure Port Address Translation (PAT) using the outside ASA interface. This will perform dynamic NAT on internal LAN hosts so that they can access the Internet.
ASA2(config)# object network internal-lan 
ASA2(config-network-object)# nat (inside,outside) dynamic interface
At this point our IPsec configuration is complete. We can generate some traffic from a host in subnet 192.168.1.0/24 connected to ASA1 to a host in subnet 10.0.0.0/24 connected to ASA2. An easy way to generate such traffic is the good old ping utility. If ping is successful between the two subnets, an IPsec tunnel is also likely to have established successfully. The same can be verified using command show crypto ipsec stats:
ASA1# show crypto ipsec stats
IPsec Global Statistics
———————–
Active tunnels: 1
Previous tunnels: 1
Inbound
Bytes: 400
Decompressed bytes: 400
Packets: 4
Dropped packets: 0
Replay failures: 0
Authentications: 4
Authentication failures: 0
Decryptions: 4
Decryption failures: 0
Decapsulated fragments needing reassembly: 0
Outbound
Bytes: 400
Uncompressed bytes: 400
Packets: 4
Dropped packets: 0
Authentications: 4
Authentication failures: 0
Encryptions: 4
Encryption failures: 0
Fragmentation successes: 0
Pre-fragmentation successses: 0
Post-fragmentation successes: 0
Fragmentation failures: 0
Pre-fragmentation failures: 0
Post-fragmentation failures: 0
Fragments created: 0
PMTUs sent: 0
PMTUs rcvd: 0
Protocol failures: 0
Missing SA failures: 0
System capacity failures: 0
You can get your hands dirty with several other show crypto commands available to verify configuration and view statistics. For example, show crypto isakmp sa detail command can be used to verify ISAKMP/Phase 1 attributes, while show crypto ipsec sa command can be used to verify IPsec/Phase 2 attributes. We have shown here the output for show crypto isakmp sa detailcommand:
ASA1# show crypto isakmp sa detail
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1   IKE Peer: 173.199.183.2
Type    : L2L             Role    : initiator
Rekey   : no              State   : MM_ACTIVE
Encrypt : aes             Hash    : SHA
Auth    : preshared       Lifetime: 86400
Lifetime Remaining: 85998