Archive

Author Archive

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.

Advertisements

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.

Dual Hub Dual DMVPN

January 21, 2011 1 comment

The scenario is to provide redundant DMVPN connection for the spokes.
We using two tunnel on every spokes.

Dual Hub Dual DMVPN

HUB1:

crypto isakmp policy 100
encr 3des
authentication pre-share
group 2
crypto isakmp key ISAKMPKEY1 address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10
!
crypto ipsec transform-set TRANSF esp-3des esp-sha-hmac
!
crypto ipsec profile PROFILE
set transform-set TRANSF
!
interface FastEthernet1/0
ip address 100.100.1.1 255.255.255.0
duplex full
speed 100
!
interface FastEthernet1/1
ip address 10.10.1.1 255.255.255.0
duplex full
speed 100
!
interface Loopback0
ip address 192.168.1.1 255.255.255.255
!
interface Tunnel0
ip address 172.16.0.1 255.255.255.0
no ip redirects
no ip next-hop-self eigrp 10
ip nhrp authentication NHRPAUTH
ip nhrp map multicast dynamic
ip nhrp network-id 100
no ip split-horizon eigrp 10
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 12345
tunnel protection ipsec profile PROFILE
!
router eigrp 10
network 10.10.1.1 0.0.0.0
network 172.16.0.1 0.0.0.0
network 192.168.1.1 0.0.0.0
no auto-summary
!
router ospf 1
log-adjacency-changes
network 100.100.1.1 0.0.0.0 area 0
!

HUB2:
crypto isakmp policy 200
hash md5
authentication pre-share
crypto isakmp key ISAKMPKEY1 address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10
!
crypto ipsec transform-set DM2TRANS esp-des esp-md5-hmac
!
crypto ipsec profile DM2PRF
set transform-set DM2TRANS
!
interface Tunnel0
ip address 172.16.100.1 255.255.255.0
no ip redirects
no ip next-hop-self eigrp 10
ip nhrp authentication DM2NHRP
ip nhrp map multicast dynamic
ip nhrp network-id 2011
no ip split-horizon eigrp 1
no ip split-horizon eigrp 10
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 2011
tunnel protection ipsec profile DM2PRF
!
interface Loopback0
ip address 192.168.0.1 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
ip address 100.100.0.1 255.255.255.0
duplex full
speed 100
!
interface FastEthernet1/1
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 10
network 172.16.100.1 0.0.0.0
network 192.168.0.1 0.0.0.0
no auto-summary
!
router ospf 1
log-adjacency-changes
network 100.100.0.1 0.0.0.0 area 0
!

SPOKE1:
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp policy 20
hash md5
authentication pre-share
crypto isakmp key ISAKMPKEY1 address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10
!
crypto ipsec transform-set TRANSFFORM esp-3des esp-sha-hmac
crypto ipsec transform-set DM2TRANSFORM esp-des esp-md5-hmac
!
crypto ipsec profile DM2PROFILE
set transform-set DM2TRANSFORM
!
crypto ipsec profile PROFILE
set transform-set TRANSFFORM
!
interface Tunnel0
ip address 172.16.0.2 255.255.255.0
no ip redirects
ip nhrp authentication NHRPAUTH
ip nhrp map 172.16.0.1 100.100.1.1
ip nhrp map multicast 100.100.1.1
ip nhrp network-id 100
ip nhrp nhs 172.16.0.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 12345
tunnel protection ipsec profile PROFILE
!
interface Tunnel1
ip address 172.16.100.2 255.255.255.0
no ip redirects
ip nhrp authentication DM2NHRP
ip nhrp map 172.16.100.1 100.100.0.1
ip nhrp map multicast 100.100.0.1
ip nhrp network-id 2011
ip nhrp nhs 172.16.100.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 2011
tunnel protection ipsec profile DM2PROFILE
!
interface Loopback0
ip address 192.168.2.1 255.255.255.255
!
interface FastEthernet1/0
ip address 100.100.2.1 255.255.255.0
duplex full
speed 100
!
router eigrp 10
network 172.16.0.2 0.0.0.0
network 172.16.100.2 0.0.0.0
network 192.168.2.1 0.0.0.0
no auto-summary
!
router ospf 1
log-adjacency-changes
network 100.100.2.1 0.0.0.0 area 0
!

