MHSRP & OSPF design

On September 25, 2010, in CCIE, by Darren

I’m going to start blogging about various design stuff that I do these days at work. Maybe you can get some ideas from these types of posts.

I’m going to run this simple topology:
HSRP Secondary1 MHSRP & OSPF design

The client has 2 networks at the first site – 192.168.1.0/24 and 10.10.10.0/24. These are both connected to R1 and R2 (via a switch not shown) – R1 and R2 are running MHSRP, with R1 being the master of 192.168.1.254 and R2 being the master of 10.10.10.254. Both routers are the backup of each others group.

I want the link from R1 to be used for 192.168.1.0 and I want the link from R2 to be used for 10.10.10.0. I also want return traffic to take the same path. i.e. if R3 needs to send traffic to 10.10.10.0 – it needs to prefer the direct path to R2.

Another constraint is that I need convergence to be fast, therefore I’m not going to run HSRP on the WAN side of R1 and R2 and have to wait for the IGP to re-converge.

The final constraint is that I don’t want to have to use route-map’s on R3 itself. Let’s pretend there are going to be a lot more routers connected to OSPF area 0. I want to make it as simple as possible when newer routers come into the area. Therefore all this routing needs to be controlled by R1 and R2 themselves.

So far, pretty simple. So let’s get cracking!

Let’s do R1 first, this is the relevant config:

interface FastEthernet0/1
ip address 10.10.10.1 255.255.255.0 secondary
ip address 192.168.1.1 255.255.255.0
standby version 2
standby 1 ip 192.168.1.254
standby 1 priority 110
standby 1 preempt
standby 1 track FastEthernet0/0 50
standby 2 ip 10.10.10.254
standby 2 preempt
standby 2 track FastEthernet0/0 50

And now R2:

interface FastEthernet0/1
ip address 10.10.10.2 255.255.255.0
ip address 192.168.1.2 255.255.255.0 secondary
standby version 2
standby 1 ip 192.168.1.254
standby 1 preempt
standby 1 track FastEthernet0/0 50
standby 2 ip 10.10.10.254
standby 2 priority 110
standby 2 preempt
standby 2 track FastEthernet0/0 50

Now let’s set up OSPF. Remember that I want 192.168.1.0 traffic to go via R1 and 10.10.10.0 to go via R2. There are a number of ways of doing this.

First let’s try and set up regular OSPF with a metric:

router ospf 1
 R1(config-router)#network 10.10.10.0 0.0.0.255 area 0 ?
  cr>
 R1(config-router)#network 10.10.10.0 0.0.0.255 area 0

OSPF will not allow you to specify a metric under the network command!

There is another way. Run 2 OSPF processes and redistribute with a higher metric.

router ospf 1
 redistribute ospf 2 metric 50 metric-type 1 subnets
 network 1.1.1.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0
!
router ospf 2
 network 10.10.10.0 0.0.0.255 area 0

Let’s check R3′s routing table:

R3#sh ip route
     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.50.0 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/51] via 1.1.1.1, 00:00:39, FastEthernet0/0
O    192.168.1.0/24 [110/2] via 1.1.1.1, 00:00:39, FastEthernet0/0

It works, but I think its messy. We could also use route-maps which would give us a lot finer control over newer subnets that may be added (without having to run more OSPF processes)

Let’s remove that OSPF config from R1 and do the following:

router ospf 1
 redistribute connected metric-type 1 subnets route-map 10_HIGH
 network 1.1.1.0 0.0.0.255 area 0
!
ip prefix-list 10NET seq 5 permit 10.10.10.0/24
!
route-map 10_HIGH permit 10
 match ip address prefix-list 10NET
 set metric +100
!
route-map 10_HIGH permit 20

Now we do this on R2:

router ospf 1
 redistribute connected metric-type 1 subnets route-map 192_HIGH
 network 1.1.1.0 0.0.0.255 area 0
!
ip prefix-list 192NET seq 5 permit 192.168.1.0/24
!
route-map 192_HIGH permit 10
 match ip address prefix-list 192NET
 set metric +100
