OSPF redistribution into MP-IBGP

[Mahesh Gohil]

Hello Expert,

Topology :    CE1--OSPF area0 --PE1-----P----PE2--OSPF area0---CE2

My understanding while redistributing internal routes (at PE1 when OSPF is used as PE-CE protocol) into MPLS domain is

> If route is advt. from CE1 to PE1 as Type 1 then it should be propogate to other PE2 as is (As type-1 only)    

> At PE2 while redistributing back to OSPF from MP-IBGP it get converted into Summary (Type-3).

WHile doing some testing in GNS as per above network diagram it seen something different.

1- OSPF route (50.50.50.1/32) advt. from CE1 to PE2 as Type-1

PE1#sh ip ospf database router 50.50.50.1

               OSPF Router with ID (10.18.7.2) (Process ID 2)

                Router Link States (Area 0)

  LS age: 833
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 50.50.50.1
  Advertising Router: 50.50.50.1
  LS Seq Number: 80000002
  Checksum: 0x32AE
  Length: 60
  Number of Links: 3

2- When this is redistributes into MP-IBGP it seen as Type-2.

PE1#sh ip bgp vpnv4 vrf DEF 50.50.50.1

BGP routing table entry for 100:1:50.50.50.1/32, version 9

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

Flag: 0x820

  Advertised to update-groups:

     1

  Local

    10.18.7.1 from 0.0.0.0 (202.123.47.1)

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

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

        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.18.7.2:512

      mpls labels in/out 22/nolabel

I assume 2 in this string  "OSPF RT:0.0.0.0:2:0" indicate this route-type is Network type and not Router type.

Can someone coonfirm that this is with GNS only or I am having difficulty in understanding.

One more thing: SInce MPLS backbone is considered as area 0 then why it is converted to summary LSA at other end...

Thanks in advance.

Regards # Mahesh

[John Blakley]

Mahesh,

The type "2" that you're seeing is actually an intra-area route. The RFC states the following:

- OSPF Route Type Extended Community Attribute. This is encoded as
       follows:

         * Type: 0x8000

         * Area Number: 4 bytes, encoding a 32-bit area number. For AS-
           external routes, the value is 0. A non-zero value identifies
           the route as being internal to the OSPF domain, and as being
           within the identified area. Area numbers are relative to a
           particular OSPF domain.

         * OSPF Route Type: 1 byte, encoded as follows:

             ** 1 or 2 for intra-area routes (depending on whether the
                route came from a type 1 or a type 2 LSA -- however this
                difference is not significant to the procedures
                specified herein)

             ** 3 for summary routes

             ** 5 for external routes (area number must be 0)

             ** 7 for NSSA routes.

         * Options: 1 byte. Currently this is only used if the route
           type is 5 or 7. Setting the least significant bit in the
           field indicates that the route carries a type 2 metric.

So, the route is sent as an intra-area (O) to the PE and the PE sets this when redistributing into BGP. The far-side PE will receive the bgp advertisement with this information set and check that the domain ids match in order to advertise it as a summary lsa to the CE on the far end.

As far as why it's redistributed as a summary lsa, the MPLS ospf area 0 is considered a super backbone that rides on top of regular area 0s. The PEs are seen as ABRs to the CE. You can see this by "show ip ospf " on the PE:

R3#sh ip ospf 456

Routing Process "ospf 456" with ID 172.36.0.3

   Domain ID type 0x0005, value 0.0.1.200

....

Connected to MPLS VPN Superbackbone, VRF Customer

It is an area border and autonomous system boundary router

In a normal ospf design, if a redistribution anywhere were to occur, routes are seen as external (type-5 lsas). In order to keep this from happening in an mpls environment, since your redistributing from ospf -> bgp and vice-versa, the designers came up with a way to have these seen, at least, as type-3 lsas without further design consideration on the customer's part. The only way that I'm aware of to have these show up as intra-area routes in your routing table is to create a sham link between the two PEs. This would tunnel the lsas across the mpls cloud and each PE would see all of their routes as intra-area routes instead of inter-area.