SPOKE2:
crypto isakmp policy 100
encr 3des
authentication pre-share
group 2
!
crypto isakmp policy 200
hash md5
authentication pre-share
crypto isakmp key ISAKMPKEY1 address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10
!
crypto ipsec transform-set TRANSF esp-3des esp-sha-hmac
crypto ipsec transform-set DMV2 esp-des esp-md5-hmac
!
crypto ipsec profile DMV2PROF
set transform-set DMV2
!
crypto ipsec profile IPSECPRF
set transform-set TRANSF
!
interface Tunnel0
ip address 172.16.0.3 255.255.255.0
no ip redirects
ip nhrp authentication NHRPAUTH
ip nhrp map multicast 100.100.1.1
ip nhrp map 172.16.0.1 100.100.1.1
ip nhrp network-id 100
ip nhrp nhs 172.16.0.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 12345
tunnel protection ipsec profile IPSECPRF
!
interface Tunnel100
ip address 172.16.100.3 255.255.255.0
no ip redirects
ip nhrp authentication DM2NHRP
ip nhrp map 172.16.100.1 100.100.0.1
ip nhrp map multicast 100.100.0.1
ip nhrp network-id 2011
ip nhrp nhs 172.16.100.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 2011
tunnel protection ipsec profile DMV2PROF
!
interface Loopback0
ip address 192.168.3.1 255.255.255.255
!
interface FastEthernet1/0
ip address 100.100.3.1 255.255.255.0
duplex full
speed 100
!
router eigrp 10
network 172.16.0.3 0.0.0.0
network 172.16.100.3 0.0.0.0
network 192.168.3.1 0.0.0.0
no auto-summary
!
router ospf 1
log-adjacency-changes
network 100.100.3.1 0.0.0.0 area 0
!

Ok. Now we estimate that the configuration running well. The two DMVPN cloud is establish. And we choose the HUB1 as the primary HUB. So we must make route selection. In this case we using EIGRP as the IGP for the DMVPN.

By default, every spokes will have 2 equal routes to the every loopback interfaces of the other spokes. Because we already choose Hub1 as the primary, so we give the lower delay for the Hub1 tunnel interface. Every spokes will prefer the DMVPN1 Tunnel (which connected to the Hub1) as the primary path to the loopback networks behind the other spokes.

HUB1:
interface Tunnel0
delay 49999
!

SPOKE2#sh ip route eigrp
10.0.0.0/24 is subnetted, 1 subnets
D 10.10.1.0 [90/297246976] via 172.16.0.1, 00:01:26, Tunnel0
192.168.0.0/32 is subnetted, 1 subnets
D 192.168.0.1 [90/297372416] via 172.16.100.1, 00:01:26, Tunnel100
192.168.1.0/32 is subnetted, 1 subnets
D 192.168.1.1 [90/297372416] via 172.16.0.1, 00:01:26, Tunnel0
192.168.2.0/32 is subnetted, 1 subnets
D 192.168.2.1 [90/310172160] via 172.16.0.2, 00:01:26, Tunnel0

Below is the DMVPN relevant condition of the Spoke2:

SPOKE2#sh ip nhrp
172.16.0.1/32 via 172.16.0.1, Tunnel0 created 02:45:34, never expire
Type: static, Flags: authoritative used
NBMA address: 100.100.1.1
172.16.100.1/32 via 172.16.100.1, Tunnel100 created 02:45:32, never expire
Type: static, Flags: authoritative used
NBMA address: 100.100.0.1

SPOKE2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
100.100.1.1 100.100.3.1 QM_IDLE 1014 0 ACTIVE
100.100.3.1 100.100.0.1 QM_IDLE 1016 0 ACTIVE

SPOKE2#ping 192.168.2.1 sou 192.168.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.3.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 244/398/756 ms
SPOKE2#

SPOKE2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
100.100.2.1 100.100.3.1 QM_IDLE 1017 0 ACTIVE
100.100.1.1 100.100.3.1 QM_IDLE 1014 0 ACTIVE
100.100.3.1 100.100.0.1 QM_IDLE 1016 0 ACTIVE

IPv6 Crypto ISAKMP SA

SPOKE2#sh ip nhrp
172.16.0.1/32 via 172.16.0.1, Tunnel0 created 02:46:32, never expire
Type: static, Flags: authoritative used
NBMA address: 100.100.1.1
172.16.0.2/32 via 172.16.0.2, Tunnel0 created 00:00:13, expire 01:55:58
Type: dynamic, Flags: router
NBMA address: 100.100.2.1
172.16.100.1/32 via 172.16.100.1, Tunnel100 created 02:46:30, never expire
Type: static, Flags: authoritative used
NBMA address: 100.100.0.1
SPOKE2#
SPOKE2#

SPOKE2#sh ip route eigrp
10.0.0.0/24 is subnetted, 1 subnets
D 10.10.1.0 [90/297246976] via 172.16.0.1, 00:03:12, Tunnel0
192.168.0.0/32 is subnetted, 1 subnets
D 192.168.0.1 [90/297372416] via 172.16.100.1, 00:03:19, Tunnel100
192.168.1.0/32 is subnetted, 1 subnets
D 192.168.1.1 [90/297372416] via 172.16.0.1, 00:03:13, Tunnel0
192.168.2.0/32 is subnetted, 1 subnets
D 192.168.2.1 [90/310172160] via 172.16.0.2, 00:02:33, Tunnel0
SPOKE2#

Now, we try to shutdown the WAN interface of the HUB1, so the DMVPN2 will active and HUB2 will acting as the active hub.

We use ping tool to measure the transition time from DMVPN1 to the DMVPN2:

SPOKE2#ping 192.168.2.1 rep 100000 sou 192.168.3.1

Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.3.1
!!!!!!

Let’s we switch to the HUB1:

HUB1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
HUB1(config)#int f1/0
HUB1(config-if)#shut
*Jan 20 17:21:49.963: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.3.2 on FastEthernet
1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Jan 20 17:21:51.955: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state
to administratively down
*Jan 20 17:21:51.959: %ENTITY_ALARM-6-INFO: ASSERT INFO Fa1/0 Physical Port Administrative State Down
*Jan 20 17:21:52.959: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down
*Jan 20 17:21:54.435: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
*Jan 20 17:21:54.663: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 172.16.0.2 (Tunnel0) is down: interface down
*Jan 20 17:21:54.695: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 172.16.0.3 (Tunnel0) is down: interface down

We switch back to the Spoke2 to check the transition time from the DMVPN1 to DMVPN2:

SPOKE2#ping 192.168.2.1 rep 100000 sou 192.168.3.1

Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.3.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!…..!!
*Jan 20 13:01:40.183: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 172.16.0.1 (Tunnel0) is down: holding time expired!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 96 percent (141/146), round-trip min/avg/max = 224/589/1104 ms

After the transition, now we check the DMVPN relevant condition on the Spoke2:

SPOKE2#sh ip nhrp
172.16.0.1/32 via 172.16.0.1, Tunnel0 created 02:48:15, never expire
Type: static, Flags: authoritative used
NBMA address: 100.100.1.1
172.16.0.2/32 via 172.16.0.2, Tunnel0 created 00:01:57, expire 01:54:15
Type: dynamic, Flags: router
NBMA address: 100.100.2.1
172.16.100.1/32 via 172.16.100.1, Tunnel100 created 02:48:14, never expire
Type: static, Flags: authoritative used
NBMA address: 100.100.0.1

SPOKE2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
100.100.2.1 100.100.3.1 QM_IDLE 1017 0 ACTIVE
100.100.1.1 100.100.3.1 MM_NO_STATE 0 0 ACTIVE
100.100.1.1 100.100.3.1 MM_NO_STATE 1014 0 ACTIVE (deleted)
100.100.3.1 100.100.0.1 QM_IDLE 1016 0 ACTIVE

SPOKE2#sh ip route eigrp
192.168.0.0/32 is subnetted, 1 subnets
D 192.168.0.1 [90/297372416] via 172.16.100.1, 00:05:01, Tunnel100
192.168.2.0/32 is subnetted, 1 subnets
D 192.168.2.1 [90/310172416] via 172.16.100.2, 00:00:48, Tunnel100

Now we see that Spoke2 using DMVPN2 where the Hub2 act as the primary Hub to connect to the loopback interfaces behind the Spoke1:

SPOKE2#ping 192.168.2.1 sou 192.168.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.3.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 372/436/516 ms

Ok. Now the DMVPN2 used by every Spokes router to connect each other.

Now we try to switch back the DMVPN1 as the primary connection by activate the WAN interface of the Hub1. Then we can see that the spokes using DMVPN1 again as the primary connection:

SPOKE2#sh ip route eigrp
10.0.0.0/24 is subnetted, 1 subnets
D 10.10.1.0 [90/297246976] via 172.16.0.1, 00:00:30, Tunnel0
192.168.0.0/32 is subnetted, 1 subnets
D 192.168.0.1 [90/297372416] via 172.16.100.1, 00:00:30, Tunnel100
192.168.1.0/32 is subnetted, 1 subnets
D 192.168.1.1 [90/297372416] via 172.16.0.1, 00:00:30, Tunnel0
192.168.2.0/32 is subnetted, 1 subnets
D 192.168.2.1 [90/310172160] via 172.16.0.2, 00:00:30, Tunnel0

Blocking TeamViewer Connection Using Cisco ASA Firewall

January 13, 2011 3 comments

TeamViewer (TV) is application that used to create remote access connection to PC anywhere. Even if the PC located behind the firewall.

Similiar like YahooMessenger, TV provide every client with the PIN and password. Everyone who want to access the other TV client need to know the PIN and password of the opposite PC. And every party that want to make connection must be connected to the TV server (servers domain is *.teamviewer.com and/or *.dyngate.com) usualy using TCP port 80.

PC that running TV is potentialy act as a backdoor in the enterprise network. Yes, to make remote connection we need to know the PIN and password, but using Social Engineering technique, untrusted person can gained it.

Because TV client using port 80 for the outbound connection, it is difficult to block using port basis. So, because TV client must be connected first to the TV server, we can use another aproach, that is blocking every dns request for the *.teamviewer.com and/or *.dyngate.com

So, these are the configuration if we use Cisco ASA Firewall (i am using OS ver 8.x):

regex TV-RGX “\.teamviewer\.com”
regex DG-RGX “\.dyngate\.com”

class-map type regex match-any TV-CLS
match regex DG-RGX
match regex TV-RGX

policy-map type inspect dns TV-PLC
parameters
message-length maximum 512
match domain-name regex class TV-CLS
drop

policy-map global_policy
class inspection_default
inspect dns TV-PLC

service-policy global_policy global

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#