!
route-map 192_HIGH permit 20

This will ensure R1 redistributes the 10.10.10.0 network with a higher metric to R3, and vice-versa for R2. R3 will have a possible route in it’s database, but won’t use it until the preferred link is down/

Let’s have a look at R3′s routing table:

R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/21] via 1.1.1.2, 00:00:28, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:28, FastEthernet0/0

Excellent, just what we want. but do the backups work correctly? Let’s shut down R1′s interface to the customer LAN and see what happens:

R1(config)#int fa1/0
R1(config-if)#shut
R1(config-if)#
*Mar  1 00:34:20.711: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Active -> Init
*Mar  1 00:34:20.723: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Init
*Mar  1 00:34:22.723: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down
*Mar  1 00:34:23.723: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down

What does R3 see?

R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/21] via 1.1.1.2, 00:00:18, FastEthernet0/0
O E1 192.168.1.0/24 [110/101] via 1.1.1.2, 00:00:18, FastEthernet0/0

Both are now going via R2, which is exactly what we wanted. Let’s now reconnect R1 and disconnect R2′s WAN link:

R1(config-if)#int fa1/0
R1(config-if)#no shut
R1(config-if)#
*Mar  1 00:35:47.775: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Listen -> Active
*Mar  1 00:35:47.859: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar  1 00:35:48.859: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
R2(config)#int fa0/0
R2(config-if)#shut
R2(config-if)#
*Mar  1 00:36:16.179: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Up->Down
*Mar  1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:36:18.179: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 00:36:18.231: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Active -> Speak
*Mar  1 00:36:19.179: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

What does R3 see this time?

R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/101] via 1.1.1.1, 00:00:03, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:03, FastEthernet0/0

Great. Let’s just make sure it all works properly again if all links are up:

R2(config-if)#int fa0/0
R2(config-if)#no shut
R2(config-if)#
*Mar  1 00:37:53.291: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Down->Up
*Mar  1 00:37:54.235: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Active
*Mar  1 00:37:55.287: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:37:56.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/21] via 1.1.1.2, 00:00:06, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:06, FastEthernet0/0

Let’s see what happens when a client is pinging a network directly connected to R3 over the 192.168.1.0 network. I’ll be using a router as a client, so it’ll be a ping flood.

R4#ping 172.16.50.1 repeat 1000

I’ll quickly shut R1′s LAN interface. Wait a bit, and then no shut it. What happens to R4′s pings?

Sending 1000, 100-byte ICMP Echos to 172.16.50.1, timeout is 2 seconds:
!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (998/1000), round-trip min/avg/max = 1/44/160 ms

I lost only 2 pings! Once when I shut the interface, and the second when it came back up again. Pretty good!

It wont be as fast if the WAN link goes down though. R2 will take over for sending packets out, but return traffic will still go to R1. Why? Well remember R3 still thinks R1 is there. Unless they were directly connected, or you wait for OSPF to realise the peer is down, it’ll continue to send traffic that way. You can speed this up by reducing your OSPF hello timers though. This will need to be balanced on how much OSPF traffic you want going across your WAN link.

Tagged with:  

Lab Solution – MPLS Lab #2

On September 9, 2010, in CCIE, by Darren

Sometimes its so hard to simply find the time to do what I promised. I hope this will spur up some conversation. I still stress that you should always try to do the lab without my help first. This will ensure you learn how to do it properly. Also remember that there are always multiple ways to do certain labs, so don’t take my solution as gospel.

This solution is for the lab I posted here: http://mellowd.co.uk/ccie/?p=527

  • CPE1 and CPE5 belong to Customer1
  • CPE2 and CPE6 belong to Customer2
  • Both customers are running OSPF as their IGP’s
  • The loopbacks as shown in the topology must be advertised into OSPF. Cutomer1 should be able to ping all loopbacks in their networks and Customer2 should be able to ping everything in theirs.
  • Both customers are now running a project together, and need 2 of their offices connected. CPE1 from Customer1 should be able to communicate with CPE6 from Customer2 and vice-versa
  • It’s essential that CPE2 and CPE5 are NOT able to get to all loopbacks. ONLY CPE1 and CPE6 should be able to communicate with each other. This new configuration should not break the previous VPN’s in place
  • Do this without using any ACL’s, Prefix-lists, Route-maps or the like

