The Distinction Between Metro Ethernet And Stretched Data Center Subnets Go Through This Article To Find Out More About Metro Ethernet And Stretched Data Center Subnets Things You Must Know About Metro Ethernet And Stretched Data Center Subnets

Each and every time I rant about large-scale bridging and also stretched L2 subnets, somebody unavoidably points out that Carrier (or Metro) Ethernet operates flawlessly fine using the same technologies and also principles.

I won't spend any time on the "perfectly fine" part, but concentrate on the fundamental difference between the two: the use case.

Typical Metro Ethernet use case

Engineers who know what they're doing connect individual websites to Metro Ethernet services with layer-3 devices. This is contained in ccie r&s workbook.

It doesn't matter whether you contact the site edge devices routers or perhaps switches, they perform several crucial functions:

They split the inside and the outside into two separate L3 subnets and also two failure domains;

They run routing protocols. Other devices attached to the same Metro Ethernet service can thus determine whether a web site is accessible or not;

They are able to find alternate paths (if they exist) after a link or perhaps service failure.

In principle, the routers connecting your web-sites to a Metro Ethernet service treat that service as one among the potential transport networks, and could use the routing protocols or BFD/CFM to determine when the Metro Ethernet service is gone even when the local link status doesn't change.

Worst case, when the Metro Ethernet service falls apart, and you've provisioned backup links, your websites could still communicate with each other. If the Metro Ethernet service experiences a serious meltdown, the hosts inside your websites will not be affected. This is stated in ccie r&s lab.

CCIE RS Lab : it's completely safe to use layer-2 transport network as long as you terminate it with a layer-3 device.

Standard stretched data center subnet use case

Hosts are directly attached to stretched layer-2 subnets in a typical layer-2 data center interconnect design, as demonstrated in the next diagram.

The servers attached to stretched VLANs normally have no routing intelligence; all they know are two simple rules:

If the destination IP address belongs to the same subnet, use ARP to find the MAC address of the other host, and send the IP packet to that MAC address. When the ARP request fails, the other host is unreachable. Otherwise, send the IP packet to the IP address of the default gateway.

The lack of routing intelligence in typical servers is not a software/OS problem. Linux as well as z/OS support routing daemons, and so did Windows server right until it got lobotomized. Nonetheless, it seems lots of engineers think naked singularity would materialize as well as gobble up their whole data center if they configured OSPF on a server.

Typical IP hosts do not have any means of detecting the VLAN failure or partitioning, and cannot find alternate paths. They rely on network devices providing the connectivity, and with no layer-3 intelligence in the path, there is only so much the networking devices could do.

The layer-2 data center interconnect thus becomes the most important part of the whole data center infrastructure - if it breaks, everything else stops working Is that a wise idea?