Sham links are normally used when a backdoor link exists between 2 locations because those now are preferred due to the lsa type (intra-area on the backdoor link vs intra-area from the PE). Sham links make the routes that traverse the mpls cloud come across as intra-area.

HTH,

John

[Peter Paluch]

John,

You beat me to it! I had my response edited all the morning long, and you got it faster Good work, by the way!

Best regards,

Peter

[John Blakley]

Thank you!

[Mahesh Gohil]

Hi John,

Thanks for detailed reply.

Before posting this question i read this part of rfc and that really confused me.

1 or 2 for intra-area routes (depending on whether the

                route came from a type 1 or a type 2 LSA -- however this

                difference is not significant to the procedures

                specified herein)

What does it mean when rfc say 1 or 2. As a good reader I took meaning link 1 if route is announced as if LSA is Router LSA and 2 if route is announced as if LSA is Network LSA. But the ultimate fact is advertising inter-area when redistributed at destination PE so it doesn't make difference if it is announced as type-1 or type-2 but my curiosity still there...

Let me read peter's response and post some output as he suggested.

Big thanks for also replying other part of query...which i am fully agree.

Regards # mahesh

[Peter Paluch]

Hello Mahesh,

How are you? Haven't seen you here for quite a time. Hope everything's okay!

As John has already provided an excellent reply, I am posting this answer not to correct anything John said, but simply to add here and there the minuscule details I personally feel important to highlight.

1- OSPF route (50.50.50.1/32) advt. from CE1 to PE2 as Type-1
PE1#sh ip ospf database router 50.50.50.1
               OSPF Router with ID (10.18.7.2) (Process ID 2)
                Router Link States (Area 0)
  LS age: 833
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 50.50.50.1
  Advertising Router: 50.50.50.1
  LS Seq Number: 80000002
  Checksum: 0x32AE
  Length: 60
  Number of Links: 3

Unfortunately, this particular output does not say anything about the network 50.50.50.1/32. What you did here is only showing us the LSA-1 with the Link State ID of 50.50.50.1 - but where does the network 50.50.50.1/32 come from is not visible here. It would probably be indicated directly below the line "Number of Links: 3" - a section that is missing in this output.