We start by doing a regular MPLS VPN config – The same for which we did for the first MPLS VPN lab. All the MPLS-specific config is here:

CPE1

interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0

CPE2:

interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.2.1 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 log-adjacency-changes
 network 10.1.2.0 0.0.0.255 area 0
 network 172.16.1.0 0.0.0.255 area 0

CPE5:

interface Loopback0
 ip address 192.168.2.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.3.1 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 log-adjacency-changes
 network 10.1.3.0 0.0.0.255 area 0
 network 192.168.2.0 0.0.0.255 area 0

CPE6:

interface Loopback0
 ip address 172.16.2.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.4.1 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 log-adjacency-changes
 network 10.1.4.0 0.0.0.255 area 0
 network 172.16.2.0 0.0.0.255 area 0

Now for the 2 AR Routers:

ip cef
ip vrf CUS1
 rd 400:1
 route-target export 400:1
 route-target import 400:1

ip vrf CUS2
 rd 400:2
 route-target export 400:2
 route-target import 400:2

interface FastEthernet0/0
 ip vrf forwarding CUS1
 ip address 10.1.1.2 255.255.255.0

interface FastEthernet2/0
 ip vrf forwarding CUS2
 ip address 10.1.2.2 255.255.255.0

router ospf 2 vrf CUS1
redistribute bgp 400 metric 10 subnets
 network 10.1.1.0 0.0.0.255 area 0

router ospf 3 vrf CUS2
 redistribute bgp 400 metric 10 subnets
 network 10.1.2.0 0.0.0.255 area 0

router bgp 400
 bgp log-neighbor-changes
 neighbor 10.255.255.7 remote-as 400
 neighbor 10.255.255.7 update-source Loopback0

 address-family vpnv4
  neighbor 10.255.255.7 activate
  neighbor 10.255.255.7 send-community extended
 
 
 address-family ipv4 vrf CUS2
  redistribute ospf 3 vrf CUS2 metric 10
  no synchronization
 
 address-family ipv4 vrf CUS1
  redistribute ospf 2 vrf CUS1 metric 10
  no synchronization

A similar config is on AR3. (I’m not going to post it here otherwise this post will just get to big)

Let’s now concentrate on CPE1. The initial requirements were to allow CPE1 and CPE5 to speak to each other. Currently CPE1 has the following routing table:

CPE1#sh ip route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.3.0 [110/11] via 10.1.1.2, 00:01:20, FastEthernet0/0
C       10.1.1.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Loopback0
     192.168.2.0/32 is subnetted, 1 subnets
O IA    192.168.2.1 [110/11] via 10.1.1.2, 00:01:20, FastEthernet0/0

Can CPE1 ping the loopback subnet on CPE5? It sure can!

CPE1#ping 192.168.2.1

Type escape sequence to abort.
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 = 80/112/156 ms

Can CPE1 ping CPE6? No it can’t (as expected at this point)

CPE1#ping 172.16.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

We are now told that we need CPE1 and CPE6 to be able to speak to each other for a project. CPE2 and CPE5 need to be left out of this completely. We need to do this without using any ACL’s or the like.

There is a simple way of doing this. It’s called Extranet MPLS VPN. In the configuration above, each customer is given a route target. We can create a third route-target and have both CPE1 and CPE6 join that third route-target. We then simply don’t add CPE2 and CPE6 to that same route-target.

Let’s add it on AR1 and AR3:

AR1(config)#ip vrf CUS1
AR1(config-vrf)#route-target both 400:100
AR3(config)#ip vrf CUS2
AR3(config-vrf)#route-target both 400:100

If I now check the routing table on CPE1 I see the following:

CPE1#sh ip route

