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:  

MPLS VPN lab #3

On March 30, 2010, in CCIE, by Darren

This lab will test a Central Services MPLS VPN.

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):

MPLS2 small 150x150 MPLS VPN lab #3

  • 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 is now providing a mail relay for it’s customers to use. Ensure that all customers can get to the 10.200.1.1/24 subnet through their vpn’s, but they must still be seperated from each other.
Tagged with:  

Checking optical interface type

On March 5, 2010, in Uncategorized, by Darren

Sometimes you log onto a switch remotely and need to know what kind of optical interface the switches actually have plugged in. It’s pretty simple:

Switch#show interface gi1/0/25 capabilities
GigabitEthernet1/0/25
Model:                 WS-C3750G-24TS
Type:                  1000BaseLX SFP
Speed:                 1000
Duplex:                full
Trunk encap. type:     802.1Q,ISL
Trunk mode:            on,off,desirable,nonegotiate
Channel:               yes
Broadcast suppression: percentage(0-100)
Flowcontrol:           rx-(off,on,desired),tx-(none)
Fast Start:            yes
QoS scheduling:        rx-(not configurable on per port basis),
tx-(4q3t) (3t: Two configurable values and one fixed.)
CoS rewrite:           yes
ToS rewrite:           yes
UDLD:                  yes
Inline power:          no
SPAN:                  source/destination
PortSecure:            yes
Dot1x:                 yes

The most important things here is that you can see I have a 1000BaseLX SFP installed.

Tagged with:  

MPLS VPN lab #2

On February 26, 2010, in CCIE, by Darren

This VPN lab will test intranet and extranet MPLS VPN’s.

    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 lab topology again:

    MPLS1 150x150 MPLS VPN lab #2

    • 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
    Tagged with:  

    © 2009-2014 Darren O'Connor All Rights Reserved