↓ Skip to main content
KAZULOG.INFO
  1. Network Articles/
  2. MPLS-VPN Articles/

The OSPF DN bit and the domain tag in MPLS VPN

Table of Contents

The OSPF DN bit and the domain tag in MPLS VPN

When OSPF runs between PE and CE, a route that a PE hands down to a CE can come back to a PE by another path. At a site attached to two PEs (multihoming), the LSA one PE sends down travels through the site and reaches the other PE.

Left alone, that closes a loop: a route received over BGP goes through OSPF and back into BGP. The DN bit (RFC 4576) and the VPN Route Tag (RFC 4577 section 4.2.5.2) are what stop it.

The DN bit is the high-order bit of Options

RFC 4576 took the previously unused high-order bit of the OSPF Options field for this.

The high-order bit of the LSA Options field (a previously unused bit) is used to solve the problem described in the previous section. We refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.

The Options field (RFC 4576 section 4)
+-------------------------------------+
| DN | * | DC | EA | N/P | MC | E | * |
+-------------------------------------+

The rule on the receiving side is this.

When the PE receives, from a CE router, a type 3, 5, or 7 LSA with the DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation. As a result, the LSA is not translated into a BGP route.

Only the route calculation is blocked; the LSA itself is handled normally. Without that in mind the show output is confusing.

Note that the DN bit has no other effect on LSA handling. In particular, an LSA with the DN bit set will be put in the topological database, aged, flooded, etc., just as if DN were not set.

So sitting in the database while never becoming a route is the correct state. It appears in show ospf database and not in show route.

Type 5 LSAs also carry a route tag

Because some implementations do not set the DN bit, RFC 4577 also requires a route tag on Type 5 LSAs (4.2.5.1). It is called the VPN Route Tag.

The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated by a PE router is not redistributed through the OSPF area to another PE router.

The value is derived from the AS number. For a two-byte AS number the default is a 32-bit value whose top four bits are 1101 and whose low 16 bits are the AS number (4.2.5.2).

The default VPN Route Tag (RFC 4577 section 4.2.5.2)
 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For AS 65001 that is 0xD0000000 + 65001 = 3489725929. A PE puts that tag on the Type 5 LSAs it originates, and ignores a Type 5 received from a CE that carries the same tag.

MechanismLSA typesWhat is checked
DN bitType 3 / 5 / 7The high-order bit of Options
VPN Route TagType 5The value of the route tag

A Type 5 LSA is therefore covered by two independent mechanisms. They overlap for backward compatibility, so disabling one leaves the other.

Some loops are not covered

RFC 4577 section 4.2.5.3 is explicit about the limits.

Therefore, extreme care must be taken if there is any mutual redistribution of routes between the OSPF domain and any third routing domain (i.e., not the VPN backbone).

What is covered is the single loop “BGP to OSPF to BGP”. Put RIP in the middle and both the DN bit and the tag are lost, so a PE can no longer tell that the route came back.

The lab

Site 1 is multihomed to PE1 and PE2 through two routers, CE-A1a and CE-A1b. The PE-CE links and the link inside the site are all in area 1. With that, an LSA that PE1 sends down to CE-A1a travels through the site, reaches CE-A1b, and goes on to PE2. The prefix under observation is 10.1.2.1/32 at site 2.

STEPChangeWhat it shows
0Initial statePE2 holds the type 3 LSA from PE1, yet its route comes from BGP (the DN bit is doing its job)
1disable-dn-bit-check on PE2PE2 takes the OSPF route (ospf 100): the DN bit was the only thing stopping it
2Remove disable-dn-bit-check from PE2Back to the BGP route
3A different domain-id on PE3 (site 2 routes become Type 5)The routes become Type 5 and carry the VPN Route Tag (3489725929)
4disable-dn-bit-check on PE2 again (with Type 5 routes)Still the BGP route. With the DN check off, the tag is what stops it
5Undo STEP 3 and 4 (final state)Back to the previous state

The LSA does come back

This is the type 3 LSA CE-A1a received from PE1. The DN flag is in the options.

STEP 0: the type 3 LSA received by CE-A1a
RP/0/RP0/CPU0:CE-A1a#show ospf database summary
Mon Oct 12 04:56:33.868 UTC


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

		Summary Net Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 288
  Options: (No TOS-capability, DC, DN)
  LS Type: Summary Links (Network)
  Link State ID: 10.1.2.1 (Summary Network Number)
  Advertising Router: 100.1.1.1
  LS Seq Number: 80000001
  Checksum: 0xca7a
  Length: 28
  Network Mask: /32
	TOS: 0 	Metric: 2

The database of PE2 holds two LSAs for the same prefix: one advertised by 100.2.2.2 (PE2 itself) and one by 100.1.1.1 (PE1). The second one is the LSA that came back through the site.

