When Information Is Distributed

Now you understand what information is flooded. But when is it flooded? In a network that doesn't use MPLS Traffic Engineering, the IGP floods information about a link in three cases:

• When a link goes up or down

• When a link's configuration is changed (when link cost is modified, for example)

• When it's time to periodically reflood the router's IGP information

All sorts of timers are associated with these actions. They differ depending on which IGP you use.

However, MPLS Traffic Engineering adds another reason to flood information—when link bandwidth changes significantly.

As tunnels are set up and torn down across interfaces, the amount of available bandwidth on an interface changes in accordance with the reservations across an interface. As tunnels are set up across an interface, they consume bandwidth, and the amount of available bandwidth goes down; as tunnels are torn down across a particular interface, the amount of available bandwidth goes up.

But when should a router advertise this change in bandwidth?

The first answer that comes to mind might be "whenever a change happens." But that can lead to a tremendous amount of flooding. Some large MPLS Traffic Engineering networks have several thousand tunnels; reflooding whenever a tunnel changes is like adding several thousand links to your IGP. Reflooding TE changes isn't quite as bad as flooding the equivalent number of IGP links—you don't run a full SPF whenever you get new TE link-state information—but there can be a lot of information flooding in the network.

There could potentially be a tremendous amount of flooding—enough to consume bandwidth on the network and significant CPU resources on the router.

On the other hand, you want to make sure that the topology information advertised by the router is reasonably up to date. If all the bandwidth on a particular link is reserved, and this fact is not advertised to the rest of the network, the fact that the network is out of sync with reality can lead to setup failures and other suboptimalities. So, you must entertain ideas about when to flood changes. These are the three rules of flooding thresholds:

Flood Significant Changes Immediately

The first rule seems simple. But how do you define significant? Is a 5-Mbps change in available link bandwidth significant? This depends on the link type. A 5-Mbps change might be significant if it happens on a DS-3 link which has a maximum reservable bandwidth of 45 Mbps. But a 5-Mbps change probably isn't worth flooding on an OC-192 link, which has more than 200 times the bandwidth of a DS-3 (a little less than 10 Gbps).

Significant is defined as a percentage of link bandwidth. But is that enough? You might not need to know immediately if your OC-192 goes from 6.483 Gbps of reservable bandwidth to 6.488 Gbps of reservable bandwidth. But you might want to know if your OC-192 gives up its last 100 Mbps of bandwidth and goes from 0.1 Gbps reservable bandwidth to 0 Gbps reservable bandwidth.

You might also need to care more about changes in one direction than in the other. So, it might be important to tell the world if you give away the last 5 Mbps on an OC-192 link, but it might not be important to tell the world if that 5 Mbps is freed up again.

Rules for when to advertise available bandwidth are different for every network, situation, and link. So Cisco IOS Software comes with a set of reasonable defaults, but also with a flexible scheme for determining what changes are significant.

Here is the command that controls when to flood information about a change on a particular link:

gsr12(config-if)#mpls traffic-eng flooding thresholds {up | down} list of threshold

  percentages

The percentages you configure are the percentages of bandwidth reserved on the link.

Configuring percentages in the up direction means that as more bandwidth is used and the thresholds are crossed, link bandwidth is flooded. Percentages configured in the down direction are crossed as bandwidth is freed up and reservations on the link decrease.

The default thresholds on all links are the same in both directions. They are 15, 30, 45, 60, 75, 80, 85, 90, 95, 96, 97, 98, 99, and 100. Currently, there is a limit of 16 flooding thresholds. There is no restriction on the numerical values used, but you cannot have more than 16 values in each direction.

You can view the current thresholds using the command show mpls traffic-eng link-management bandwidth-allocation [interface-name], as demonstrated in Example 3-12.

Example 3-12 Viewing Available Bandwidth Thresholds

gsr1#show mpls traffic-eng link-management bandwidth-allocation pos0/0

System Information::

    Links Count:          3

    Bandwidth Hold Time:  max. 15 seconds

Link ID::  PO0/0 (192.168.2.1)

    Link Status:

      Physical Bandwidth:   155000 kbits/sec

      Max Res Global BW:    116250 kbits/sec (reserved: 0% in, 0% out)

      Max Res Sub BW:       0 kbits/sec (reserved: 100% in, 100% out)

      BW Descriptors:       0

      MPLS TE Link State:   MPLS TE on, RSVP on, admin-up, flooded

      Inbound Admission:    allow-all

      Outbound Admission:   allow-if-room

      Admin. Weight:        10 (IGP)

      IGP Neighbor Count:   1

      Up Thresholds:        15 30 45 60 75 80 85 90 95 96 97 98 99 100 (default)

      Down Thresholds:      100 99 98 97 96 95 90 85 80 75 60 45 30 15 (default)

    Downstream Global Pool Bandwidth Information (kbits/sec):

      KEEP PRIORITY     BW HELD  BW TOTAL HELD   BW LOCKED  BW TOTAL LOCKED

                  0           0              0           0                0

                  1           0              0           0                0

                  2           0              0           0                0

                  3           0              0           0                0

                  4           0              0           0                0

                  5           0              0           0                0

                  6           0              0           0                0

                  7           0              0           0                0

