Archive

Archive for the ‘Service Provider’ Category

Interconnecting Ethernet and Frame-Relay interfaces Using MPLS L2VPN Interworking

June 5, 2012 Leave a comment

One of the MPLS L2VPN or Any Transport over MPLS (AToM) feature is “interworking”, that used to interconnect two different type of interfaces encapsulation.

In this example, we will try to interconnect the customer ethernet interface at one site to the customer frame-relay interface at another site.

The Service Provider core which are consist of PE-2, P-1, P-2 and PE-2 router, are using IGP and MPLS with LDP to distribute labels.

Configuring the customers interface

On customer router CE-1, we are using ethernet interface

interface Ethernet0/2
 ip address 10.0.0.1 255.255.255.0
 !

On customer router CE-2, we are using Serial interface and applying frame-relay encapsulation with DLCI 100.

interface Serial2/0
 no ip address
 encapsulation frame-relay
!
interface Serial2/0.100 point-to-point
 ip address 10.0.0.20 255.255.255.0
  frame-relay interface-dlci 100
!

Configuring AToM Pseudowire at the PE Routers

We are assuming that the Service Provider Core networks already running IGP and MPLS with LDP. In this example we are using OSPF. The important thing is we must have any of the PE Routers Loopback IP address on the routing table and the MPLS label that associated to its.

PE-1#sh ip route 19.19.19.19
Routing entry for 19.19.19.19/32
  Known via “ospf 100“, distance 110, metric 31, type intra area
  Last update from 20.2.4.4 on Ethernet0/0.24, 04:55:09 ago
  Routing Descriptor Blocks:
  * 20.2.3.3, from 19.19.19.19, 04:55:09 ago, via Ethernet0/0.23
      Route metric is 31, traffic share count is 1

PE-1#sh mpls forwarding-table 19.19.19.19
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
2002       3003       19.19.19.19/32   0             Et0/0.23   20.2.3.3

PE-2#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via “ospf 100“, distance 110, metric 31, type intra area
  Last update from 20.5.19.5 on Ethernet0/0.519, 04:56:01 ago
  Routing Descriptor Blocks:
  * 20.6.19.6, from 2.2.2.2, 04:56:01 ago, via Ethernet0/0.619
      Route metric is 31, traffic share count is 1

PE-2#sh mpls forwarding2.2.2.2
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19008    6013       2.2.2.2/32       0             Et0/0.619  20.6.19.6

In PE-1, we create the pseudowire-class that will used for the customer L2VPN.  The difference from the ordinary AToM pseudowire, is this pseudowire enabling the interworking feature, to connect the different interface type.

pseudowire-class ETH_TO_FR
 encapsulation mpls
 interworking ip
!

Then the pseudowire-class applied to the ethernet interface (Ethernet 0/2) that facing to the customer router (CE-1) and associated to the PE-2 loopback address.

interface Ethernet0/2
 no ip address
 no cdp enable
 xconnect 19.19.19.19 14 pw-class ETH_TO_FR
!

In this example, we are using VC ID number 14.

In the PE-2 router, we do the same thing.

pseudowire-class FR_TO_ETH
 encapsulation mpls
 interworking ip
!

The pseudowire-class then applied to the serial interface (Serial 2/0) that facing to the customer router (CE-2) and associated to the PE-1 loopback address. In this example, we are using DLCI 100.

interface Serial2/0
 no ip address
 encapsulation frame-relay
 frame-relay intf-type dce
!

connect FR_TO_ETH_CONN Serial2/0 100 l2transport
 xconnect 2.2.2.2 14 pw-class FR_TO_ETH
 !
!

Now we verify on the PE-1 wether the AToM pseudowire for the customer has created or not.

PE-1#sh mpls l2transport vc 14 detail | i (up|LDP|label)
Local interface: Et0/2 up, line protocol up, Ethernet up
  Destination address: 19.19.19.19, VC ID: 14, VC status: up
    Output interface: Et0/0.23, imposed label stack {3003 19014}
  Signaling protocol: LDP, peer 19.19.19.19:0 up
    Targeted Hello: 2.2.2.2(LDP Id) -> 19.19.19.19
    Status TLV support (local/remote)   : enabled/supported
      Last local  LDP TLV    status sent: no fault
      Last remote LDP TLV    status rcvd: no fault
    MPLS VC labels: local 2014, remote 19014
    Group ID: local 0, remote 0

We see that the AToM pseudowire for the customer  has created and the VC (Virtual Circuit) status is Up.  Label 2014 is allocated for the pseudowire.

PE-1#sh mpls forwarding-table labels 2014
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
2014       No Label   l2ckt(14)        57176         Et0/2      point2point

Label 3003 that allocated by P-1,  is the transport label to go to the PE-2 loopback IP Address.

PE-1#sh mpls forwarding-table | i (3003|Outgoing)
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
2002       3003       19.19.19.19/32   0             Et0/0.23   20.2.3.3

In the P-1 router, the transport label 3003 will be swapped to the label 6004 to go the PE-2 loopback IP address.

P-1#sh mpls forwarding-table labels 3003
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
3003       6004       19.19.19.19/32   228000        Et0/0.36   20.3.6.6

And in the P-2 router, the transport label 6004 will be detached and forwarded to the PE-2 router.

P-2#sh mpls forwarding-table labels 6004
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel
Id     Switched      interface

6004       Pop Label  19.19.19.19/32   851677        Et0/0.619  20.6.19.19

Now we verify the AToM pseudowire on the PE-2.