Gateway of last resort is not set

     172.16.0.0/32 is subnetted, 1 subnets
O E2    172.16.2.1 [110/10] via 10.1.1.2, 00:00:21, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
O IA    10.1.3.0 [110/11] via 10.1.1.2, 00:08:41, FastEthernet0/0
C       10.1.1.0 is directly connected, FastEthernet0/0
O E2    10.1.4.0 [110/10] via 10.1.1.2, 00:00:21, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Loopback0
     192.168.2.0/32 is subnetted, 1 subnets
O IA    192.168.2.1 [110/11] via 10.1.1.2, 00:08:41, FastEthernet0/0

Can CPE1 now ping CPE6′s loopback subnet?

CPE1#ping 172.16.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/69/92 ms

It works :) – We now need to be sure that CPE2 and CPE5 still cannot see any of this.

CPE2#sh ip route

Gateway of last resort is not set

     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.1.0/24 is directly connected, Loopback0
O IA    172.16.2.1/32 [110/11] via 10.1.2.2, 22:04:42, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.2.0 is directly connected, FastEthernet0/0
O IA    10.1.4.0 [110/11] via 10.1.2.2, 22:05:56, FastEthernet0/0

As expected, it cannot ping anywhere in Customer1′s network:

CPE2#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CPE2#ping 192.168.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Job done. :D

Tagged with:  

Troubleshooting 101 – Can I get back?

On August 13, 2010, in JNCIE, by Darren

Rule #1 – Just because Host 1 can get to Host 2, does NOT mean that Host 2 can get back to Host 1!

I can’t tell you how many times I’ve seen this out in the field. Here is a prime example.

This is quite a simply common topology. OfficeA and OfficeB have a WAN connection running between them. RouterA and RouterB are under control of the ISP and are running OSPF. RouterC is a customer-owned router, and so doesn’t run any OSPF with RouterA or RouterB.

OfficeB has an internet connection, and RouterB is injecting a default route to OfficeA via OSPF.

101routeback1 Troubleshooting 101   Can I get back?

RouterB has a default route to RouterC. So let’s think about traffic flow now. A host connected to RouterA needs to send traffic to the internet. It will send it’s traffic to it’s default gateway, RouterA. RouterA has a default route injected into OSPF from RouterB and so sends traffic to RouterB.

101routeback2 Troubleshooting 101   Can I get back?

RouterB has a default route and hence sends that traffic out to RouterC. Which then goes out to the internet.

101routeback3 Troubleshooting 101   Can I get back?

Traffic then flows back from the internet to RouterC. The return address will be an IP that belongs in RouterA and RouterB’s routing table, however RouterC has no knowledge of that subnet (as it’s not participating in OSPF). RouterC will just use it’s default route and send that packet back out to the internet.  Eventually the TTL will kill that packet.

101routeback4 Troubleshooting 101   Can I get back?

This can be fixed by putting a static route on RouterC to let it know that RouterA’s ip range needs to be sent off to RouterB instead.

101routeback5 Troubleshooting 101   Can I get back?

A similar thing will happen if we add a server to SwitchA. That server’s default gateway will most likely be RouterC. If a host in OfficeA send a PING to that server, that server will then send traffic off to RouterC. If RouterC does not have the static route added above, it’ll send it out to the internet.

I’m well aware that the design in the picture is pretty bad, but I used it to illustrate a point. That point being that just because router’s know how to get from A to B, it does NOT mean they know how to route that traffic back. Make sure you understand this!

Tagged with:  

Lab Solution – MPLS Lab #1

On July 7, 2010, in CCIE, by Darren

As promised, I’ll now start writing up solutions to my previously posted labs. I hope this will spur up some conversation.  I still stress that you should always try to do the lab without my help first. This will ensure you learn how to do it properly. Also remember that there are always multiple ways to do certain labs, so don’t take my solution as gospel.