STEP 0: the LSDB of PE2 (the VRF OSPF instance)
RP/0/RP0/CPU0:PE2#show ospf 100 vrf CUST-A database summary
Mon Oct 12 04:55:03.928 UTC


            OSPF Router with ID (100.2.2.2) (Process ID 100, VRF CUST-A)

		Summary Net Link States (Area 1)

  LS age: 200
  Options: (No TOS-capability, DC, DN)
  LS Type: Summary Links (Network)
  Link State ID: 10.1.2.1 (Summary Network Number)
  Advertising Router: 100.1.1.1
  LS Seq Number: 80000001
  Checksum: 0xca7a
  Length: 28
  Network Mask: /32
	TOS: 0 	Metric: 2 

  LS age: 198
  Options: (No TOS-capability, DC, DN)
  LS Type: Summary Links (Network)
  Link State ID: 10.1.2.1 (Summary Network Number)
  Advertising Router: 100.2.2.2
  LS Seq Number: 80000001
  Checksum: 0xb58c
  Length: 28
  Network Mask: /32
	TOS: 0 	Metric: 2

Even so, the route PE2 uses comes from BGP. Stored in the database but never used in the route calculation is exactly the state RFC 4576 describes.

STEP 0: 10.1.2.1/32 on PE2
RP/0/RP0/CPU0:PE2#show route vrf CUST-A 10.1.2.1/32
Mon Oct 12 04:55:05.698 UTC

Routing entry for 10.1.2.1/32
  Known via "bgp 65001", distance 200, metric 2, type internal
  Installed Oct 12 04:51:46.482 for 00:03:19
  Routing Descriptor Blocks
    4.4.4.4, from 4.4.4.4
      Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
      Route metric is 2, Wt is 1
  No advertising protos.

Turning the check off makes the PE use it

The DN bit check is disabled on PE2.

STEP 1: configuration committed on PE2
router ospf 100
 vrf CUST-A
  disable-dn-bit-check
 !
!
end

The route is now an OSPF route. OSPF at distance 110 beats iBGP at distance 200, so PE2 starts forwarding towards site 1. That is the entry point of the loop.

STEP 1: 10.1.2.1/32 on PE2
RP/0/RP0/CPU0:PE2#show route vrf CUST-A 10.1.2.1/32
Mon Oct 12 05:01:05.598 UTC

Routing entry for 10.1.2.1/32
  Known via "ospf 100", distance 110, metric 5
  Local Label 24008, type inter area
  Installed Oct 12 04:57:47.280 for 00:03:18
  Routing Descriptor Blocks
    172.16.2.2, from 100.1.1.1, via GigabitEthernet0/0/0/0
      Route metric is 5
  No advertising protos.

Putting the configuration back restores the BGP route.

STEP 2: 10.1.2.1/32 on PE2
RP/0/RP0/CPU0:PE2#show route vrf CUST-A 10.1.2.1/32
Mon Oct 12 05:07:03.664 UTC

Routing entry for 10.1.2.1/32
  Known via "bgp 65001", distance 200, metric 2, type internal
  Installed Oct 12 05:03:46.487 for 00:03:17
  Routing Descriptor Blocks
    4.4.4.4, from 4.4.4.4
      Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
      Route metric is 2, Wt is 1
  No advertising protos.

Type 5 LSAs carry the tag as well

A different domain-id on PE3 turns the routes of site 2 into Type 5.

STEP 3: configuration committed on PE3
router ospf 100
 vrf CUST-A
  domain-id type 0005 value 000000000003
 !
!
end

This is the Type 5 LSA CE-A1b received. Besides the DN flag in the options, the External Route Tag reads 3489725929, the value computed from AS 65001 (0xD0000000 + 65001).

STEP 3: the type 5 LSA received by CE-A1b
RP/0/RP0/CPU0:CE-A1b#show ospf database external
Mon Oct 12 05:15:02.211 UTC


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

		Type-5 AS External Link States

  LS age: 316
  Options: (No TOS-capability, DC, DN)
  LS Type: AS External Link
  Link State ID: 10.1.2.1 (External Network Number)
  Advertising Router: 100.1.1.1
  LS Seq Number: 80000001
  Checksum: 0xec17
  Length: 36
  Network Mask: /32
	Metric Type: 2 (Larger than any link state path)
	TOS: 0 
	Metric: 2 
	Forward Address: 0.0.0.0
	External Route Tag: 3489725929

  Routing Bit Set on this LSA

The packets show both the DN bit and the tag in a single LSA. This is No.2 of the attached STEP 3 capture of the PE1-CE-A1a link.

