Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding IS-IS Flood Reflectors


Benefits of Flood Reflectors

  • Flooding path reduction—Reduces the redundancy in flooding paths as it limits flooding of link-state packet data units (PDUs) and enhances the efficiency of IS-IS updates in large fabric topologies.

  • Fast convergence—Optimizes IS-IS routing protocol convergence in large networks.

  • Network efficiency—Enhances network efficiency rapidly by leveraging the pre-existing capability to establish IS-IS adjacencies over flexible tunnel interfaces (FTI).

  • Scalability—Provides better scalability for the Level 2 topologies in an IS-IS network. Only the routers configured as flood reflectors participate in flood reflection. This leverages incremental deployment of scalable Level 1 transit areas in an existing network, without the necessity of upgrading other routers in the network.

Flood Reflectors Overview

A flood-reflector adjacency as defined in the draft-przygienda-flood reflector-00 is built for the purpose of reflecting flooding information. The flood reflectors participate in the IS-IS control plane without being used in the forwarding plane. This is a purely local operation on the Level 1/Level 2 ingress device as it does not require replacing or modifying any routers not involved in the reflection process.

IS-IS flood reflection enables creation of flood-reflection topologies where Level 1 areas provide transit forwarding for Level 2 destinations within a Level 2 topology. This is accomplished by creating Level 2 flood-reflection adjacencies within each Level 1 area. The Level 2 flood-reflection adjacencies are used to flood Level 2 link-state PDUs that are used in the Level 2 shortest-path-first (SPF) computation. However, they are not used for forwarding. This arrangement provides better scalability for the Level 2 topology.

To establish IS-IS adjacency for flood reflection, we designate flexible tunnel interfaces (FTI) as flood- reflector interfaces. These tunnels utilize UDP encapsulation.

Junos OS Implementation of Flood Reflectors


In the Junos OS implementation, the basic flood reflector forwarding functionality enables us to identify an IS-IS interface as a flood-reflector interface on a per-level basis. This modifies the Level 2 route computation to not install any next hops that uses a flood-reflector interface as a next hop.

If this process results in at least one remaining next hop that uses a normal interface, then the modified Level 2 route is installed. If the process of removing flood-reflector next hops from the Level 2 route results in a Level 2 route that has no next hops, then the installation of the Level 2 route is suppressed completely. Because the installation of the usual IS-IS Level 2 route is suppressed, we rely on the presence of an IS-IS Level 1 route to carry the traffic to the flood-reflector client on the Level 2 shortest path for this prefix.

Flood reflection does not load balance traffic on Level 2 and Level 1 routes. Suppose a Level 2 route has 10 equal-cost next hops and one of those next hops uses a flood-reflector interface, then all the next hops are removed from the Level 2 route. Even though there is a path available in the Level 2 domain, it suppresses all the Level 2 routes and relies on the IS-IS Level 1/ Level 2 inter-area route to carry the traffic. The Junos OS implementation does not use a Level 2 route until the Level 2 route has at least one flood-reflector next hop.


Ensure that you have configured the Level 1 routes to prevent disruption of traffic.

Flood-Reflection Adjacency Formation

The Flood-Reflection TLV as defined in draft-przygienda-flood reflector-00 is a new top-level TLV that represents the flood-reflector cluster that a given router interface is configured to participate in. It also indicates whether the router is configured to play the role of either the flood reflector or the flood-reflector client. For more information about the flood reflection TLV, see draft-przygienda-flood-reflector-00

Flood reflection implements the advertisement and receipt of the flood-reflection adjacency sub-TLV as defined in draft-przygienda-lsr-flood-reflection-01. The flood reflection adjacency sub-TLV is installed in the traffic engineering database (TED) and is included in the Level 2 area flooded LSPs. It indicates that a given adjacency is a flood-reflector adjacency and serves the following purposes:

  • It enables RSVP on the same router to recognize that a link in the TED represents a flood-reflection adjacency.

  • It also helps in potential metric-independent loop prevention mechanism. That is, it enables a device participating in flood reflection to have awareness of remote flood-reflection links to detect loops.


The external Level 2 devices that do not participate in flood reflection do not advertise or receive the flood-reflection adjacency sub-TLV.

Flood Reflector Sample Topology

Figure 1 depicts a flood-reflector topology that allows R4 to send traffic to R5 utilizing the Level 1 fabric shown at the top of the figure without being exposed to any Level 1 advertisements.