I’ll be walking through my first MPLS lab which was originally posted over here: http://mellowd.co.uk/ccie/?p=518

  • Use RIP as the routing protocol on CPE devices
  • CPE1 and CPE5 belong to Company_A
  • CPE2 and CPE6 belong to Company_B
  • Each site has a /24 that is advertised via the loopback
  • CPE1 should be able to ping CPE5’s loopback and vice-versa
  • CPE2 should be able to ping CPE6’s loopback and vice-versa
  • Different companies should NOT be able to ping each other. They must stay completely separate
  • Now remove RIP and configure it so that both companies are using OSPF
  • Once complete, remove the OSPF config and use EIGRP

The first part is very easy. As far as the config on the CPE goes, it’s standard. The CPE devices don’t know, or care, that the ISP is running MPLS. As an example, I’ve posted the relevent config from CPE6:

interface Loopback0
 ip address 172.16.2.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.4.1 255.255.255.0
 duplex auto
 speed auto
!
router rip
 version 2
 network 10.0.0.0
 network 172.16.0.0
 no auto-summary

The actual core routers also have a very simple configuration. This has already been setup in my provided configuration files. All thats needed is a IGP running correctly; CEF to be enabled; and then MPLS IP to be enabled on all links going to MPLS routers. As an example, I’ll show a bit of the configuration on CR1:

ip cef
!
interface FastEthernet0/0
 ip address 10.0.0.5 255.255.255.252
 duplex auto
 speed auto
 mpls ip
!
interface Serial1/0
 ip address 10.3.0.1 255.255.255.252
 mpls ip
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.3 area 0
 network 10.0.0.4 0.0.0.3 area 0
 network 10.2.0.0 0.0.0.3 area 0
 network 10.3.0.0 0.0.0.3 area 0
 network 10.255.255.2 0.0.0.0 area 0

The real meat of the configuration comes in on the AR routers. i.e. the edge MPLS routers that the CPE devices connect to. These are the routers which needs to hold the customer routing tables, as well as keeping customer networks separate from each other.

The first thing that needs to be done is to configure the VRF’s on each AR router that will connect. I’ll use the vrf name of CUS1 for the first customer and CUS2 for the second.

For the first customer:

AR1#(config)ip vrf CUS1
AR1#(config)rd 400:1
AR1#(config)route-target both 400:1

And now the second:

AR1#(config)ip vrf CUS2
AR1#(config)rd 400:2
AR1#(config)route-target both 400:2

We now need to setup the interfaces that the CPE devices will connect to:

AR1#interface FastEthernet0/0
AR1#ip vrf forwarding CUS1
AR1#ip address 10.1.1.2 255.255.255.0

AR1#interface FastEthernet2/0
AR1#ip vrf forwarding CUS2
AR1#ip address 10.1.2.2 255.255.255.0

Now it’s time to set up the routing protocol between the ISP vrf and the customer device. We are using RIP for this lab, so the configuration will be as follows for both customers:

AR1#router rip
AR1#version 2
AR1#no auto-summary

AR1#address-family ipv4 vrf CUS2
AR1#redistribute bgp 400 metric 10
AR1#network 10.0.0.0
AR1#no auto-summary
AR1#version 2

AR1#address-family ipv4 vrf CUS1
AR1#redistribute bgp 400 metric 10
AR1#network 10.0.0.0
AR1#no auto-summary
AR1#version 2

You can see in the above commands that we are redistributing BGP even though we haven’t configured BGP yet. Don’t worry, that step is next.

MPLS used MP-BGP for the MPLS VPN feature. i.e. it uses MP-BGP to distribute routes via each customers VRF, through the core, and then out the other side.

The first part of the MP-BGP configuration is a simple iBGP config. AR1′s configuration is below:

AR1#router bgp 400
AR1#neighbor 10.255.255.7 remote-as 400
AR1#neighbor 10.255.255.7 update-source Loopback0
AR1#no auto-summary

The second part of the MP-BGP configuration is to enable the vpnv4 part of BGP:

AR1#address-family vpnv4
 AR1#neighbor 10.255.255.7 activate
 AR1#neighbor 10.255.255.7 send-community extended