STEP 3 No.2 LS Update (PE1 to CE-A1a), AS-External-LSA (tshark -V excerpt)
        Number of LSAs: 2
        LSA-type 5 (AS-External-LSA (ASBR)), len 36
            .000 0000 0000 0001 = LS Age (seconds): 1
            0... .... .... .... = Do Not Age Flag: 0
            Options: 0xa0, DN, (DC) Demand Circuits
                1... .... = DN: Set
                .0.. .... = (O) Opaque: Not set
                ..1. .... = (DC) Demand Circuits: Supported
                ...0 .... = (L) LLS Data block: Not Present
                .... 0... = (N) NSSA: Not supported
                .... .0.. = (MC) Multicast: Not capable
                .... ..0. = (E) External Routing: Not capable
                .... ...0 = (MT) Multi-Topology Routing: No
            LS Type: AS-External-LSA (ASBR) (5)
            Link State ID: 10.1.2.1
            Advertising Router: 100.1.1.1
            Sequence Number: 0x80000001
            Checksum: 0xec17
            Length: 36
            Netmask: 255.255.255.255
            1... .... = External Type: Type 2 (metric is larger than any other link state path)
            .000 0000 = TOS: 0
            Metric: 2
            Forwarding Address: 0.0.0.0
            External Route Tag: 3489725929
Download the pcap of the packet in the tshark output above (No.2 LS Update)

The two mechanisms work independently

With the routes now Type 5, the DN bit check is disabled again.

STEP 4: configuration committed on PE2
router ospf 100
 vrf CUST-A
  disable-dn-bit-check
 !
!
end

The configuration is in place.

STEP 4: router ospf 100 on PE2
RP/0/RP0/CPU0:PE2#show running-config router ospf 100
Mon Oct 12 05:19:08.525 UTC
router ospf 100
 vrf CUST-A
  log adjacency changes
  router-id 100.2.2.2
  disable-dn-bit-check
  redistribute bgp 65001
  area 1
   interface GigabitEthernet0/0/0/0
    network point-to-point
   !
  !
 !
!

The route still comes from BGP. With the DN bit ignored, the tag is what stops it.

STEP 4: 10.1.2.1/32 on PE2
RP/0/RP0/CPU0:PE2#show route vrf CUST-A 10.1.2.1/32
Mon Oct 12 05:19:07.881 UTC

Routing entry for 10.1.2.1/32
  Known via "bgp 65001", distance 200, metric 2, type internal
  Installed Oct 12 05:09:48.598 for 00:09:19
  Routing Descriptor Blocks
    4.4.4.4, from 4.4.4.4
      Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
      Route metric is 2, Wt is 1
  No advertising protos.

The same configuration switched the route to OSPF in STEP 1. The only difference is the LSA type. A type 3 LSA is stopped by the DN bit alone; a type 5 LSA is covered by both the DN bit and the tag.

Verification configs and show output

For every STEP the following files were collected from all seven routers, separated per router. The verification config is ..._run.txt (the final state is the one from the last STEP).

FileContents
..._show.txtshow version / show interface description / the OSPF, LDP, BGP and VRF show commands
..._log.txtshow logging limited to that STEP
..._run.txtshow running-config at that STEP (the verification config)
..._ping.txtping and traceroute for that STEP
..._trace.txtshow bgp trace (PEs only)
..._commit.cfgThe configuration actually committed in that STEP (only on routers that changed)

STEP 0: Initial state

Routershowsyslogrunning-configpingtracecommitted config
CE-A1ashowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE-A1bshowlogrunping--
PE3showlogrunpingtrace-
CE-A2showlogrunping--

STEP 1: disable-dn-bit-check on PE2

Routershowsyslogrunning-configpingtracecommitted config
CE-A1ashowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A1bshowlogrunping--
PE3showlogrunpingtrace-
CE-A2showlogrunping--

STEP 2: Remove disable-dn-bit-check from PE2

Routershowsyslogrunning-configpingtracecommitted config
CE-A1ashowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A1bshowlogrunping--
PE3showlogrunpingtrace-
CE-A2showlogrunping--

STEP 3: A different domain-id on PE3 (site 2 routes become Type 5)

Routershowsyslogrunning-configpingtracecommitted config
CE-A1ashowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtrace-
CE-A1bshowlogrunping--
PE3showlogrunpingtracecommit
CE-A2showlogrunping--

STEP 4: disable-dn-bit-check on PE2 again (with Type 5 routes)

Routershowsyslogrunning-configpingtracecommitted config
CE-A1ashowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A1bshowlogrunping--
PE3showlogrunpingtrace-
CE-A2showlogrunping--

STEP 5: Undo STEP 3 and 4 (final state)

Routershowsyslogrunning-configpingtracecommitted config
CE-A1ashowlogrunping--
PE1showlogrunpingtrace-
P1showlogrunping--
PE2showlogrunpingtracecommit
CE-A1bshowlogrunping--
PE3showlogrunpingtracecommit
CE-A2showlogrunping--

Packet captures were taken per STEP.

STEPPE1-CE-A1aPE2-CE-A1b
0pcappcap
1pcappcap
2pcappcap
3pcappcap
4pcappcap
5pcappcap

Related articles