|
|
< Free Open Study > |
|
Combining MPLS TE with MPLS VPNsOne thing that's not been discussed so far is how to use MPLS TE in conjunction with other MPLS services. One of the most popular MPLS applications is MPLS VPNs. MPLS VPNs use a label of their own (a service label) that is carried across your network by one or more IGP labels. TE can provide the IGP label, as can LDP. There's nothing particularly special about using TE LSPs to carry VPN traffic. You use the standard MPLS TE mechanisms to route traffic down a TE tunnel (static routes or autoroute), and MPLS VPNs resolve via a next hop. Both mechanisms end up resolving via the tunnel. Consider the network shown in Figure 10-5. Figure 10-5. Sample Network for the TE+VPN Example
gsr1 and gsr8 are PEs; vxr9 and vxr11 are CEs in the same VPN. gsr2 is just there as a midpoint for the TE LSP. Example 10-22 shows the VPN and TE portions of gsr1's configuration. Example 10-22 gsr1 Configuration: VPN and TE Portionsip vrf test rd 100:1 route-target export 100:1 route-target import 100:1 ... mpls traffic-eng tunnels ... interface Tunnel1 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 192.168.1.8 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 10 dynamic ! ... interface POS0/1 description interface to vxr9 ip vrf forwarding test ip address 192.168.32.1 255.255.255.0 ! Because Tunnel1 has autoroute enabled, gsr8 (whose loopback address/RID is 192.168.1.8) is automatically reachable via that tunnel, as shown in Example 10-23. Example 10-23 Verifying That gsr8 Is Reachable Via Tunnel1gsr1#show ip route 192.168.1.8 Routing entry for 192.168.1.8/32 Known via "isis", distance 115, metric 20, type level-2 Redistributing via isis Last update from 192.168.1.8 on Tunnel1, 00:30:24 ago Routing Descriptor Blocks: * 192.168.1.8, from 192.168.1.8, via Tunnel1 Route metric is 20, traffic share count is 1 The outgoing tunnel label is 16, as shown in Example 10-24. Example 10-24 Determining the Outgoing Tunnel Labelgsr1#show mpls traffic-eng tunnels Tunnel1 Name: gsr1_t1 (Tunnel1) Destination: 192.168.1.8 Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, type dynamic (Basis for Setup, path weight 20) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled(0/24) 0 Bandwidth Requested: 0 InLabel : - OutLabel : POS0/0, 16 As Example 10-25 confirms, this label has been installed in the Forwarding Information Base (FIB). Example 10-25 Confirming That the Outgoing Tunnel Label Is Installed in the FIBgsr1#show ip cef 192.168.1.8 192.168.1.8/32, version 86 0 packets, 0 bytes tag information set local tag: 28 fast tag rewrite with Tu1, point2point, tags imposed {16} via 192.168.1.8, Tunnel1, 1 dependency next hop 192.168.1.8, Tunnel1 valid adjacency tag rewrite with Tu1, point2point, tags imposed {16} Next, look at the VPN information in Example 10-26, which makes things simple; only two routes exist in the VPN routing table. Example 10-26 VPN Information
gsr1#show ip route vrf test
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
B 192.168.27.0/24 [200/0] via 192.168.1.8, 00:39:42
C 192.168.32.0/24 is directly connected, POS0/1
As Example 10-27 shows, gsr1 has learned that 192.168.27.0/24 in the VPN routing and forwarding instance (VRF) called test has a next hop of 192.168.1.8 and an outgoing label of 21. Example 10-27 Information Learned Via BGP for the test VRF on gsr1gsr1#show ip bgp vpnv4 vrf test label Network Next Hop In label/Out label Route Distinguisher: 100:1 (test) 192.168.27.0 192.168.1.8 nolabel/21 192.168.32.0 0.0.0.0 31/aggregate(test) Consider the following points:
Given these points, it only makes sense that you'd use label 16 (the TE LSP) to get to gsr8, right? Right. And that's exactly how it works, as Example 10-28 confirms. Example 10-28 CEF Table for VRF Routes, Using a TE Tunnelgsr1#show ip cef vrf test 192.168.27.0 192.168.27.0/24, version 7 0 packets, 0 bytes tag information set local tag: VPN route head fast tag rewrite with Tu1, point2point, tags imposed {16 21}, wccp tag 92 via 192.168.1.8, 0 dependencies, recursive next hop 192.168.1.8, Tunnel1 via 192.168.1.8/32 valid adjacency tag rewrite with Tu1, point2point, tags imposed {16 21} The {16 21} means that gsr1 puts two labels on the packet—16 on the top and 21 under that. This means that when the packet leaves gsr1 destined for vxr11, it looks like Figure 10-6. Figure 10-6. VPN Packets in a TE Tunnel
Static routes also work. If you disable autoroute on Tunnel1 and install ip route 192.168.1.8 255.255.255.255 Tunnel1 on gsr1, things look much the same, as you can see in Example 10-29. Example 10-29 Routing and CEF Entries Using Static Routesgsr1#show ip route 192.168.1.8 Routing entry for 192.168.1.8/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Tunnel1 Route metric is 0, traffic share count is 1 gsr1#show ip cef 192.168.1.8 192.168.1.8/32, version 115, attached 0 packets, 0 bytes tag information set, unshareable local tag: 28 fast tag rewrite with Tu1, point2point, tags imposed {16} via Tunnel1, 1 dependency valid adjacency tag rewrite with Tu1, point2point, tags imposed {16} gsr1#show ip cef vrf test 192.168.27.0 192.168.27.0/24, version 7 0 packets, 0 bytes tag information set local tag: VPN route head fast tag rewrite with Tu1, point2point, tags imposed {16 21}, wccp tag 92 via 192.168.1.8, 0 dependencies, recursive next hop 192.168.1.8, Tunnel1 via 192.168.1.8/32 valid adjacency tag rewrite with Tu1, point2point, tags imposed {16 21} Any traffic that needs to get from gsr1 to gsr8 uses the TE LSP. It doesn't matter whether that traffic is IP or MPLS; if it needs to get to 192.168.1.8 or something that resolves via that address, that traffic is sent down the TE LSP. A TE Tunnel Per VRFRather than taking advantage of MPLS's LSP hierarchy, some people want to build a TE LSP per VPN between a pair of CEs. In other words, rather than letting all VPN traffic between gsr1 and gsr8 share the same tunnel, they want each VPN to have its own LSP. A TE tunnel per VRF is often not a good idea. If you have more traffic between gsr1 and gsr8 than you can fit in a single LSP (such as if you want to make a 200 Mb reservation and you have two OC-3s between gsr1 and gsr8), build two TE LSPs. But the idea here is that TE LSPs transport core traffic; they're not really for per-user traffic. Also, besides scaling horribly, a per-VPN LSP makes little to no sense. What does it buy you? Yes, each customer is in its own TE LSP, but so what? That's like building a network to carry OC-3s by laying dozens of strands of dark fiber, each carrying its own OC-3, rather than grooming 64 OC-3s into a single OC-192. Hierarchy is good. Use it. On the other hand, there might be the occasional legitimate reason to have separate TE tunnels for services between the same pair of routers. For example, if you want to offer strict QoS guarantees for a VPN service, it might be easier to do this with multiple TE tunnels. Just make sure that before you start provisioning TE tunnels on a per-service basis, you have both a justification for doing so and a handle on the scalability aspects. LDP on a Tunnel InterfaceYou might have noticed in the previous section that Tunnel1 on gsr1 has mpls ip enabled. This turns on TDP or LDP on the tunnel interface. This is not strictly necessary in the network illustrated in Figure 10-5, but it is necessary when the TE tunnel does not run from PE to PE, but instead from P to P. Expanding the network shown in Figure 10-5 to something like Figure 10-7, where gsr1 and gsr8 are PEs, but gsr2 and gsr5 have TE LSPs to each other, you need TDP or LDP over the TE tunnel. Figure 10-7. Expansion of the Network Shown in Figure 10-5, with the Need for TDP or LDP Over the TE Tunnel
Enabling TDP or LDP on the TE tunnel with the command mpls ip is necessary here. If you think about the packet path, packets leave gsr1 with an LDP-derived label on them. This labeled packet gets to gsr2. gsr2 needs to take this packet and put it down the TE tunnel that terminates on gsr5. Figure 10-8 shows what the packet at each hop looks like. Figure 10-8. Packet Path and Label Stacks Without LDP Over the TE Tunnel
gsr5 isn't the egress PE, so it doesn't know what to do with the VPN label. As a result, it drops or misroutes the packet. For this reason, an LDP label must exist on the packet when it gets to gsr5. You can't have just a TE label and a VPN label, because by the time the packet gets to gsr5, the TE label will have been removed already because of penultimate hop popping, and the only label gsr5 would see is a VPN label. With LDP on the TE tunnel, the packet at each hop then looks like Figure 10-9. Figure 10-9. Packet Path and Label Stacks with TE Over the LDP Tunnel
gsr2 and gsr5 form an LDP neighbor relationship so that gsr2 can do the following:
When gsr5 gets the packet, it will only have the LDP label on it. gsr5 will switch the packet according to the value in that label and, therefore, forward the packet to gsr8. Thus the need for LDP. Or TDP; it works the same way. You just configure mpls ip on a TE tunnel interface, just like you would on any other interface. And, of course, you almost always have a TE tunnel from gsr5 to gsr2, also with the same mpls ip configuration. If for some reason you have only a TE LSP from gsr1 to gsr5, you need to tell gsr5 to listen to the LDP hello messages that gsr5 is sending. You do that by configuring mpls ldp discovery targeted-hello accept on gsr5. This command can take an ACL specifying the RID of the peers you're willing to accept targeted hellos from; it's a good idea to use the ACL so that you don't open yourself to forming LDP sessions with devices you shouldn't. You should generally have tunnels in both directions, so you shouldn't need to configure mpls ldp discovery targeted-hello accept anywhere in your network. |
|
|
< Free Open Study > |
|
