14.7 PE - CE with OSPF

i am seeing something that I am not understanding with this task and would like some clarification.

It is my understanding that when a route is redistributed into OSPF from MP-BGP the LSA that is generate is a type-3 LSA and the down bit is set.  So if both CE routers have the same process ID (Domain ID), each router should see the route in the routing table as O IA.  Either I am not getting expected results, or I am missing something.

Before doing any summarization in this task, I am seeing SW2s routes as E2 routes in SW1 routing table and I am seeing SW1s routes as O IA in SW2s routing table.  Is that right?  Shouldn't I be seeing SW2 route as O IA?  Keep in mind that SW2 is not participating in VRF routing, but SW1 is.

Please note the below output.

SW1

 

Rack1SW1#show ip route vrf VPN_A | b Gate

Gateway of last resort is not set

 

     155.1.0.0/24 is subnetted, 2 subnets

O E2    155.1.58.0 [110/1] via 155.1.67.6, 00:09:38, Vlan67

C       155.1.67.0 is directly connected, Vlan67

 

Rack1SW1#sh ip protocols vrf VPN_A

Routing Protocol is "ospf 100"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Router ID 155.1.67.7

  It is an area border router

  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

  Maximum path: 4

  Routing for Networks:

    0.0.0.0 255.255.255.255 area 1

 Reference bandwidth unit is 100 mbps

  Routing Information Sources:

    Gateway         Distance      Last Update

    155.1.67.6           110      00:10:48

  Distance: (default is 110)

R6

 

Rack1R6#show bgp vpnv4 unicast vrf VPN_A 155.1.67.0

BGP routing table entry for 100:1:155.1.67.0/24, version 70