The final part is to set up the actual VRF part for each customer, and enable redistribution of RIP routes learned earlier:

AR1#address-family ipv4 vrf CUS2
AR1#redistribute rip metric 10
!
AR1#address-family ipv4 vrf CUS1
AR1#redistribute rip metric 10

To have a quick recap, this is the MPLS specific configuration now on AR1:

ip cef
!
ip vrf CUS1
 rd 400:1
 route-target export 400:1
 route-target import 400:1
!
ip vrf CUS2
 rd 400:2
 route-target export 400:2
 route-target import 400:2
!
!
interface FastEthernet0/0
 ip vrf forwarding CUS1
 ip address 10.1.1.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 ip vrf forwarding CUS2
 ip address 10.1.2.2 255.255.255.0
 duplex auto
 speed auto
!
router rip
 version 2
 no auto-summary
 !
 address-family ipv4 vrf CUS2
  redistribute bgp 400 metric 10
  network 10.0.0.0
  no auto-summary
  version 2
 exit-address-family
 !
 address-family ipv4 vrf CUS1
  redistribute bgp 400 metric 10
  network 10.0.0.0
  no auto-summary
  version 2
 exit-address-family
!
router bgp 400
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.255.255.7 remote-as 400
 neighbor 10.255.255.7 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.255.255.7 activate
  neighbor 10.255.255.7 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf CUS2
  redistribute rip metric 10
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf CUS1
  redistribute rip metric 10
  no synchronization
 exit-address-family

A similar configuration will of course need to be done on AR3.

Once done, we should be able to log onto CPE6 and ensure that it has CPE2′s networks. We should also see that it has NO access to CPE1 and CPE5′s networks. This is exactly what we see:

CPE6#sh ip route
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.1.0 [120/10] via 10.1.4.2, 00:00:19, FastEthernet0/0
C       172.16.2.0 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.2.0 [120/10] via 10.1.4.2, 00:00:19, FastEthernet0/0
C       10.1.4.0 is directly connected, FastEthernet0/0

Can we ping CPE2′s loopback? We sure can:

CPE6#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/60/92 ms

Can we ping CPE1′s loopback? No we cannot!

CPE6#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

If we run a traceroute to CPE2′s loopback, we can see it going through the MPLS core:

CPE6#trace 172.16.1.1

Type escape sequence to abort.
Tracing the route to 172.16.1.1

  1 10.1.4.2 8 msec 0 msec 20 msec
  2 10.8.0.1 [MPLS: Labels 28/38 Exp 0] 44 msec 68 msec 84 msec
  3 10.1.2.2 [MPLS: Label 38 Exp 0] 60 msec 48 msec 28 msec
  4 10.1.2.1 112 msec *  44 msec
CPE6#

Lab done. If there are any questions, please let me know! :)

Tagged with:  

MPLS VPN lab #4

On May 14, 2010, in CCIE, Dynamips, by Darren

The diagram is the same as my last VPN Lab. Also it uses my MPLs topology found over here: http://mellowd.co.uk/ccie/?p=522

This is the topology for this lab (click for a bigger image):

MPLS4 small MPLS VPN lab #4

  • Customer1 and Customer 2 both have MPLS vpn’s through the ISP core.
  • Customer1 is using OSPF and Customer2 is using EIGRP
  • Customers should have no access to each others networks
  • Customers should be able to reach all their sites from all their sites
  • The ISP wants to monitor the CPE routers via their monitoring server. Create another loopback on each CPE router and give them all a /32 loopback in the 172.16.1.1/24 range – i.e. 172.16.1.1/32 for CPE1, 172.16.1.2/32 for CPE2 and so on
  • Ensure the monitoring router can get to all these /32 routes (and ONLY these /32 routes) – It should not know about any customer routes – CPE routers should only see their OWN loopbacks in the routing table
  • Now enable CPE3 and CPE6 to see each others subnets. All other CPE routers should see no change in their routing tables
Tagged with:  

© 2009-2014 Darren O'Connor All Rights Reserved