2- When this is redistributes into MP-IBGP it seen as Type-2.
PE1#sh ip bgp vpnv4 vrf DEF 50.50.50.1
BGP routing table entry for 100:1:50.50.50.1/32, version 9
Paths: (1 available, best #1, table DEF)
Flag: 0x820
  Advertised to update-groups:
     1
  Local
    10.18.7.1 from 0.0.0.0 (202.123.47.1)
      Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.18.7.2:512
      mpls labels in/out 22/nolabel
I assume 2 in this string  "OSPF RT:0.0.0.0:2:0" indicate this route-type is Network type and not Router type.

According to the RFC 4577 Section 4.2.6 this would indeed indicate that the route originated from within Area 0 and was a LSA-2-advertised route. Interesting. Can you post the complete detailed dump of the OSPF LSDB on CE1, i.e. both show ip ospf database router and show ip ospf database network?

One more thing: SInce MPLS backbone is considered as area 0 then why it is converted to summary LSA at other end...

The MPLS Superbackbone is indeed considered as Area 0 - but it is not a true OSPF area. That's the problem - it is not a true area and it does not flood true LSAs from one router to another. What really happens is a redistribution from OSPF into BGP and vice versa whereby prefixes and some additional data about the routes are carried over from OSPF into BGP so that the LSAs can be more closely reconstructed at the other PE. However, the LSAs are not themselves flooded, only selected data from them are added as attributes to the BGP. If the redistribution happened without any additional mechanisms, the routes would be carried over as LSA-5 (external). Because of this BGP/OSPF interoperation, the routes from different sites in the same VPN are carried over as LSA-3 (inter-area). However, if you want the routes from one site to be carried to the other site as intra-area routes, you absolutely need to configure a sham link between the PE routers which is really a targeted OSPF session between the two routers in the appropriate VRF that allows to exchange LSAs directly (plus some tricks similar to virtual links in the LSDB). That is how you actually allow the MPLS Superbackbone to carry intra-area routes.

Best regards,

Peter

[Mahesh Gohil]

Hello Peter,

Yes ! Everything is OK here and hope at your end too.

You are right when I announced a network as Type-1 and it seen as "2" which makes more interesting.

As suggested I am posting four output.

@@@@@@@@   From CE1  @@@@@@@@@@@@@

CE#sh ip ospf database router

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 1322
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.18.7.2
  Advertising Router: 10.18.7.2
  LS Seq Number: 80000002
  Checksum: 0x7780
  Length: 48
  Area Border Router
  AS Boundary Router
  Number of Links: 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 50.50.50.1
     (Link Data) Router Interface address: 10.18.7.2
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.18.7.0
     (Link Data) Network Mask: 255.255.255.252
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

  LS age: 1325
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 50.50.50.1
  Advertising Router: 50.50.50.1
  LS Seq Number: 80000002
  Checksum: 0x32AE
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 50.50.50.1
     (Link Data) Network Mask: 255.255.255.255
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 10.18.7.2
     (Link Data) Router Interface address: 10.18.7.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.18.7.0
     (Link Data) Network Mask: 255.255.255.252
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

CE#sh ip ospf database network

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

@@@@@ From PE1 @@@@@@@@@@@

PE1#sh ip ospf database router    <

            OSPF Router with ID (10.18.7.2) (Process ID 2)

                Router Link States (Area 0)

  LS age: 1406
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.18.7.2
  Advertising Router: 10.18.7.2
  LS Seq Number: 80000002
  Checksum: 0x7780
  Length: 48
  Area Border Router
  AS Boundary Router
  Number of Links: 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 50.50.50.1
     (Link Data) Router Interface address: 10.18.7.2
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.18.7.0
     (Link Data) Network Mask: 255.255.255.252
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

  LS age: 1411
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 50.50.50.1
  Advertising Router: 50.50.50.1
  LS Seq Number: 80000002
  Checksum: 0x32AE
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 50.50.50.1
     (Link Data) Network Mask: 255.255.255.255
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 10.18.7.2
     (Link Data) Router Interface address: 10.18.7.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.18.7.0
     (Link Data) Network Mask: 255.255.255.252
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

PE1#sh ip ospf database network

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

            OSPF Router with ID (10.18.7.2) (Process ID 2)

Guys awaiting your reply.

Regards

Mahesh

[John Blakley]

Mahesh,

I'm still researching this, but here's the latest that I've done and maybe Peter has a better understanding of why this is taking place. I set both of my CE and link from PE to CE as point-to-point links (no DR/BDR elected). I still get the 0.0.0.0:2:0 type:

R1#sh ip ospf 456 database

            OSPF Router with ID (172.14.0.1) (Process ID 456)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count

4.4.4.4         4.4.4.4         936         0x80000036 0x00B1B3 3

172.14.0.1      172.14.0.1      249         0x80000036 0x004F8B 2

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum

172.25.0.0      172.14.0.1      12          0x80000001 0x0091A8

R1#sh ip bgp vpnv4 vrf Customer 4.4.4.4

BGP routing table entry for 1:1:4.4.4.4/32, version 30

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

  Advertised to update-groups:

        1    2

  Local

    172.14.0.4 from 0.0.0.0 (1.1.1.1)

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

      Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000001C80200

        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:172.14.0.1:0

      mpls labels in/out 23/nolabel

As you can see above, the ospf database is from the PE (R1 is the PE). In fact, both type-1 lsa and the type-3 lsa are reporting the same thing.

Here's the interface that leads to the CE:

R1#sh ip ospf 456 inter

FastEthernet0/0 is up, line protocol is up

  Internet Address 172.14.0.1/24, Area 0

  Process ID 456, Router ID 172.14.0.1, Network Type POINT_TO_POINT, Cost: 10

  Transmit Delay is 1 sec, State POINT_TO_POINT

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

No DR, so there would never be a type-2 lsa in an ospf environment. I'm wondering if the :2 is just the way that bgp references the lsa type-1. I created a loopback on my CE and advertised that through eigrp and then redistributed into ospf to get a type-5. The type-5 comes through ok:

R1(config-if)#do sh ip bgp vpnv vrf Customer 44.44.44.44

BGP routing table entry for 1:1:44.44.44.0/24, version 38

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

  Advertised to update-groups:

        1    2

  Local

    172.14.0.4 from 0.0.0.0 (1.1.1.1)

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

      Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000001C80200

        OSPF RT:0.0.0.0:5:1 OSPF ROUTER ID:172.14.0.1:0

      mpls labels in/out 19/nolabel

I then set all LSRs as point-to-point so I have no type-2 lsas anywhere. It was my original belief that the PE, because it was the DR in my original setup, was doing something with the lsa that it was receiving, but this wasn't the case. I still receive the type-2. Running debugs below, you can see that the CE never sends a type-2 to the PE:

*Mar  2 01:28:25.937: OSPF: Send Type 1, LSID 4.4.4.4, Adv rtr 4.4.4.4, age 5, seq 0x80000001 (0)

*Mar  2 01:28:25.937: OSPF: LS_UPD Retransmits: 1 for 172.14.0.1 on FastEthernet0/0

*Mar  2 01:28:25.965: OSPF: received update from 172.14.0.1, FastEthernet0/0

*Mar  2 01:28:25.965: OSPF: Rcv Update Type 1, LSID 4.4.4.4, Adv rtr 4.4.4.4, age 3600, seq 0x80000037

*Mar  2 01:28:25.969: OSPF: we received our own old rtr lsa

*Mar  2 01:28:25.969: Update router LSA 4.4.4.4 4.4.4.4 1 80000037

*Mar  2 01:28:25.969: OSPF: Rate limit LSA generation for 4.4.4.4 4.4.4.4 1

*Mar  2 01:28:26.545: OSPF: Retransmitting update on FastEthernet0/0 to 172.14.0.1 Area 0

*Mar  2 01:28:26.545: OSPF: Send Type 5, LSID 44.44.44.0, Adv rtr 4.4.4.4, age 5, seq 0x80000001 (0)

My conclusion, although I haven't been able to verify this, is that 0.0.0.0:1 doesn't exist (this is where I'd like Peter to chime in). Type 1 and 2 are listed as intra-area routes in the RFC, so maybe there's a reason that 2 is used for both?

HTH,

John

[Giuseppe Larosa]

Hello John,

you have done a very good job testing the scenario.

I agree, at least in Cisco implementation, we see the OSPF route type coded as 2 regardless of type 1,2 LSA.

This has no real effects as the objective on the remote end is to build inter -area routes as LSA type3 in the best case (LSA type5 in the worst case), a sham-link would be needed to make real LSAs to flow over it between the two PE nodes as explained by Peter.

The RFC says just after describing the route-type sub-field:

>> Note that the procedures of Section 4.2.8 do not make any

         distinction between routes types 1, 2, and 3. 

Hope to help

Giuseppe

[Peter Paluch · Accepted solution]

Hello Giuseppe, John and Mahesh,

Giuseppe, I agree with you wholeheartedly. John has done a pretty good job in testing the diverse scenarios. I have also tried to configure a small testing network in Dynamips running 2691 IOS 12.4(15)T13 and I can only confirm what John and Mahesh have observed: Cisco IOS always puts OSPF Route Type extended community attribute equal to 2 for all intra-area networks, both discovered via LSA-1 and LSA-2.  I also agree with Giuseppe that with particular respect to OSPF/BGP interoperation in these scenarios, this makes no difference. It simply seems that Cisco has decided to go with the Route Type set to 2 for all intra-area networks.

So what IOS currently does here is not wrong, just slightly unexpected. The question is - does Cisco IOS ever set the Route Type to 1, and if so, in what scenarios? I was not able to find this out.

Best regards,

Peter

[Mahesh Gohil]

Hello Guys,

Thanks for your efforts on this.

Let me close this thread as this is the way cisco implented the OSPF... If I get chance may be will test it with Juniper and update you the behavior.

Regards # Mahesh