PE-2#show mpls l2transport vc 14 detail | i (up|LDP|label)
Local interface: Se2/0 up, line protocol up, FR DLCI 100 up
  Destination address: 2.2.2.2, VC ID: 14, VC status: up
    Output interface: Et0/0.519, imposed label stack {5013 2014}
  Signaling protocol: LDP, peer 2.2.2.2:0 up
    Targeted Hello: 19.19.19.19(LDP Id) -> 2.2.2.2
    Status TLV support (local/remote)   : enabled/supported
      Last local  LDP TLV    status sent: no fault
      Last remote LDP TLV    status rcvd: no fault
    MPLS VC labels: local 19014, remote 2014
    Group ID: local 0, remote 0

The AToM pseudowire has created and the VC status is up too.  Label 19014 is allocated by PE-2 for the pseudowire. Label 5013 is the transport label that allocated by P-2 to go the VC ID 14 egress router (that is PE-1) loopback IP Address.

PE-2#sh mpls forwarding-table labels 19014
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19014      No Label   l2ckt(14)        77876         Se2/0      point2point
PE-2#sh mpls forwarding-table | i (Outgoing|5013)
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
19008      5013       2.2.2.2/32       0             Et0/0.519  20.5.19.5

We see that the AToM pseudowire for both PE routers have been created and the Virtual Circuit status is up.

Verifying the AToM Interworking

CE-1#ping 10.0.0.20  repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.20, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 28/28/28 ms
CE-1#

CE-2#debug ip icmp
ICMP packet debugging is on
CE-2#
*Jun  6 04:25:43.491: ICMP: echo reply sent, src 10.0.0.20, dst 10.0.0.1, topology BASE, dscp 0 topoid 0
CE-2#

We see that the icmp echo packet that send from CE-1 was received by CE-2. Then router CE-2 send the ICMP echo reply packet to the CE-1.

Mitigating Source Specific DoS Attack Using Remotely Triggered BlackHole

January 28, 2011 Leave a comment

Remotely Triggered Black Hole method usualy used to dealing with the DDoS Attack that have specific destination. When we combine it with the Unicast Reverse Path Forwarding (RPF) feature, we can drop every DoS attack based on the source IP.

Here are the lab scenario to simulate that method (we are using Cisco routers):

To simulate the attacker, we are using loopback interface on router INET. INET has 2 connection to the AS 65000 (The Service Provider). In this scenario, we are prefering GW1 as the primary path for outgoing traffic to the Service Provider Network. Here are the relevant configuration from INET:

hostname INET
!
interface Loopback0
ip address 100.100.1.1 255.255.255.0
no ip directed-broadcast
!
interface Loopback1
ip address 200.200.1.1 255.255.255.0
no ip directed-broadcast
!
interface FastEthernet1/0
ip address 172.16.0.1 255.255.255.0
no ip directed-broadcast
duplex full
speed 100
!
interface FastEthernet1/1
ip address 172.16.1.1 255.255.255.0
no ip directed-broadcast
duplex full
speed 100
!
router bgp 65002
no synchronization
bgp log-neighbor-changes
network 100.100.1.0 mask 255.255.255.0
network 200.200.1.0
neighbor 172.16.0.2 remote-as 65000
neighbor 172.16.0.2 weight 65535
neighbor 172.16.1.2 remote-as 65000
neighbor 172.16.1.2 weight 32768
no auto-summary

For the Service Provider network, we are using 4 router, they are GW1, GW2, RR and PE-1. RR act as Route-Reflector for all the rest routers and as the trigger router. They use OSPF for IGP and BGP AS 65000. We are using BGP too to triggered router GW1 and GW2 to blackholing the attacker traffic.

Here are the relevant configuration for all of Service Provider routers:

hostname GW1
!
ip cef
!
interface Loopback0
ip address 1.1.1.2 255.255.255.255
!
interface FastEthernet1/0
ip address 172.16.0.2 255.255.255.0
!
interface FastEthernet1/1
ip address 10.1.1.2 255.255.255.0
ip ospf priority 0
!
router ospf 1
router-id 1.1.1.2
log-adjacency-changes
network 1.1.1.2 0.0.0.0 area 0
network 10.1.1.2 0.0.0.0 area 0
!
router bgp 65000
no synchronization
bgp router-id 1.1.1.2
bgp log-neighbor-changes
redistribute connected route-map TO-INET
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
neighbor 172.16.0.1 remote-as 65002
no auto-summary
!
access-list 1 permit 172.16.0.0
!
route-map TO-INET permit 10
match ip address 1

hostname GW2
ip cef
interface Loopback0
ip address 1.1.1.3 255.255.255.255
!
interface FastEthernet1/0
ip address 172.16.1.2 255.255.255.0
!
interface FastEthernet1/1
ip address 10.1.1.3 255.255.255.0
ip ospf priority 50
!
router ospf 1
router-id 1.1.1.3
log-adjacency-changes
network 1.1.1.3 0.0.0.0 area 0
network 10.1.1.3 0.0.0.0 area 0
!
router bgp 65000
no synchronization
bgp router-id 1.1.1.3
bgp log-neighbor-changes
redistribute connected route-map INET-EDGE
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
neighbor 172.16.1.1 remote-as 65002
no auto-summary
!
access-list 1 permit 172.16.1.0
!
route-map INET-EDGE permit 10
match ip address 1

hostname PE-1
!
interface Loopback0
ip address 1.1.1.4 255.255.255.255
!
interface FastEthernet1/0
ip address 10.1.1.4 255.255.255.0
ip ospf priority 0
!
interface FastEthernet1/1
ip address 192.168.0.2 255.255.255.0
!
router ospf 1
router-id 1.1.1.4
log-adjacency-changes
network 1.1.1.4 0.0.0.0 area 0
network 10.1.1.4 0.0.0.0 area 0
!
router bgp 65000
no synchronization
bgp router-id 1.1.1.4
bgp log-neighbor-changes
redistribute connected route-map TO-CE1
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
neighbor 192.168.0.1 remote-as 65001
neighbor 192.168.0.1 default-originate
no auto-summary
!
access-list 1 permit 192.168.0.0
route-map TO-CE1 permit 10
match ip address 1

