OSPF LSA Type 3 behavior in PE-CE

Hello,

I have a simple OSPF PE-CE topology, where

image

  1. PE1 (OSPF router-id 192.168.20.1) is having an adjacency with CE1 (OSPF router-id 192.168.20.2) in area 55
  2. PE2 (OSPF router-id 192.169.20.1) is having an adjacensy with CE2 (OSPF router-id 192.169.20.2) in area 55
  3. CE1 is having a loopback (11.11.11.11) in area 55
  4. CE2 is having a loopback (22.22.22.22) in area 55

Now, everything is fine for me. I can interpret the OSPF database perfectly except for one thing; The advertising router for LSA ID 22.22.22.22 and 192.169.20.0 is 192.168.20.1 which is PE1!

Shouldn't they be coming from 192.169.20.1 which is PE2 and in the same time the ABR between Area 0 and Area 55 in the other side of the topology?

PE1#sh ip ospf database  

            OSPF Router with ID (192.168.20.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
192.168.20.1    192.168.20.1    49          0x80000001 0x006FD3 0

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
11.11.11.11     192.168.20.1    39          0x80000001 0x00038D
22.22.22.22     192.168.20.1    48          0x80000001 0x007F64
192.168.20.0    192.168.20.1    39          0x80000001 0x0066D9
192.169.20.0    192.168.20.1    48          0x80000001 0x00D2EB

                Router Link States (Area 55)

Link ID         ADV Router      Age         Seq#       Checksum Link count
192.168.20.1    192.168.20.1    44          0x80000006 0x00E9B8 2
192.168.20.2    192.168.20.2    45          0x80000004 0x00BFA8 3

                Summary Net Link States (Area 55)
         
Link ID         ADV Router      Age         Seq#       Checksum
22.22.22.22     192.168.20.1    43          0x80000002 0x007D65
192.169.20.0    192.168.20.1    43          0x80000002 0x00D0EC

Comments



  • That sounds about right.

    The local PE ABR would self-generate the LSA 3's [if PEs are using the same domain-id/process number/route-type 0:2] for propagation to any OSPF non zero peers, and this is once the PEs receives the VPNv4 routes over BGP and post redistribution into OSPF..

    Have you checked the other side what did that show, should be the same


    On 28 Dec 2014, at 18:01, mohm.kamal <[email protected]> wrote:

    Hello,

    I have a simple OSPF PE-CE topology, where

    1. PE1 (OSPF router-id 192.168.20.1) is having an adjacency with CE1 (OSPF router-id 192.168.20.2) in area 55
    2. PE2 (OSPF router-id 192.169.20.1) is having an adjacensy with CE2 (OSPF router-id 192.169.20.2) in area 55
    3. CE1 is having a loopback (11.11.11.11) in area 55
    4. CE2 is having a loopback (22.22.22.22) in area 55

    Now, everything is fine for me. I can interpret the OSPF database perfectly except for one thing; The advertising router for LSA ID 22.22.22.22 is 192.168.20.1 which is PE1! Shouldn't it be coming from 192.169.20.1 which is PE2 and in the same time the ABR between Area 0 and Area 55 in the other side of the topology?

    PE1#sh ip ospf database  

                OSPF Router with ID (192.168.20.1) (Process ID 1)

                    Router Link States (Area 0)

    Link ID         ADV Router      Age         Seq#       Checksum Link count
    192.168.20.1    192.168.20.1    49          0x80000001 0x006FD3 0

                    Summary Net Link States (Area 0)

    Link ID         ADV Router      Age         Seq#       Checksum
    11.11.11.11     192.168.20.1    39          0x80000001 0x00038D
    22.22.22.22     192.168.20.1    48          0x80000001 0x007F64
    192.168.20.0    192.168.20.1    39          0x80000001 0x0066D9
    192.169.20.0    192.168.20.1    48          0x80000001 0x00D2EB

                    Router Link States (Area 55)

    Link ID         ADV Router      Age         Seq#       Checksum Link count
    192.168.20.1    192.168.20.1    44          0x80000006 0x00E9B8 2
    192.168.20.2    192.168.20.2    45          0x80000004 0x00BFA8 3

                    Summary Net Link States (Area 55)
             
    Link ID         ADV Router      Age         Seq#       Checksum
    22.22.22.22     192.168.20.1    43          0x80000002 0x007D65
    192.169.20.0    192.168.20.1    43          0x80000002 0x00D0EC




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Your reply is confirming what is already happening (which I find incorrect).

    What I mean is:

    1- PE2 which with OSPF router-id 192.169.20.1 will generate and receive LSA-1/2 in area 55 from the CE2.

    So, in Area 55, there will be two entries:

    192.169.20.1
    192.169.20.2

    2- Now, PE2 (which have another interface in the MPLS network, it is considered an ABR), will translate the LSA-1/2 to LSA-3 and advertise it into the MPLS network as the ADV router.

    3- PE1, will receive the VPNv4 updates from PE2, encoded with some extended communities like the OSPF router-id and will reconstruct the LSA-3 again to be flooded into area 55 in the other side.

    4- PE1 should PRESERVE the router-id of the PE2 (ABR) so that the LSA-3's ADV router should be PE2 router not PE1

    Am I correct?



  • No because it's the job of every ABR to self-generate the type 3s for flooding into any connected non zero areas once received over area 0.

    PE1 which is connected to the super backbone has to re-construct the LSA's from VPNv4 BGP redistribution, it does this by first cross checking the domain-id (process number) and route-type 0:2 is the same on both PEs indicating LSA build will be OIA LSA 3.

    The behaviour is not any different to if you had two ABRs in Area 0 where they would expect OIA's from each in order to self-generate their own for flooding into their respective non zero areas.

    *in regular OSPF Loop prevention on type 3s mean do not accept type 3s LSAs from non-backbone areas **caveat here is if ABR has no adjacency over area 0 then it can accept type 3s as their is no risk of a loop

    **in MPLS VPN Loop prevention on type 3 LSAs when OSPF is the PE-CE RP is by PE setting the DN bit on any routes it sends to CE thus they are not considered for further redistribution in a dual homed scenario




    On 30 Dec 2014, at 15:28, mohm.kamal <[email protected]> wrote:

    Your reply is confirming what is already happening (which I find incorrect).

    What I mean is:

    1- PE2 which with OSPF router-id 192.169.20.1 will generate and receive LSA-1/2 in area 55 from the CE2.

    So, in Area 55, there will be two entries:

    192.169.20.1
    192.169.20.2

    2- Now, PE2 (which have another interface in the MPLS network, it is considered an ABR), will translate the LSA-1/2 to LSA-3 and advertise it into the MPLS network as the ADV router.

    3- PE1, will receive the VPNv4 updates from PE2, encoded with some extended communities like the OSPF router-id and will reconstruct the LSA-3 again to be flooded into area 55 in the other side.

    4- PE1 should PRESERVE the router-id of the PE2 (ABR) so that the LSA-3's ADV router should be PE2 router not PE1

    Am I correct?




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Sorry for wasting your time Sukhjit, my question was misleading.

    The OSPF database of PE1 shouldn't include Area 0 from the early begining, as the only area I have configured with area 55.

    However, I have found that OSPF area 0 was (Inactive) due to an erroneously configured "sham-link in area 0" before.

    Now after removing the sham-link command and resetting the process, only area 55 is now shown in the database.

    Again, thanks for your usual help.

Sign In or Register to comment.