INE WorkBook LAB:4.12 MPLS L3 VPN and OSPF Domain-ID

Hi Mates,

this LAB is confusing me very much , I think there is something wrong with the lab description :

 

first lets check the required tasks for configuring OSPF as PE-CE routing protocol below :

Configure OSPF routing for the VRF as follows:
o Use Process-ID 100.
o Enable OSPF Area 0 between R1 & R2.
o Enable OSPF Area 0 between XR1 & XR2.
o Enable OSPF Area 120 between R1 & XR2.
o Advertise the Loopback0 network of R1 into OSPF Area 1.
o Advertise the Loopback0 network of XR2 into OSPF Area 20.
o Redistribute the Loopback1 networks of R1 and XR2 into OSPF.
o Modify the link between R1 and XR2 to have an OSPF cost of 100.
o Configure the OSPF Domain-ID on R2 and XR1 for the VRF aware process as
type 0005 with value 0x000000640200.

 

here is the topology , I Put the required points on the topology to be more clear

INE-L3VPN-Backdoor-Topology

what is confusing me is in page 302 at the top of the page there is the below note :

When R1 and XR2 make their path selection decision, they now see two possible paths to
each other’s Loopback0 networks, one via the MPLS L3VPN PE and one via the backdoor link.

 

and as per my  knowledge this is not true because R1 loopback 0 is in area 1 and XR-1 loopback 0 is in area 20 so for any traffic to pass between those to loopbacks it must use area 0 which in our case the route to the MPLS-VPN backbone not the backdoor link which is in area 120 that sounds more logic.

and to do more confirmation I increased the cost of the link between R1 and R2 to the ospf max cost and found that R1 still prefer that link , I also shut it down and the route to to XR1 loopback didn't show up in the routing table.

 

so did any one noticed that mistake???

 

