Forwarding Adjacency

Earlier in this chapter, you learned how to change the metric on a TE tunnel. But sometimes, changing the metric isn't enough to steer traffic the way you want it to go.

As mentioned earlier, TE tunnels are not advertised in your IGP. This means that if you change the metric on a TE tunnel, other routers will not see this changed metric and won't be able to take advantage of it.

All links shown in Figure 5-13 have a cost of 10, and all routers are at the same IS-IS level. This example uses Level-2 adjacencies between routers; forwarding adjacency also works across a Level-1 cloud.

Figure 5-13. Network Without MPLS TE


Traffic goes from Router A to Router G. With no MPLS TE, all A→G traffic goes across A→C→F→G. What if you want to send A→G traffic across both A→C→F→G and A→B→D→E→G?

One way to do this is to place two TE tunnels from Router A to Router F—one across the B→D→E→F path and one across the C→E→F path. These tunnels are both installed with the shortest cost to the IGP tail, and Router A load shares between them.

But what if you don't want to extend TE tunnels all the way to Router A? Extending TE tunnels all the way to the edge works OK in a small network, but most real-world networks have more than seven routers. If you have 50 POPs with 15 routers in each POP, that's a total of 750 routers; a full mesh of TE tunnels between 750 routers is 561,750 TE LSPs, and two tunnels between each router means 1,123,500 TE LSPs. That's pretty big.

Obviously, things scale better if you move the TE tunnels up one level in the network hierarchy, toward the core. If you deploy a full mesh of TE tunnels between the POP-facing core routers (B, C, E, and F), only 12 tunnels are necessary in Figure 5-13. If your 50 POPs have two core routers each, that's 100 * 99 TE tunnels, for a total of 9900. A total of 9900 is a big number, but it's much lower than 1,123,500.

Figure 5-14 shows the same topology as Figure 5-13, but with TE tunnels.

Figure 5-14. Network with MPLS TE and Without Forwarding Adjacency


Now you've got two TE tunnels—B→E and C→F. Each of these tunnels has been configured with tunnel mpls traffic-eng autoroute metric 9, which means that the tunnel headends assign these tunnels a metric of 9.

Problem solved, right?

Wrong!

Router A doesn't know about those TE tunnels. It makes its SPF decision based on the IGP metrics alone, which means it still sends all its A→G traffic to Router C. You haven't solved anything yet!

You need a way to advertise the TE tunnels into the IGP so that Router A can see them and take advantage of them. You do this using the command tunnel mpls traffic-eng forwarding-adjacency on the tunnel interface, as shown in Example 5-10.

Example 5-10. Advertising TE Tunnels into the IGP
					interface Tunnel1
					ip unnumbered Loopback0
					no ip directed-broadcast
					tunnel destination 192.168.1.8
					tunnel mode mpls traffic-eng
					
						tunnel mpls traffic-eng forwarding-adjacency
					tunnel mpls traffic-eng path-option 10 dynamic
					isis metric 9 level-2
				

NOTE

forwarding-adjacency and the IGP metric are configured on both the tunnel from Router B to Router E and from Router C to Router F. Another way to solve this problem is to only build a TE tunnel from Router B to Router E, not from Router C to Router F, and give the B→E tunnel a cost of 10. Because 10 is a link's default IS-IS cost, there is no need to configure an IS-IS metric on the tunnel interface. This example was done with a metric of 9 so that you can see that you control the tunnel's cost by changing the IGP metric rather than the autoroute metric.


Note that an IS-IS metric is also configured on the tunnel interface. This metric is what's announced into the IGP.

When you configure forwarding-adjacency, the tunnel headend advertises that tunnel in its IGP. The IS-IS database looks like Example 5-11.

Example 5-11. IS-IS Database After forwarding-adjacency Is Configured
RouterB#show isis database detail RouterB.00-00
IS-IS Level-2 LSP RouterB.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
RouterB.00-00       * 0x0000023D   0xEDD2        1122              0/0/0
  Area Address: 47.0001.0192
  NLPID:        0x81 0xCC
  Hostname: RouterB
  Router ID:    192.168.1.5
  IP Address:   192.168.1.5
  Metric: 10         IP 192.168.10.0/24
  Metric: 10         IS-Extended RouterD.00
  Metric: 9          IS-Extended RouterE.00
  Metric: 10         IP 192.168.1.5/32

After this IS-IS LSP is announced, all other routers see the TE tunnel as a regular link. It's not a link that TE tunnels can be signalled across, but it is available for regular IGP traffic. It's important to understand that any router that sees this advertisement has no idea that the forwarding adjacency from Router B to Router E is a forwarding adjacency; all any other router sees is a link of cost 9.

From Router A's perspective, the topology looks like Figure 5-15.

Figure 5-15. Network with Forwarding Adjacency


Forwarding adjacency optionally allows you to configure a holdtime. Here is the full forwarding-adjacency command syntax:

					tunnel mpls traffic-eng forwarding-adjacency {holdtime
					0-4294967295 milliseconds}

The holdtime is used when a TE tunnel goes down. If the link a TE tunnel is on fails, the tunnel might go down and come back up quickly as it finds a new path. This is not the sort of thing you want to advertise into your IGP because the link would be removed and readvertised, causing unnecessary IGP churn. The holdtime is how long the TE tunnel must be down before its status is advertised in the IGP. The holdtime is configured in milliseconds, so tunnel mpls traffic-eng forwarding-adjacency holdtime 12000 waits until a TE tunnel has been down for 12 seconds before telling the IGP that the tunnel is down.

The default forwarding adjacency holdtime is 0 ms.

Forwarding adjacency has a few restrictions:

  • You must have IS-IS as your IGP; OSPF does not currently support forwarding adjacency.

  • When a forwarding adjacency is advertised in the IGP, it is advertised as an IP link only, not as a TE link. This means that you cannot send a TE reservation from Router A to Router G across the tunnel from Router C to Router F.

  • Because of the nature of forwarding adjacency, the tunnel headend and tail must be in the same area.

Note that IS-IS's bidirectional check is not removed. This means that if you have a TE tunnel from Router B to Router E that you've configured with tunnel mpls traffic-eng forwarding-adjacency, you also need to have a similarly configured tunnel from Router E to Router B in order for forwarding adjacency to be considered in Router A's IGP SPF. If you don't, even after receiving IS-IS LSPs about the tunnel link, Router A will not install it in the routing table because only one of the links is up.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.140.185.170