When we last left off, we were considering the feasibility of replacing a WAN provider’s P and PE devices with routers. Let’s take a look at this in greater detail, to see where any potential problems might arise. Refer to Figure 1, where we have two customers, “A” and “B”, each with three sites, connected to a WAN provider:
The first problem with using routers within the WAN cloud is that in addition to IPv4, customers might also be using other routed protocols, such as IPv6, IPX, AppleTalk, SNA, etc. With Layer-2 switches in the WAN cloud this isn’t a problem, but if the PE and P devices are routers they will need multiple routing tables, one for each routed protocol for which they’re forwarding traffic (they’ll be “multiprotocol routers”). Since routing tables are kept in RAM, and RAM costs money, keeping multiple large routing tables on many routers could entail significant costs.
The second problem is that packet processing by a router takes longer than frame forwarding by a Layer-2 switch. A Layer-2 switch only has to find the match in its switching table, and forward the frame. If using “cut-through” switching, this can happen at nearly line speed. An IPv4 router, on the other hand, must strip the frame header and trailer, do a longest-prefix match on the destination address, decrement the IP TTL, check that the TTL hasn’t reached zero, recalculate the IP header checksum, encapsulate the packet within a new frame, and forward the frame. This all takes time, and if it takes too much time, the customers’ delay-sensitive apps won’t work well.
The third problem is that if two customers attempt to use the same address space, the routers within the WAN cloud will be confused as to which prefix lies where. As you can see from Figure 1, Customer A’s site A1 is using the 10.1.0.0/16 address space, as is Customer B’s site B1. When CE-A1 and CE-B1 advertise 10.1.0.0/16, PE1 will prefer the path via the routing protocol with the lowest Administrative Distance. It the AD’s are a tie, then PE1 will prefer the path with the best metric. If the metrics are a tie, PE1 will load-share between the available paths.
What this means is that PE1 might send all of the traffic for 10.1.0.0/16 to CE-A1, or it might send it all to CE-B1, or maybe load-share it between the two, depending on the routing protocols and metrics involved. And if two PE routers advertise the same address space, as PE2 and PE5 do with 10.2.0.0/16, the P routers will also be confused.
One possible solution to the address collision problem is for the provider to enforce a rule that no two customers could share the same address space, but this is unworkable in practice. First, customers will not take kindly to a WAN provider dictating what private address space they can use (remember, this is a WAN provider, not an ISP, so advertising private addresses is perfectly legal, and that’s bound to create some overlaps). Second, if the provider did make such rules, it would have to enforce those rules using some type of access list, which would require revision if a customer’s address space was changed, which is a non-scalable solution.
So, when it comes to using routers within a WAN cloud, it looks like we have three possible problems:
- Multiple routing tables in RAM
- Excessive latency
- Address-space collisions
Each of these by itself could be a show-stopper, but next time we’ll see how we can solve all three problems in an exceedingly slick manner!