Comments

  • Hi monstager,

     

    I came across the same problem as you did, there is a need for virtual link between R1 and XR2 under the area 120. That way you will accomplish the required connectivity.

     

     

  • yes you are right this exactly the way that I thought of :)

  • I came across the same problem as you did, there is a need for virtual link between R1 and XR2 under the area 120. That way you will accomplish the required connectivity.

    You are exactly right.  If the MPLS link goes down there is loss of area 0 backbone connectivity.  The virtual-link certainly fixes this.  I'm wondering if there is any errata posted for the workbook solutions.

    -v10d

     

  • I came across the same problem as you did, there is a need for virtual link between R1 and XR2 under the area 120. That way you will accomplish the required connectivity.

    I'm not convinced that a VL is the end all fix to this.  When I created a VL between R1 and XR2 via thei area 120, the routes then are always preferred over the backdoor link, regardless of cost.  Even though the route learned each way is an Inter-area route.

    With backdoor link shut down:

     

          10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
    O IA 10.1.20.0/24 [110/102] via 10.1.2.2, 00:00:04, FastEthernet0/0
    O IA 10.19.20.0/24 [110/2] via 10.1.2.2, 00:00:04, FastEthernet0/0
    O E2 10.20.20.20/32 [110/20] via 10.1.2.2, 00:00:04, FastEthernet0/0
    20.0.0.0/32 is subnetted, 1 subnets
    O IA 20.20.20.20 [110/3] via 10.1.2.2, 00:00:04, FastEthernet0/0

    OSPF Router with ID (1.1.1.1) (Process ID 100)

    Summary Net Link States (Area 0)

    Routing Bit Set on this LSA in topology Base with MTID 0
    LS age: 88
    Options: (No TOS-capability, DC, Downward)
    LS Type: Summary Links(Network)
    Link State ID: 20.20.20.20 (summary Network Number)
    Advertising Router: 10.1.2.2
    LS Seq Number: 80000001
    Checksum: 0xFD5D
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 2

    LS age: 3 (DoNotAge)
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 20.20.20.20 (summary Network Number)
    Advertising Router: 20.20.20.20
    LS Seq Number: 80000002
    Checksum: 0x9BFE
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1


    Summary Net Link States (Area 120)

    LS age: 12
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 20.20.20.20 (summary Network Number)
    Advertising Router: 1.1.1.1
    LS Seq Number: 80000001
    Checksum: 0xEDF7
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 3


     

    With the backdoor link up:

     

    R1#show ip ospf neighbor 

    Neighbor ID Pri State Dead Time Address Interface
    20.20.20.20 0 FULL/ - 00:00:34 10.1.20.20 OSPF_VL0
    10.1.2.2 1 FULL/DR 00:00:39 10.1.2.2 FastEthernet0/0
    20.20.20.20 1 FULL/DR 00:00:36 10.1.20.20 FastEthernet1/0


    10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
    O 10.19.20.0/24 [110/101] via 10.1.20.20, 00:00:09, FastEthernet1/0
    O E2 10.20.20.20/32 [110/20] via 10.1.20.20, 00:00:09, FastEthernet1/0
    20.0.0.0/32 is subnetted, 1 subnets
    O IA 20.20.20.20 [110/101] via 10.1.20.20, 00:00:04, FastEthernet1/0



    R1#show ip ospf database summary 20.20.20.20

    OSPF Router with ID (1.1.1.1) (Process ID 100)

    Summary Net Link States (Area 0)

    Routing Bit Set on this LSA in topology Base with MTID 0
    LS age: 1 (DoNotAge)
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 20.20.20.20 (summary Network Number)
    Advertising Router: 20.20.20.20
    LS Seq Number: 80000002
    Checksum: 0x9BFE
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1

    Summary Net Link States (Area 120)

    LS age: 1770
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 20.20.20.20 (summary Network Number)
    Advertising Router: 20.20.20.20
    LS Seq Number: 80000001
    Checksum: 0x9DFD
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1

     

     

    So I'm not sure what the fix is then since they would have an area 0 connection via the backdoor link.  Then what, sham-link?

    -v10d

  • Hi all,

     

    what about Making the virtiual link between R1 and  XR1 instead of XR2 , I will try it and update you.

  • This wont help you much, since as soon as you shut your link from R1 to R2 you will break the are 0 making it discontiguous again.




    On Tue, Oct 29, 2013 at 8:13 AM, mostager <[email protected]> wrote:

    Hi all,

     

    what about Making the virtiual link between R1 and  XR1 instead of XR2 , I will try it and update you.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • what about Making the virtiual link between R1 and  XR1 instead of XR2 , I will try it and update you.

    I don't think that will work and I don't think there is a solution to this problem.  

    Everything per the INE solution works until you take into account you lose connectivity to the MPLS network.  When that happens you lose connectivity between area 1 and area 20.  Without a virtual-link they can no longer communicate. 

    If you establish a virtual-link over area 120, you then break path selection and the intra-area routes will prefer the backdoor connection, ragardless of cost.

    So I'm stumped.

    -v10d

  • Hi Void,

    Don't give up quickly bro , every thing has a solution I got the reason for that issue right now :

    when you create a virtual link between R1 and XR1 the route to XR2 loopback0 is still learned as Interarea not intera-area but the problem is the LSA is propagated from R1 to R2 which make R2 to prefer the OSPF route rather than the BGP route learned from XR1 you can note this from the below

     

    R1#sh ip route 20.20.20.20
    Routing entry for 20.20.20.20/32
      Known via "ospf 1", distance 110, metric 101, type inter area
      Last update from 10.1.20.20 on Ethernet1/0, 00:07:38 ago
      Routing Descriptor Blocks:
      * 10.1.20.20, from 20.20.20.20, 00:07:38 ago, via Ethernet1/0   -->here the route is learned from the backdoor
          Route metric is 101, traffic share count is 1

     

    now let's look at the route on R2 :

    R2#sh ip rou vrf VPN_A 20.20.20.20      

    Routing Table: VPN_A
    Routing entry for 20.20.20.20/32
      Known via "ospf 100", distance 110, metric 111, type inter area
      Redistributing via bgp 100
      Advertised by bgp 100 match internal external 1 & 2
      Last update from 10.1.2.1 on Ethernet1/0, 00:04:28 ago
      Routing Descriptor Blocks:
      * 10.1.2.1, from 20.20.20.20, 00:04:28 ago, via Ethernet1/0 -->it prefered the ospf route to R1
          Route metric is 111, traffic share count is 1

     

    so the simplest solution for this problem is to increase the Admin distance of the ospf proccess on the PE to a value greater than BGP distance so let's check now :

     

    R2#sh ip rou vrf VPN_A 20.20.20.20

    Routing Table: VPN_A
    Routing entry for 20.20.20.20/32
      Known via "bgp 100", distance 200, metric 65, type internal
      Redistributing via ospf 100
      Advertised by ospf 100 subnets
      Last update from 19.19.19.19 00:00:04 ago
      Routing Descriptor Blocks:
      * 19.19.19.19 (default), from 3.3.3.3, 00:00:04 ago
          Route metric is 65, traffic share count is 1
          AS Hops 0
          MPLS label: 33
          MPLS Flags: MPLS Required
    R2#

    from the above output you can note that the BGP route is now selected and lets check on R1 now :

     

    R1#sh ip route 20.20.20.20
    Routing entry for 20.20.20.20/32
      Known via "ospf 1", distance 110, metric 75, type inter area
      Last update from 10.1.2.2 on Ethernet0/0, 00:01:10 ago
      Routing Descriptor Blocks:
      * 10.1.2.2, from 10.10.10.2, 00:01:10 ago, via Ethernet0/0 --> now it prefer the MPLS-VPN backbone route as it's the lowest metric of both inter-area routes.
          Route metric is 75, traffic share count is 1

     

    now i'm going to shut the link to between R1 and R2and see what will happen :

    R1#sh ip route 20.20.20.20
    Routing entry for 20.20.20.20/32
      Known via "ospf 1", distance 110, metric 101, type inter area
      Last update from 10.1.20.20 on Ethernet1/0, 00:00:01 ago
      Routing Descriptor Blocks:
      * 10.1.20.20, from 20.20.20.20, 00:00:01 ago, via Ethernet1/0 -->now the backdoor link  is used
          Route metric is 101, traffic share count is 1

     

    finally please note the metic of the ospf  route in both cases you will find it 75 before I shut the link between R1 and R2 and 101 after shuting it which confirm that it's only amatter of metric in this case.

     

    hope this is clear to every one.

     

  • so the simplest solution for this problem is to increase the Admin distance of the ospf proccess on the PE to a value greater than BGP distance so let's check now :

     

    Thanks fo rthe tip and that works, however you don't want to change the admin distance for the whole process, only for those prefixes you want to prefer via BGP rather than OSPF.   If you don't then you'll end up prefering the prefix that should go over the backdoor link as well.  This worked for me:

    R2:

    access-list 1 permit 20.20.20.20
    access-list 1 permit 1.1.1.1 

    router ospf 100 vrf VPN_A
    distance 201 0.0.0.0 255.255.255.255 1

     

    and similarly on XR1...

     

    -v10d

Sign In or Register to comment.