Every time bandwidth is reserved on an interface, the reservation is considered. If the amount of bandwidth change is enough to cross a threshold, information about that link is reflooded immediately.

Flooding Links in IS-IS Versus OSPF Flooding is a little different between IS-IS and OSPF. In OSPF, only information about the link that has changed is flooded, because a Type 10 LSA contains a single link advertise-ment. In IS-IS, information about all links on a node is flooded even if only one has changed, because the Type 22 TLV contains a list of all the links on the router. Ninety-nine percent of the time you're not going to care about the distinction, but it's worth noting. The trade-off is that on a router with many links doing MPLS Traffic Engineering, the flooding traffic from a single link change is more in IS-IS than the flooding traffic from a single link change in OSPF. But if multiple links change on the same router, IS-IS might be more efficient at encoding these changes in a single TLV. But again, most of the time you don't care.

Consider a link with 100 Mbps of reservable bandwidth. At time 0, the link has 0 Mbps reserved. As tunnels come and go, thresholds are inspected to see if any change in reservation crosses a threshold, and TE link-state information is flooded as necessary.

Consider the bandwidth changes caused by the tunnel reservations shown in Table 3-2. Positive bandwidth changes are due to reservations being made, and negative changes are due to reservations being torn down. Assuming that the default threshold is configured for the link, Table 3-2 lists bandwidth changes on the link at various points in time. The Flood? column shows whether the change caused flooding. The last column shows the thresholds crossed in each direction. Figure 3-6 illustrates the points in time where the bandwidth changes caused significant flooding. The arrows indicate points where TE information is flooded.

Table 3-2. Crossing Flooding Thresholds

Time	Bandwidth Change (%)	Bandwidth Remaining (%)	Bandwidth Consumed (%)	Flood?	Threshold Crossed, Direction?
0	0	100	0%	N/A	—
1	10	90	10%	N	—
2	1	89	11%	N	—
3	2	87	13%	N	—
4	2	85	15%	Y	15%, up
5	35	50	50%	Y	Both 30% and 45%, up
6	–8	58	42%	N	—
7	–20	78	22%	Y	30%, down
8	72	6	94%	Y	30%, 45%, up
9	1	5	95%	Y	95%, up
10	2	3	97%	Y	96%, 97%
11	–3	6	94%	Y	96%, 95%, down

The important concept to take away from this example is that the default flooding values are more sensitive to changes when the link is almost full than when it's nearly empty.

Flood Insignificant Changes Periodically, But More Often Than the IGP Refresh Interval

How often is "periodically"? By default, it's every 180 seconds (3 minutes). But this too can be configured, using the following global command:

gsr1(config)#mpls traffic-eng link-management timers periodic-flooding 0-3600

  second interval

This is how often information is flooded if available bandwidth has changed and it hasn't already been flooded. The default behavior is to check with the TE Link Manager (see Chapter 4) every 3 minutes and, if reservable bandwidth has changed on any links, flood the new information about these links. MPLS Traffic Engineering information is not flooded every 3 minutes if there are no changes. Only if changes were made in the last 3 minutes are things flooded. Periodic flooding floods only information that has not yet been flooded (that is, a bandwidth change that did not cross a flooding threshold).

Setting mpls traffic-eng link-management timers periodic-flooding to 0 disables periodic flooding. This means that bandwidth information is flooded only on Rule 1 or Rule 3.

If a Change That Has Not Yet Been Flooded Is Known to Cause an Error, Flood Immediately

What's an error? RSVP sends an error when a path setup fails due to lack of bandwidth. Errors are covered in more detail in Chapter 4, but there's not much to understand from a flooding perspective. If a router receives a reservation request for more bandwidth than is currently available on a particular link, available link bandwidth has been changed since the last time flooding occurred, so the router receiving the reservation assumes that the router sending the reservation has stale information in its topology database, and it refloods.

When to Change the Flooding Timers Don't. Or, more specifically, don't change them unless you know you need to. It might be tempting to change the periodic flooding timer to 1 second so that all routers always have the most up-to-date information. But do you really need that level of accuracy? And at what cost do you achieve it? The default thresholds are useful; change them only if you know you need to.