Figure 1: Flood Reflector Sample Topology
Flood Reflector Sample Topology
  • R6 is the flood reflector. R0, R1, R2, R3 are flood-reflector clients and have FTI tunnels to R6. All of the FTI tunnels have metric 10 and are configured as flood-reflector interfaces. R0, R1, R2, R3 are configured to redistribute Level 2 routes into Level 1 as Level 1/Level 2 inter-area routes. This redistribution into Level 1 only occurs if the Level 2 route is installed in the route table.

  • R2 advertises in Level 1 link-state PDUs with a cost of 10 as it has installed the Level 2 route for over the physical interface from R2 to R5.

  • Under normal circumstances, if the FTI tunnel from R3 to R6 was not configured as a flood reflector interface, then R3 would also advertise into Level 1 link-state PDUs with a cost of 30.

    However, as the FTI tunnel from R3 to R6 is configured as a flood reflector-interface, the Level 2 route is suppressed in favor of the Level 1 route for being advertised by R3 into Level 1 link-state PDUs. The same logic applies to R0 and R1. Therefore, only R2 advertises in Level 1 link-state PDUs.

  • When we trace a packet destined for from R4 to R5, R4 only sees Level 2 advertisements. Therefore, it determines that the Level 2 shortest path to reach is R4-R0-R6-R2-R5. R4 sends the packet to R0.

  • At R0, the shortest Level 2 path to reach is R0-R6-R2-R5 (with cost 30). However, as the next hop for this Level 2 route uses a flood-reflector interface, the Level 2 route is suppressed. Instead, the Level 1 route to reach R2 is used.

  • R7, R8, R9, R10 use the Level 1 route to reach R2 as they do not participate in Level 2. R6 uses the Level 1 route because all of the Level 2 routes on R6 use FTI tunnels configured as Level 2 flood-reflector interfaces, so all Level 2 routes are suppressed at R6.

  • At R2, the Level 2 internal route for using the physical Level 2 interface to R5 is installed and used.

Requirements for Configuring Flood-reflector Interfaces

The following requirements are enforced through IS-IS advertisements by including information about the role of the router (flood reflector or flood-reflector client) as well as the cluster-identifier (ID) in the IS-IS Hello messages:

  • A flood-reflector client must not be allowed to connect to another flood-reflector client over a flood-reflector interface.

  • A flood-reflector client must be allowed to connect to multiple flood reflectors over flood-reflector interfaces.

  • A flood reflector must not be allowed to connect to another flood reflector over a flood reflector-interface.

  • Adjacency between a flood reflector and a flood reflector client can be established only if they have the same cluster ID.

  • A flood reflector for a given level (Level 1, Level 2, or Level 1/Level 2) must not have any IS-IS interfaces at a given level that are not flood-reflector interfaces. This can be validated with commit check without any advertisements.

Best Practice

We recommend configuring the Level 2 tunnels to use the source and destination loopback addresses that are only advertised into Level 1. Different loopback addresses are advertised into Level 2. Otherwise, you might encounter a scenario where the edge router in the fabric becomes disconnected from the Level 1 fabric, but it is still able to form a flood- reflector adjacency by tunneling over links in the Level 2 topology.


Flood reflection carries with it the potential to disrupt traffic and routing loops in certain topologies where it is not configured properly.

Routing Loops

When using flood reflection, it is possible to create topologies that cause routing loops. Figure 2 depicts a looping topology sample.

Figure 2: Looping Topology
Looping Topology

The only difference between the topologies in Figure 1 and Figure 2 is the missing the FTI tunnel between R1 and R6 in Figure 2.

Other Factors that Cause Routing Loops

Besides the missing FTI tunnel described in the topology in Figure 2, the following factors can also cause a routing loop:

  • Tunnel establishment being slow or a tunnel never getting established.

  • Level 1 metrics being larger than the Level 2 metrics.

Limitations with ECMP

When using flood reflectors, it is possible to encounter some issues with ECMP resulting in minimal usage of the paths through the network. The following cases represent some issues with ECMP:

  • ECMP Expected from Level 2 SPF not Realized in Forwarding

    In this topology, based on its Level 2 SPF computation, R4 expects the traffic to enter the Level 1 fabric at R0 and exit at R1 and R2, with traffic being load balanced equally across the links from R1 to R5 and R2 to R5.

    However, the Level 1 cost from R0 to R1 is 2 while the Level 1 cost from R0 to R2 is 4. All of the traffic is forwarded to R1 in the Level 1 fabric and uses the link from R1 to R5.

    This issue can be addressed by building a full mesh of equal-cost Level 1 tunnels between each of the Level 1/ Level 2 leaf routers.

  • ECMP Expected from Level 2 SPF not Effectively Utilized

    Based on its Level 2 SPF computation, R4 expects the traffic to be sent only across the link from R0 to R5. This is the observed forwarding behavior. However, this behavior limits to utilize ECMP effectively. Building a full-mesh of equal-cost Level 1 tunnels between all of the Level 2/Level 1 leaf routers does not solve this issue.

Related Documentation