Providing IP Services


Certain IP services such as DHCP and DNS can be shared by many VNs. Because these services are closely tied to the structure of the IP addressing scheme, it is necessary to be able to add VN information to some service requests and also be able to virtualize the services themselves and make them VN aware.

DHCP

You can provide DHCP services in a virtualized network in two ways:

  • Dedicated DHCP services per VN In this scenario, the DHCP service exists inside the VN address space. The service itself is not virtualized and does not need to be aware of the virtualization of the network either.

  • Shared DHCP services across VNs In this scenario, a single DHCP service is shared by many VNs. Therefore, the DHCP service must be aware of the virtualization of the network and must also be virtualized.

Each of these options is discussed in more detail in the following sections.

Dedicated DHCP Services per VN

When each VN has its own DHCP service, the only added required functionality is that any router relaying DHCP messages be able to unicast these messages using a VRF rather than the global table.

The DHCP relay functionality allows the DHCP multicast-based conversation to be relayed over a unicast UDP connection directly to a known DHCP server when the DHCP server is not in the same subnet as the client. To unicast this traffic in a VN, the DHCP relay feature must be able to look up the destination address in a VRF table rather than the global table.

This is the basic level of VRF awareness for the DHCP relay functionality.

Shared DHCP Services

To share a DHCP service among many VNs, it is necessary to virtualize the DHCP service. What this means is that the DHCP server will contain a set of scopes for each VN. For instance, the DHCP server might contain a partition for the BLUE VN with several scopes providing addresses in several subnets. Simultaneously, the DHCP server might contain a totally separate partition with the scopes and subnets for the RED VN. Each partition in the DHCP server is equivalent to a traditional nonvirtualized DHCP server and services a particular VN.

It is, of course, necessary to provide a way of differentiating DHCP messages from one VN from DHCP messages from another so that the correct partition can be used to service the different DHCP requests for the different VNs.

Thus, the infrastructure must be able to not only relay the DHCP messages over a VN, but must also be capable of tagging certain DHCP messages as originated within a specific VN.

Option 82 (a field in the DHCP messages) can be used to carry the information related to which VN the message belongs to. This information is added to the DHCP message by the DHCP relay agent. Therefore, when the message reaches the DHCP server, it will be linked to the partition that corresponds to the VN in the option 82 field.

For example, in the network in Figure 8-17, the DHCP server contains two partitions, one for the RED VN and one for the BLUE VN.

Figure 8-17. Shared DHCP Services


When host C (which is in the BLUE VN) makes a DHCP request, it will be seen by PE-1. PE-1 will then assign the tag corresponding to BLUE in the Option 82 field of the request, write 10.10.10.1 in the giaddr (gateway IP address) field of the request, and unicast the request to the DHCP server. When the DHCP server receives the request, it will choose the appropriate scope based on both Option 82 and the giaddr fields. Note that without option 82, the DHCP server would have two different partitions to choose from, but no criteria to decide.

Domain Name System (DNS) Services

The provisioning of Domain Name System (DNS) services for VNs using valid Internet addresses is straightforward and requires no special consideration. On the other hand, the provisioning of DNS for VNs using private addresses as defined in RFC 1918 can pose certain challenges depending on the level of functionality desired.

At a basic level, DNS services can be shared by all VNs if these are only used to resolve names of hosts that are outside the VNs. In this scenario, all VNs must simply be able to reach the DNS server that will be outside the VNs in a demilitarized zone (DMZ) or a central services site.

When the requirement is to resolve the names of internal hosts while using private IP addressing, it is necessary to deploy a DNS server inside each VN. This internal server allows the resolution of the internal names. This DNS server should be able to query external DNS servers for the resolution of Internet names.

In general it is recommended that separate internal and external DNS servers be deployed. The internal DNS server relays requests from the internal hosts to the external DNS server, which then proceeds to begin the necessary resolution queries on behalf of the internal server. To obtain the desired result, it is necessary for the internal DNS server to be reachable from outside the VN. To this effect, a static NAT entry and the necessary rules must be put in place at the firewall to allow the internal DNS server to be accessed from the outside. Note that this will not provide resolution of the internal names for external queries.




Network Virtualization
Network Virtualization
ISBN: 1587052482
EAN: 2147483647
Year: 2006
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net