hostname RR
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet1/0
ip address 10.1.1.1 255.255.255.0
ip ospf priority 100
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.1.1.1 0.0.0.0 area 0
!
router bgp 65000
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 1.1.1.2 remote-as 65000
neighbor 1.1.1.2 update-source Loopback0
neighbor 1.1.1.2 route-reflector-client
neighbor 1.1.1.2 send-community both
neighbor 1.1.1.3 remote-as 65000
neighbor 1.1.1.3 update-source Loopback0
neighbor 1.1.1.3 route-reflector-client
neighbor 1.1.1.3 send-community both
neighbor 1.1.1.4 remote-as 65000
neighbor 1.1.1.4 update-source Loopback0
neighbor 1.1.1.4 route-reflector-client
neighbor 1.1.1.4 send-community both
no auto-summary

And to simulate the Victim Network, we are using loopback interface on CE-1. Here are it relevant configuration:

hostname CE-1
!
interface Loopback0
ip address 9.9.9.9 255.255.255.0
!
interface Loopback1
ip address 8.8.8.8 255.255.255.0
!
interface FastEthernet1/0
ip address 192.168.0.1 255.255.255.0
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 8.8.8.0 mask 255.255.255.0
network 9.9.9.0 mask 255.255.255.0
neighbor 192.168.0.2 remote-as 65000
no auto-summary

In our scenario, host 100.100.1.1/32 is the DoS source.

After all BGP speaker in the Service Provider network have form adjancency, now on the GW1 and GW2 we create the IP next-hop for every DoS source, so we can manipulate it and forward it to dropped at Null interface. Usualy we use the non-allocated IP Address, for example 192.0.2.0/24 (Test-Net).

GW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
GW1(config)#ip route 192.0.2.1 255.255.255.255 Null0 tag 101
GW1(config)#route-map TEST-NET permit 10
GW1(config-route-map)#match tag 101
GW1(config-route-map)#set community no-export
GW1(config-route-map)#router bgp 65000
GW1(config-router)#redistribute static route-map TEST-NET
GW1(config-router)#^Z

GW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
GW2(config)#ip route 192.0.2.1 255.255.255.255 Null0 tag 101
GW2(config)#route-map TEST-NET permit 10
GW2(config-route-map)#match tag 101
GW2(config-route-map)#set community no-export
GW2(config-route-map)#router bgp 65000
GW2(config-router)#redistribute static route-map TEST-NET
GW2(config-router)#^Z


