So I'd now like to cover how IP address plans will assist with planning multihoming. An IP address planning is actually a very important part of multihoming especially for traffic engineering. A lot of network operators don't think about this or they leave the management of their address space to a customer sales organization or the customer deployment organization. When, in fact, the address block and the address planning belongs firmly and squarely with the network engineering and network operations. Typical service provider address plans are set up such that they split the address space into four parts. There will be address space for end-users, the customers. There'll be address space used to address the link from the service provider backbone to the end user, typically the point-to-point link addresses. There'll be address space used for the service providers infrastructure, again typically the point-to-point links that connect the routers across the network. And there will also be a small amount of address space for the router loop backs. And these four blocks make up the service provider address plan, as you can see in the diagram below where I have an example of a slash 21 that has been divided between customer address space, customer point-to-point links, the infrastructure point-to-point links and the loopback addresses. Now service provider router loop backs and backbone point-to-point link addresses make up a small part of the total address space. And routers do not attract traffic. They're not browsing the different content around the Internet. They are simply moving packets. Whereas customer address space attracts traffic because the end users are doing all the downloads and their uploads and whatever other work they're doing when connected to the Internet. The links from the ISP aggregation edge to the customer router needs a single slash 30 in IPv4 and a slash 64 in IPv6. These are small requirements when compared with the total address space. Some service providers don't even use addresses on these point-to-point links. In Cisco IOS we use a feature called IP unnumbered or IPv6 unnumbered. However, planning customer assignments is a very important part of multihoming and traffic engineering involves subdividing the aggregate into pieces until the load balancing works satisfactorily. So we need to pay close attention to the address space that's assigned to the customers and to the address space, if used, on the point-to-point link between the service provider and the customer. If the customer is using NAT, then they will be NAT'ing onto the point-to-point link address from the service provider to them. Now if we don't do any planning with the IP address space and we simply consider our address block as a long tube and just start filling up the tube from the left hand side as the diagram shows, the traffic engineering is not really going to work here. Imagine we have two links. Up to now I've said Well. Take the aggregate and answers on both links and then take the aggregate and divide it into two. Announce one piece on one link, the other piece on the other link. Well, if we just number the customers sequentially from the left then all the traffic will come into the first half of the address space and there will be nothing at all for the second half. So we have not been able to do any kind of traffic engineering here. In fact, the only way we can make traffic engineering work is subdivide the extreme most left of our address space and try and balance with that. And then when we add another customer it upsets everything and another customer gets upset again. In fact, this becomes so hard to manage, it's just unmanageable. Some operators have realized that it's unmanageable and just simply announce the smallest amount of address space they can to the internet. resulting in the serious pollution of the internet routing table we see today. Full of the smallest prefixes advertisable / 24 and ipv4 and / 48 and ipv6 it's not scaling for ipv4 but still works just and it simply will not scale at all for ipv6 with a large number of / 48 that are feasible out of every single / 32 that's distributed to a network operator instead we should be doing planned IP addressing rather than filling up the address space from one end of the range we should divide the range into two number the odd-numbered customers from one side and the even-numbered customers on the other side for example and then the scheme becomes quite simple in this 21 we announce the two 21s on our two external links we are now it's one twenty two and one leg and the other 22 on the other link it means that traffic for the first twenty two customers one three five seven nine in the diagram will come in one link and traffic for the other customers two four six eight ten will come in the other link so we'll have some kind of rudimentary load balancing here assuming each customers doing more or less the same thing on the internet today or you could adopt another strategy maybe the first twenty two is for residential customers and the second twenty two is for commercial or enterprise customers or some other allocation to suit but the important point I want to make here is IP address planning is critically important when it comes to doing traffic engineering for multihoming so this example works fine for multihoming between two upstream providers we could also subdivide the address space to suit more upstreams maybe three maybe four although as you see trying to do the traffic balance will get harder with more up streams we have an important pointers don't forget to always announce the aggregate out of each link