Paths: (1 available, best #1, table VPN_A)

  Advertised to update-groups:

        1

  Local

    0.0.0.0 from 0.0.0.0 (150.1.6.6)

      Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000640200 

        OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:155.1.67.6:0

      mpls labels in/out 25/aggregate(VPN_A)

 

Rack1R6#show ip protocols vrf VPN_A

Routing Protocol is "ospf 100"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Router ID 155.1.67.6

  It is an area border and autonomous system boundary router

  Redistributing External Routes from,

    bgp 100, includes subnets in redistribution

  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

  Maximum path: 4

  Routing for Networks:

    0.0.0.0 255.255.255.255 area 1

 Reference bandwidth unit is 100 mbps

  Routing Information Sources:

    Gateway         Distance      Last Update

 

R5

 

Rack1R5#show bgp vpnv4 unicast vrf VPN_A 155.1.67.0

BGP routing table entry for 100:1:155.1.67.0/24, version 13

Paths: (1 available, best #1, table VPN_A)

  Not advertised to any peer

  Local

    150.1.6.6 (metric 66) from 150.1.4.4 (150.1.4.4)

      Origin incomplete, metric 0, localpref 100, valid, internal, best

      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000640200 

        OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:155.1.67.6:0

      Originator: 150.1.6.6, Cluster list: 150.1.4.4

      mpls labels in/out nolabel/25

 

Rack1R5#show ip protocols vrf VPN_A

Routing Protocol is "ospf 100"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Router ID 155.1.58.5

  It is an area border and autonomous system boundary router

  Redistributing External Routes from,

    bgp 100, includes subnets in redistribution

  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

  Maximum path: 4

  Routing for Networks:

    0.0.0.0 255.255.255.255 area 1

 Reference bandwidth unit is 100 mbps

  Routing Information Sources:

    Gateway         Distance      Last Update

    150.1.8.8            110      02:35:29

  Distance: (default is 110)

SW2

 

Rack1SW2#sh ip route ospf

     155.1.0.0/24 is subnetted, 4 subnets

O IA    155.1.67.0 [110/2] via 155.1.58.5, 00:25:22, Vlan58

 

Rack1SW2#show ip protocols

Routing Protocol is "ospf 100"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Router ID 150.1.8.8

  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

  Maximum path: 4

  Routing for Networks:

    0.0.0.0 255.255.255.255 area 1

 Reference bandwidth unit is 100 mbps

  Routing Information Sources:

    Gateway         Distance      Last Update

    155.1.58.5           110      00:25:52

  Distance: (default is 110)

 

 

 

Any clarification would be helpful.

Thanks,

Erick

 

 

 

 

 

Comments

  • Hi Erick,

    thanks for your question, it had me thinking much more in debt about it than I was when I did the task (and had to look at the solution guide)

    seems the key here is the part where routes received from BGP as summary LSA type 3 on an interface belonging to a vrf will get dropped because of the down bit being set in them. causing a routing black-hole in case a multi vrf router. (ofcourse preventing loops when dual homing ISP's)

    to solve this acroding to the documentation you can use the OSPF process command: capability vrf-lite on (IOS) CE routers (disables the down bit check)

    or in case of catalist OS or older versions IOS you set the PE routers OSPF process command: domain-id to diffrent values (makes the LSA summary advertisements of type 5 instead of type 3 which does not have the down bit set)  this will than show the routes as E instead of IA

    hope this helps (and is complete, please add or correct if needed) cheers Richard

     

  • Hi Richard.

    Here is what I understand about the down bit and the capability VRF lite feature.  We'll take this particual example task.  When R5 redistributes the 155.1.58.0 VPNv4 prefix into MP-BGP, it will set the domain ID.  When R6 receives the 155.1.58.0 VPNv4 prefix and redisributes it into OSPF, it will check the domain ID to see whether or not the route should be redistributed with a type 5 LSA or a type 3.  If the domain ID matches, the LSA will be type 3. If not, it will be a type 5 LSA.  Also, when R6 redistributes the VPNv4 prefix into OSPF on SW1, it will set the down bit if it's redistributing a type 3 LSA.  This is to prevent loops if either R5 or R6 receive the LSA back with the down bit set from SW1 or SW2.  I was expecting to see a type 3 LSA inside VPN_A on SW1 with the down bit set in the LSA options field, but I'm seeing a type 5 LSA even though the domain ID fields match and I'm still not sure why.

    Thanks for your response. I do appreciate any help I can get to understand this behavior.

    Erick

  • Ok. I went back though the ATC for MPLS VPN routing OSPF with the down bit.  So things still don't make sense.  SW1 is running VRF-aware OSPF, but not a PE.  SW1 should not be installing the 155.1.58.0 into the VPN_A routing table.  However, it is being installed as a external E2 route.  Oh well.  I need to move on.  I'll have to come back to this later if there is time.

  • OSPF capability vrf lite is not merely for ignoring DN bit. We have discussed about this in this thread: http://ieoc.com/forums/t/13686.aspx?PageIndex=1

    Cmd Ref says "When the OSPF process is associated with the VRF, several checks are performed when link-state advertisements (LSAs) are received." Capability vrf lite is for ignoring these checks, telling OSPF that it is actually not connected to MPLS superbackbone.
    http://www.cisco.com/en/US/docs/ios/iproute_ospf/command/reference/iro_osp1.html#wp1012376

    Read the thread for more info.

    HTH

  • Hi Erick,

    I see what you mean, I was under the assuption you had changed the domain ID for this task and therefore ended up with the E route. If you did not than it indeed sounds strange you dont get the type 3 LSA as expected from the PE. ill lab it up next week to see what I get, you did check on IOS bugs right? (assuming you are not on the INE rack)

    cheers Richard

     

     

  • Hi Alexander,

    thanks for the info, I did understand correctly that the vrf lite (or setting diffrent domain ID's) in this specific task were used for ignoring the down bit right? (I do understand it does more than just that, but tried to find the reason for using this workaround in this specific task)

    regards Richard

     

  • Hi guys.

    I am going to circle back to this.  While I didn't get the results I expected, I was able to solidify some concepts about the feature and the operation of OSPF in this particular scenario. It wasn't a total loss because I was able to confirm a few things. I went back and watched the ATC to help out.  I'm sure this will come up again in the volume II workbooks somewhere.

    Thanks!

    Erick

  • Hi guys.

    I'm sure this will come up again in the volume II workbooks somewhere.

    Thanks!

    Erick

     

    yes, check out vol 2 lab 7 ticket 1 ;)

  • thanks for the info, I did understand correctly that the vrf lite (or setting diffrent domain ID's) in this specific task were used for ignoring the down bit right? (I do understand it does more than just that, but tried to find the reason for using this workaround in this specific task)

     

     


    Hi Richard,

     

    I was making my point that capability vrf lite is not only for ignoring DN bit :)

     

    I don't have the WB in front of me right now, but if I remember it correctly, for this task we can use either capability vrf lite or using different domain ID.

     

    happy studying!

  • hi Alexander,

    all clear to me than, thanks for the input

    cheers

  • Ok. I went back though the ATC for MPLS VPN routing OSPF with the down bit.  So things still don't make sense.  SW1 is running VRF-aware OSPF, but not a PE.  SW1 should not be installing the 155.1.58.0 into the VPN_A routing table.  However, it is being installed as a external E2 route.  Oh well.  I need to move on.  I'll have to come back to this later if there is time.

    yes, i did the configuration, then i removed the domain-id yes all the routes are being installed as E2. i tried resetting the OSPF process, re-did partial configuration. still they would install as E2 (im running this on GNS3). anyways. i did loads of reading as you did, and i understand the point of the command. strange i couldn't see it in my scenario. 

Sign In or Register to comment.