RR#sh ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 37
Paths: (2 available, best #1, not advertised to EBGP peer)
Flag: 0x880
Advertised to update-groups:
1
Local, (Received from a RR-client)
1.1.1.2 (metric 2) from 1.1.1.2 (1.1.1.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Community: no-export
Local, (Received from a RR-client)
1.1.1.3 (metric 2) from 1.1.1.3 (1.1.1.3)
Origin incomplete, metric 0, localpref 100, valid, internal
Community: no-export

Note that we attached community no-export to the 192.0.2.1/32 route, in order to prevent the Service Provider routers advertise it to neighbor AS.

After that, still in GW1 and GW2, we add Unicast RPF feature in the edge interfaces. In this scenario, we use “ip verify unicast source reachable-via any” command, in order to detect the incoming traffic based on the source Address, and because we have 2 gateway router (so the incoming and outgoing traffic can be assymetric or not must using the same edge interface).

GW1(config)#int f1/0
GW1(config-if)#ip verify unicast source reachable-via any
GW1(config-if)#^Z

GW1(config)#int f1/0
GW1(config-if)#ip verify unicast source reachable-via any
GW1(config-if)#^Z

Now, we prepare the blackhole trigger configuration at RR. We must add community no-export to for the manipulated route.

RR#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RR(config)#route-map TRIGGER permit 10
RR(config-route-map)#match tag 99
RR(config-route-map)#set community no-export
RR(config-route-map)#set ip next-hop 192.0.2.1
RR(config-route-map)#router bgp 65000
RR(config-router)#redistribute static route-map TRIGGER
RR(config-router)#^Z

Note that we are using 192.0.2.1/32 as the ip next-hop of the DoS source.

Now, lets we try to send the packets to the host 9.9.9.9 from host 100.100.1.1.

INET#ping
Protocol [ip]:
Target IP address: 9.9.9.9
Repeat count [5]: 10000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 100.100.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

GW1#sh ip bgp
BGP table version is 27, local router ID is 1.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i8.8.8.0/24 192.168.0.1 0 100 0 65001 i
*>i9.9.9.0/24 192.168.0.1 0 100 0 65001 i
*> 100.100.1.0/24 172.16.0.1 0 0 65002 i
*> 172.16.0.0/24 0.0.0.0 0 32768 ?
*>i172.16.1.0/24 1.1.1.3 0 100 0 ?
*> 192.0.2.1/32 0.0.0.0 0 32768 ?
*>i192.168.0.0 1.1.1.4 0 100 0 ?
*> 200.200.1.0 172.16.0.1 0 0 65002 i

GW1#sh ip bgp 100.100.1.1
BGP routing table entry for 100.100.1.0/24, version 17
Paths: (1 available, best #1)
Advertised to update-groups:
2
65002
172.16.0.1 from 172.16.0.1 (200.200.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
GW1#
GW1#sh ip route 100.100.1.1
Routing entry for 100.100.1.0/24
Known via “bgp 65000”, distance 20, metric 0
Tag 65002, type external
Last update from 172.16.0.1 04:16:53 ago
Routing Descriptor Blocks:
* 172.16.0.1, from 172.16.0.1, 04:16:53 ago
Route metric is 0, traffic share count is 1
AS Hops 1, BGP network version 0
Route tag 65002
GW1#debug ip packet 123
IP packet debugging is on for access list 123
01:13:34: IP: tableid=0, s=100.100.1.1 (FastEthernet1/0), d=9.9.9.9 (FastEtherne
t1/1), routed via FIB
01:13:34: IP: s=100.100.1.1 (FastEthernet1/0), d=9.9.9.9 (FastEthernet1/1), g=10
.1.1.4, len 100, forward

Now, let we assume that host 100.100.1.1 has send the DoS attack to the whatever host at the AS-65000 customer network. So, we want to drop every traffic that coming from host 100.100.1.1.

In RR (that act as a Black Hole Trigger router), we add the static IP route for 100.100.1.1/32 using tag 99, then RR will send the route via BGP with IP next-hop 192.0.2.1/32 that reside in the router GW1 and GW2.

RR#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RR(config)#ip route 100.100.1.1 255.255.255.255 null0 tag 99
RR(config)#^Z
RR#

GW1#sh ip bgp
BGP table version is 26, local router ID is 1.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
*>i8.8.8.0/24 192.168.0.1 0 100 0 65001 i
*>i9.9.9.0/24 192.168.0.1 0 100 0 65001 i
*> 100.100.1.0/24 172.16.0.1 0 0 65002 i
*>i100.100.1.1/32 192.0.2.1 0 100 0 ?
*> 172.16.0.0/24 0.0.0.0 0 32768 ?
*>i172.16.1.0/24 1.1.1.3 0 100 0 ?
*> 192.0.2.1/32 0.0.0.0 0 32768 ?
*>i192.168.0.0 1.1.1.4 0 100 0 ?
*> 200.200.1.0 172.16.0.1 0 0 65002 i
GW1#
GW1#sh ip bgp 100.100.1.1
BGP routing table entry for 100.100.1.1/32, version 33
Paths: (1 available, best #1, not advertised to EBGP peer)
Not advertised to any peer
Local
192.0.2.1 from 1.1.1.1 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Community: no-export
GW1#sh ip route 100.100.1.1
Routing entry for 100.100.1.1/32
Known via “bgp 65000”, distance 200, metric 0, type internal
Last update from 192.0.2.1 03:09:15 ago
Routing Descriptor Blocks:
* 192.0.2.1, from 1.1.1.1, 03:09:15 ago
Route metric is 0, traffic share count is 1
AS Hops 0, BGP network version 0

GW1#sh ip route 192.0.2.1
Routing entry for 192.0.2.1/32
Known via “static”, distance 1, metric 0 (connected)
Tag 101
Redistributing via bgp 65000
Advertised by bgp 65000 route-map TEST-NET
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
Route tag 101

INET#ping
Protocol [ip]:
Target IP address: 9.9.9.9
Repeat count [5]: 10000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 100.100.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
…………

GW1#debug ip packet 123
IP packet debugging is on for access list 123
GW1#
01:09:09: IP: s=100.100.1.1 (FastEthernet1/0), d=9.9.9.9, len 100, unicast rpf failed
01:09:11: IP: s=100.100.1.1 (FastEthernet1/0), d=9.9.9.9, len 100, unicast rpf failed

In the gateway router (in this case is GW1 because it is prefered by INET router), the incoming source ip packet is checked by Unicast RPF feature. It is check the reverse path/route to the source IP (in this case is 100.100.1.1/32) in the routing table. Because in the routing table the next-hop of the 100.100.1.1/32 is null0 interface, then the packet is dropped.

So, after the Blackhole route triggered, the DoS traffic is dropped in the gateway router before reach the customer. It is more effective than using Access-List method that more CPU extensive.

Securing MP-EBGP VPNv4 for Inter-AS MPLS VPN

February 21, 2009 4 comments

1. Securing Inter-AS interfaces

  • Permit only BGP traffic because the other traffic that traverse between ASBRs is IP Labelled traffic.
  • Apply inbound and outbound. Logging the denied traffic for further investigation

interface FastEthernet0/0
ip address 172.16.0.2 255.255.255.252
ip access-group ASBR-IN in
ip access-group ASBR-OUT out
!
ip access-list extended ASBR-IN
permit tcp any any eq bgp
permit tcp any eq bgp any
deny ip any any log
!
ip access-list extended ASBR-OUT
permit tcp any eq bgp any
permit tcp any any eq bgp
deny ip any any log
!

  • See the example of IPv4 and IP Labelled traffic that traverse beetwen ASBR routers below. Note that IPv4 is only BGP communication, and the remaining traffic is telnet or icmp traffic that has been labelled.

interas-mpls-ethereal

2. Securing MP-EBGP Peering Session

  • Use BGP MD5 Authentication to ensure that the BGP peer is the legitimate neighbor.

neighbor 172.16.0.1 password 7 011A08105E19071C

  • Use BGP TTL-Security with number of hop is 1. The BGP peering session between ASBRs usually using the back-to-back interface.

neighbor 172.16.0.1 ttl-security hops 1

  • Both ASBR did not communicating ini IPv4 (except BGP communication), so we must turn-off the IPv4 BGP Address-family

no bgp default ipv4-unicast

  • Use BGP Dampening to secure the ASBR CPU from frequently flapped routes

bgp dampening

  • Filter the Route-Target. Only allows Route-Target that need to extend across the AS. Disable BGP default RT filter to allow VPNv4 routes installed in the BGP VPNv4 table even the Route-Target is not configured on the ASBR.

Router BGP 100
no bgp default route-target filter
!
address-family vpnv4
neighbor 172.16.0.2 route-map ASBR in
exit address-family
!
route-map ASBR permit 10
match extcommunity 101
!
ip extcommunity-list 101 permit RT:200:123+
ip extcommunity-list 101 permit RT:200:222+

  • Set the BGP maximum-prefix filter.

neighbor 172.16.0.2 maximum-prefix 100 80

3. General Router Security

  • AAA Authentication
  • SSH Access for Management
  • Access-Class for Line VTY access
  • Read-Only SNMP with ACL
  • using NTP and disabling ntp on not appropriate interfaces
  • Enable CoPP if necessary
  • Specific and strict ACL for inter-AS interface
  • Enable Security Services
  1. Service Password-Encryption
  2. Service Timestamp for Debug and Logging
  3. Logging buffered
  • Disable small Services
  1. Disable udp-small-services (echo, discard)
  2. Disable tcp-small-service
  3. Disable finger-service
  4. Disable pad-service
  5. Disable unused bootp service
  6. Disable cdp
  7. Disable icmp unreachables on all interfaces including null0
  8. Disable ip source-route options
  9. Disable proxy-arp per interfaces
  10. Disable directed-broadcast per interfaces
  11. Disable icmp mask-reply per interfaces
  12. Disable http-service
  13. Disable ident-service

Inter-AS MPLS VPN using MP-EBGP VPNv4

February 16, 2009 3 comments

There are a requirement from one company, who want to connect their sites that connected to the different ISP MPLS VPN. To fulfill the requirement, the two ISPs need to interconnect their MPLS Autonomous Systems. For this purpose, we can use a few method below:

  • Back to back VRF
  • VPNv4 MP-EBGP
  • VPNv4 MP-EBGP between RR

The easy method and less security impact, is back to back VRF connection, but it is not scalable. The VPNv4 MP-EBGP without or with RR as ASBR, is more scalable, but need deeply security concern.

In this article, we will not discuss about how to secure the inter-AS MPLS connection (i hope i will cover it in the next article). We just highlight the mandatory configuration between the two ASBRs to provide the inter-AS MPLS connection.

Here are the connection diagram:

interas-mpls

Here are the important configuration on the PE-ABC-1 and PE-XYZ-1 for the interface and VRF.  For example we use vrf  Company. We don’t use CE routers, instead just loopback interfaces at the PEs acting like the interface that facing to the CE router:

hostname PE-ABC-1
!
ip cef
ip vrf Company
rd 100:111
route-target export 100:111
route-target import 100:111
route-target import 200:222
!
!
interface Loopback0
ip address 10.10.127.1 255.255.255.255
no ip directed-broadcast
!
interface Loopback111
ip vrf forwarding Company
ip address 10.10.111.1 255.255.255.255
no ip directed-broadcast
!
interface FastEthernet1/1
ip address 10.10.12.1 255.255.255.0
no ip directed-broadcast
duplex half
speed auto
mpls label protocol ldp
tag-switching ip
!
router bgp 100
no synchronization
bgp router-id 10.10.127.1
bgp log-neighbor-changes
neighbor 10.10.127.3 remote-as 100
neighbor 10.10.127.3 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.10.127.3 activate
neighbor 10.10.127.3 send-community both
exit-address-family
!
address-family ipv4 vrf Company
redistribute connected
no synchronization
exit-address-family
!

hostname PE-XYZ-1
ip cef
ip vrf Company
rd 200:222
route-target export 200:222
route-target import 200:222
route-target import 100:111
!
interface Loopback0
ip address 100.100.127.3 255.255.255.255
no ip directed-broadcast
!
interface Loopback222
ip vrf forwarding Company
ip address 10.10.222.1 255.255.255.255
no ip directed-broadcast
!
interface FastEthernet1/0
ip address 100.100.23.3 255.255.255.0
no ip directed-broadcast
duplex half
speed auto
mpls label protocol ldp
tag-switching ip
!
router bgp 200
no synchronization
bgp router-id 100.100.127.3
bgp log-neighbor-changes
neighbor 100.100.127.1 remote-as 200
neighbor 100.100.127.1 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 100.100.127.1 activate
neighbor 100.100.127.1 send-community extended
exit-address-family
!
address-family ipv4 vrf Company
redistribute connected
no synchronization
exit-address-family
!

And here are the important configuration for the two PE-ASBR for MP-EBGP VPNv4 connection:

hostname PE-ABC-ASBR
!

ip cef
interface Loopback0
ip address 10.10.127.3 255.255.255.255
no ip directed-broadcast
!
interface FastEthernet1/0
ip address 10.10.23.3 255.255.255.0
no ip directed-broadcast
duplex half
speed auto
mpls label protocol ldp
tag-switching ip
!
interface FastEthernet1/1
ip address 172.16.0.1 255.255.255.252
no ip directed-broadcast
!
router bgp 100
no synchronization
bgp router-id 10.10.127.3
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 10.10.127.1 remote-as 100
neighbor 10.10.127.1 update-source Loopback0
neighbor 172.16.0.2 remote-as 200
no auto-summary
!
address-family vpnv4
neighbor 10.10.127.1 activate
neighbor 10.10.127.1 send-community extended
neighbor 10.10.127.1 next-hop-self
neighbor 172.16.0.2 activate
neighbor 172.16.0.2 send-community extended
exit-address-family
!

hostname PE-XYZ-ASBR
ip cef
!
interface Loopback0
ip address 100.100.127.1 255.255.255.255
!
interface FastEthernet0/0
ip address 172.16.0.2 255.255.255.252
!
interface FastEthernet1/0
ip address 100.100.12.1 255.255.255.0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
router bgp 200
no synchronization
bgp router-id 100.100.127.1
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 100.100.127.3 remote-as 200
neighbor 100.100.127.3 update-source Loopback0
neighbor 172.16.0.1 remote-as 100
no auto-summary
!
address-family vpnv4
neighbor 100.100.127.3 activate
neighbor 100.100.127.3 send-community extended
neighbor 100.100.127.3 next-hop-self
neighbor 172.16.0.1 activate
neighbor 172.16.0.1 send-community extended
exit-address-family
!

Note that because we don’t configure the vrf, rd and the route-target in the two PE-ASBRs, we need to turn off the BGP route-target filter, so we can receive the vpnv4 routes. We use “no bgp default route-target filter” command.

Verify the vpnv4 bgp connection and routes on PE-ASBRs:

PE-XYZ-ASBR#sh ip bgp vpnv4 all summary
BGP router identifier 100.100.127.1, local AS number 200
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.100.127.3   4   200      35      36       11    0    0 00:26:38        1
172.16.0.1      4   100      81      81       11    0    0 00:07:25        1

PE-XYZ-ASBR#sh ip bgp vpnv4 all
BGP table version is 11, local router ID is 100.100.127.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:111
*> 10.10.111.1/32   172.16.0.1                             0 100 ?
Route Distinguisher: 200:222
*>i10.10.222.1/32   100.100.127.3            0    100      0 ?

PE-ABC-ASBR#sh ip bgp vpnv4 all summary
BGP router identifier 10.10.127.3, local AS number 100
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.127.1     4   100      83      83        7    0    0 00:08:27        1
172.16.0.2      4   200      82      82        7    0    0 00:08:24        1

PE-ABC-ASBR#sh ip bgp vpnv4 all
BGP table version is 7, local router ID is 10.10.127.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:111
*>i10.10.111.1/32   10.10.127.1              0    100      0 ?
Route Distinguisher: 200:222
*> 10.10.222.1/32   172.16.0.2                             0 200 ?

Verify the IPv4 vrf routes on and connectivity the PE-ABC1 and PE-XYZ-1:

PE-ABC-1#sh ip route vrf Company
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
C       10.10.111.1 is directly connected, Loopback111
B       10.10.222.1 [200/0] via 10.10.127.3, 00:10:23
PE-ABC-1#ping vrf BMW-EURO 10.10.222.1
Sending 5, 100-byte ICMP Echos to 10.10.222.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/205/268 ms

PE-XYZ-1#sh ip route vrf Company
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
B       10.10.111.1 [200/0] via 100.100.127.1, 00:12:40
C       10.10.222.1 is directly connected, Loopback222
PE-XYZ-1#ping vrf Company 10.10.111.1
Sending 5, 100-byte ICMP Echos to 10.10.111.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 124/162/220 ms

Multiple VRF on One Customer Site

February 10, 2009 Leave a comment

In MPLS VPN implementation, every interface have just one VRF. Maybe for some reason, our customer named XYZ, need to have more than one VPN for their networks. For example they want to separate the Accounting and Manufacture Department networks in the different VPN.

To accomplish this requirement, we can apply a few solutions below:

  • Using Subinterface
  • Using VRF-Select
  • Using interface Tunnel and VRF-Lite

In this article, we will use the third solution, that is using interface tunnel and VRF Lite. Notes that we already using one VRF for the customer XYZ , applied to the interface Fastethernet1/0 at PE Router. This existing VRF converted to the VRF XYZ-ACCT for Accounting Department VPN.

For the Manufacture Department VPN, we use an interface tunnel that originated from the loopback0 interface at CE-XYZ Router and terminated at the loopback127 interface at PE-Router. The loopback interfaces above is belong to the existing VRF (XYZ-ACCT), but the tunnel interface itself belong to the new VRF, that is VRF XYZ-MANF (for Manufacture Department).

multiple-vrf

1. Existing Configuration with VRF XYZ-ACCT

Below is the existing configuration on C-XYZ-ACCT, CE-XYZ and PE Router:

hostname C-XYZ-MANF
!
interface FastEthernet0/0
ip address 192.168.11.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.11.1

hostname C-XYZ-ACCT
!
interface FastEthernet0/0
ip address 192.168.10.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.10.1

hostname CE-XYZ
!
interface FastEthernet1/0
ip address 192.168.10.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.2

hostname PE
!
ip cef
ip vrf XYZ-ACCT
rd 100:101
route-target export 100:101
route-target import 100:101
!
interface FastEthernet1/0
ip vrf forwarding XYZ-ACCT
ip address 192.168.1.2 255.255.255.0
!
ip classless
ip route vrf XYZ-ACCT 192.168.10.0 255.255.255.0 192.168.1.1

2. Create VRF-Lite on CE-XYZ Router:

Create VRF XYZ-ACCT and apply to the interface that connected to the PE and the C-XYZ-ACCT router. Create the default static ip route for VRF XYZ-ACCT.

ip vrf XYZ-ACCT
!
interface FastEthernet1/0
ip vrf forwarding XYZ-ACCT
ip address 192.168.10.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet2/0
ip vrf forwarding XYZ-ACCT
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
ip route vrf XYZ-ACCT 0.0.0.0 0.0.0.0 192.168.1.2

Verify the connection:

CE-XYZ#ping v XYZ-ACCT 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/36/48 ms

C-XYZ-ACCT#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/46/72 ms

3. Create Tunnel interface at CE-XYZ and PE for new VRF

Add a new VRF for XYZ Manufacture Department at PE router. Use loopback interface that belong to the VRF XYZ-ACCT for the Tunnel-Source. Apply the new VRF (XYZ-MANF) to the tunnel interface.

ip vrf XYZ-MANF
rd 100:100
route-target export 100:100
route-target import 100:100
!
interface Loopback127
ip vrf forwarding XYZ-ACCT
ip address 192.168.127.2 255.255.255.255
no ip directed-broadcast
!
interface Tunnel1
ip vrf forwarding XYZ-MANF
ip address 192.168.2.2 255.255.255.0
no ip directed-broadcast
tunnel source Loopback127
tunnel destination 192.168.127.1
tunnel vrf XYZ-ACCT

At the CE-XYZ router, add a new VRF, then apply it to the Tunnel interface. The tunnel interface using loopback interface that belong to the VRF XYZ-ACCT for the Tunnel-Source interface:

ip vrf XYZ-MANF
!
interface Loopback0
ip vrf forwarding XYZ-ACCT
ip address 192.168.127.1 255.255.255.255
!
interface Tunnel1
ip vrf forwarding XYZ-MANF
ip address 192.168.2.1 255.255.255.0
tunnel source Loopback0
tunnel destination 192.168.127.2
tunnel vrf XYZ-ACCT
!
interface Loopback0
ip vrf forwarding XYZ-ACCT
ip address 192.168.127.1 255.255.255.255

Verify the Tunnel interfaces:

PE#sh ip int br | i Tun
Tunnel1 192.168.2.2 YES manual up up
PE#sh ip vrf int | i Tu
Tu1 192.168.2.2 XYZ-MANF up
PE#ping vrf XYZ-MANF 192.168.2.1
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/43/92 ms

CE-XYZ#sh ip int br | i Tun
Tunnel1 192.168.2.1 YES manual up up
CE-XYZ#sh ip vrf int | i Tu
Tu1 192.168.2.1 XYZ-MANF up
CE-XYZ#ping vrf XYZ-MANF 192.168.2.2
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/48 ms

Add a default static route for VRF XYZ-MNF at CE-XYZ router. Use the PE Tunnel interface IP Address as the next-hop.

ip route vrf XYZ-MANF 0.0.0.0 0.0.0.0 192.168.2.2

4. Apply VRF-Lite for the Manufacture VPN to the interface

hostname CE-XYZ
!
interface FastEthernet0/0
ip vrf forwarding XYZ-MANF
ip address 192.168.11.1 255.255.255.0
duplex auto
speed auto

CE-XYZ#sh ip vrf XYZ-MANF
Name Default RD Interfaces
XYZ-MANF <not set> Tu1
Fa0/0
CE-XYZ#

For verification purpose, create new loopback interface at PE-Router and Apply VRF XYZ-MANF to it.

PE#sh run int lo 11
!
interface Loopback11
ip vrf forwarding XYZ-MANF
ip address 192.168.111.11 255.255.255.255
no ip directed-broadcast
end

Add static IP route to C-XYZ-MANF — CE-XYZ back-to-back network at PE router:

ip route vrf XYZ-MANF 192.168.11.0 255.255.255.0 192.168.2.1

Verify connection from C-XYZ-MANF router:

C-XYZ-MANF#ping 192.168.2.2
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/59/128 ms
C-XYZ-MANF#ping 192.168.111.11
Sending 5, 100-byte ICMP Echos to 192.168.111.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/74/108 ms
C-XYZ-MANF#traceroute 192.168.111.11
Tracing the route to 192.168.111.11
1 192.168.11.1 76 msec 40 msec 24 msec
2 192.168.2.2 12 msec * 176 msec
C-XYZ-MANF#

Securing MPLS LDP

November 25, 2008 Leave a comment

To secure LDP communication between LSRs peer (PE to P), we can use MD5 authentication. Below is the simple configuration for MPLS LDP authentication:

Router(config)#mpls ldp neighbor direct_peer_ip password p@55w0rd

Verification:

Router#sh mpls ldp nei peer_ip_address detail
Peer LDP Ident: peer_ip_address:0; Local LDP Ident local_ip_address:0
TCP connection: peer_ip_address.12780 – local_ip_address.646; MD5 on
Password: not required, neighbor, in use
State: Oper; Msgs sent/rcvd: 3/4; Downstream; Last TIB rev sent 0
Up time: 00:00:55; UID: 4; Peer Id 0;
LDP discovery sources:

ldp-md51

AToM Tunnel Selection Using MPLS Traffic-Engineering

July 28, 2008 3 comments

By default, AToM will use IGP to select what path that will used to send the pseudowire packets. In this scenario we will use MPLS Traffic-Engineering to select the pseudowire path.

Below is the diagram for our scenario:

We will build an AToM VC (Virtual Circuit) for CE-1 and CE-2 Ethernet connection. The VC will use Pseudowire Tunnel-Selection with MPLS Traffic-Engineering. We will select path (PE-1) – (P1) – (PE-2).

So, let we configure our routers (note that IGP and LDP is already configured and working properly).

Configure EoMPLS VC on PE-1 and PE-2

Configure RSVP for MPLS Traffic-Engineering support on the relevant interfaces at the Service Provider routers, that are PE-1 (F1/1,F0/0), PE-2 (F1/1, F0/0), P1 (F0/0, F1/0, F1/1) and P2 (F0/0, F1/0, F1/1):

mpls label protocol ldp
mpls traffic-eng tunnels
mpls ip
ip rsvp bandwidth 8000

The RSVP bandwidth for path (PE-1)-(P1)-(PE-2) is 80000, and for path (PE-1)-(P2)-(PE-2) is 70000 Mbps.

The configuration below is implemented only at router PE-1. Remember that MPLS Traffic-Engineering is for unidirectional traffic flow. So if we want to use Traffic-Engineering for the reserve flow, then we must implement it at router PE-2 too.

Configure IP Explicit-Path to use (PE-1)-(P1)-(PE-2) path:

ip explicit-path name P1-PE2 enable
next-address 10.0.0.2
next-address 10.1.1.1

Configure Interface Tunnel1 that used by EoMPLS VC 301 for preferred path. Don’t forget to apply the IP Explicit-Path P1-PE2 to this interface

interface Tunnel1
ip unnumbered Loopback0
no ip directed-broadcast
mpls traffic-eng tunnels
tunnel destination 10.10.10.3
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng bandwidth 7500
tunnel mpls traffic-eng path-option 1 explicit name P1-PE2
end

Configure pseudowire-class with MPLS encapsulation and using Tunnel1 as preferred-path:

pseudowire-class VIA_P1
encapsulation mpls
preferred-path interface Tunnel1

On router PE-1, configure subinterface that facing to the CE-1 (note that IP interface loopback0 on PE-2 is 10.10.10.3). In this scenario, we use VLAN 30 EoMPLS:

interface FastEthernet1/0.30
encapsulation dot1Q 30
no ip directed-broadcast
xconnect 10.10.10.3 301 pw-class VIA_P1
end

Because we just want to use Traffic-Engineering for one direction only (that is for flow from PE-1 to PE-2), then we configure the standard configuration for AToM application at the interface that facing to router CE-2 (note that IP interface loopback0 on PE-2 is 10.10.10.1):

interface FastEthernet1/0.30
encapsulation dot1Q 30
no ip directed-broadcast
xconnect 10.10.10.1 301 encapsulation mpls
end

Verifying EoMPLS VC on PE-1

So, let we verify our configuration:

PE-1#sh mpls l2 vc
Local intf Local circuit Dest address VC ID Status
————- ————————– ————— ———- ———-
Fa1/0.30 Eth VLAN 30 10.10.10.3 301 UP

PE-1#sh mpls l2 vc 301 det
Local interface: Fa1/0.30 up, line protocol up, Eth VLAN 30 up
Destination address: 10.10.10.3, VC ID: 301, VC status: up
Preferred path: Tunnel1, active
Default path: ready
Next hop: point2point
Output interface: Tu1, imposed label stack {39 33}
Create time: 00:42:44, last status change time: 00:40:36
Signaling protocol: LDP, peer 10.10.10.3:0 up
Targeted Hello: 10.10.10.1(LDP Id) -> 10.10.10.3
MPLS VC labels: local 34, remote 33
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 0, send 0
byte totals: receive 0, send 0
packet drops: receive 0, seq error 0, send 0

Note that for VC 301, we will use Tunnel1 as a preferred-path.

PE-1#sh mpls traffic-eng tunnels Tunnel 1
Name: PE-1_t1 (Tunnel1) Destination: 10.10.10.3
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit P1-PE2 (Basis for Setup, path weight 2)
Config Parameters:
Bandwidth: 7500 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 7500 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : –
OutLabel : FastEthernet1/1, 39
RSVP Signalling Info:
Src 10.10.10.1, Dst 10.10.10.3, Tun_Id 1, Tun_Instance 15
RSVP Path Info:
My Address: 10.0.0.1
Explicit Route: 10.0.0.2 10.1.1.2 10.1.1.1 10.10.10.3
Record Route: NONE
Tspec: ave rate=7500 kbits, burst=1000 bytes, peak rate=7500 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=7500 kbits, burst=1000 bytes, peak rate=7500 kbits
Shortest Unconstrained Path Info:
Path Weight: 2 (TE)
Explicit Route: 10.0.0.1 10.0.0.2 10.1.1.2 10.1.1.1 10.10.10.3
History:
Tunnel:
Time since created: 45 minutes, 36 seconds
Time since path change: 16 minutes, 35 seconds
Number of LSP IDs (Tun_Instances) used: 15
Current LSP:
Uptime: 16 minutes, 35 seconds
Prior LSP:
ID: path option 1 [14]
Removal Trigger: configuration changed
PE-1#

We can see that the path that used by interface Tunnel-1 is equivalent with our ip explicit-path configuration (P1-PE2).

The outgoing (outer) label that used by Tunnel1 is 39 via interface FastEthernet 1/1. We can see the corellation at router P1:

P1#sh mpls traffic-eng tunnels
LSP Tunnel PE-1_t1 is signalled, connection is up
InLabel : FastEthernet1/0, 39
OutLabel : FastEthernet1/1, implicit-null
RSVP Signalling Info:
Src 10.10.10.1, Dst 10.10.10.3, Tun_Id 1, Tun_Instance 15
RSVP Path Info:
My Address: 10.1.1.2
Explicit Route: 10.1.1.1 10.10.10.3
Record Route: NONE
Tspec: ave rate=7500 kbits, burst=1000 bytes, peak rate=7500 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=7500 kbits, burst=1000 bytes, peak rate=7500 kbits
P1#

And for the inner label (VC label), VC 301 use label 33. We can see this in the FIB table at router PE-2:

PE-2#sh mpls for
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
33 Untagged l2ckt(301) 0 none point2point
35 Pop tag 10.12.12.0/24 0 Fa0/0 10.3.3.2
Pop tag 10.12.12.0/24 0 Fa1/1 10.1.1.2
36 Pop tag 10.0.0.0/24 0 Fa1/1 10.1.1.2
37 Pop tag 10.2.2.0/24 0 Fa0/0 10.3.3.2
38 33 10.10.10.1/32 0 Fa1/1 10.1.1.2
42 10.10.10.1/32 0 Fa0/0 10.3.3.2
39 Pop tag 10.10.10.2/32 0 Fa1/1 10.1.1.2
64 Pop tag 10.10.10.4/32 0 Fa0/0 10.3.3.2

So, let we verify EoMPLS connectivity between CE-1 and CE-2:

CE-1#sh run int f1/0.30
interface FastEthernet1/0.30
encapsulation dot1Q 30
ip address 30.1.1.1 255.255.255.0
end
CE-1#ping 30.1.1.2
Sending 5, 100-byte ICMP Echos to 30.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 680/836/988 ms
CE-1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 30.1.1.2 0 cc05.1628.0010 ARPA FastEthernet1/0.30
Internet 30.1.1.1 – cc00.1628.0010 ARPA FastEthernet1/0.30
CE-1#

CE-2#sh run int f1/0.30
interface FastEthernet1/0.30
encapsulation dot1Q 30
ip address 30.1.1.2 255.255.255.0
end
CE-2#ping 30.1.1.1
Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 628/892/1580 ms
CE-2#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 30.1.1.2 – cc05.1628.0010 ARPA FastEthernet1/0.30
Internet 30.1.1.1 2 cc00.1628.0010 ARPA FastEthernet1/0.30
CE-2#

Done …