eyatsko.msk.united-networks.ru

Phisical Diagram

It's nothing interesting yet. But.. In the future plans a buying of several access switches. You are already able to observe that devices are arranged into classes. There are devices that serve users: these are computers and printers. And there are devices to supply users by Internet. All of them are grouped into something which will be Switch Blocks. Several deviations from Standard are conditioned by the lack of hardware. For example, server farm is connected to core switches directly. It's because there is no Gigabit access (2960G) switch. By the way the scheme of Standard is called “Collapsed Core” where distributed layer is combined with core. In the final case it will be something like this:

Criss-cross link between WAN and Server Farm means the only thing: the most of Virtual Machines are really (internal) servers and site has no enough resources to allow presence additional VMWare platform to separate Srvgate into another switch block. Srvgate in its essence VPN Aggregator what is actually WAN technology.

Third Gigiabit Switch (which is used exclusively with pc-eyatsko.domain) is needed to work with KVM-switch. And the mentioned pc-eyatsko.domain is one of PCs connected to KVM.

Datalink Diagram

All devices are grouped by functional sign into different VLANs. This division is more conceptual then really needed. :-) Almost all VLANs are terminated on Core 3750G Switches as directed. Except one. VLAN of Free Wifi Users. It is more convinient to restrict access by IPTABLES firewall then Cisco's one and centralize all access functions of this VLAN on Ubuntu. For instance, users of Free Wifi need not to authenticate. Instead before the first Internet access Free Wifi user's browser shows “Caution Message” and then redirects to original User typed Site. It is very difficult to do this terminating the VLAN on Core switches. Therefore it is terminated on Srvgate. And without redundancy.

All other VLANs use redundant technology to reserve Gateway. Almost everywhere the HSRP is used, and only between heterogeneous Cisco 2821 and Srvgate VRRP is used (Vlan 22). That is, it is redundant even twice! :-) The only exception is Vlan 23 which is auxillary and needed to supply IP level communication (OSPF redundancy) between two core switches.

Vlan 16 collects all management interfaces of all switches, routers and so on, including core switches too.

Vlan 21 represents Server Farm. Servers are either entirely belong to Server Farm (so-called “internal”) or by a number of its network interfaces. For Example Srvgate has three interfaces: one is external - for VPN aggregation and Internet connection, the second one is for Vlan 99 termination (Free Wifi Users), and the third is for Server Farm. Srvgate provides not only “external” functions like BGP and VPN aggregation but also DNS and Web implementations for internal users. So it has “internal” interface in Vlan 21.

To avoid asymmetric routing interfaces that do not participate in routing are declared as “passive interfaces” under corresponding “router ospf”. The reverse side of a “medal” is using various source interface. Sharp question arises of using loopback interfaces. That is, to divide sending interface from Source IP address.

Spanning-Tree

As Spanning Tree Protocol (STP) MSTP had been choosen. Drawbacks of traditional 802.1D and PVST/PVST+ (Per VLAN Spanning Tree) are well known. 802.1D has the only Tree but sometimes there is a need to change Tree (uplinks and BPDU flow) for a set of VLANs. PVST is another extreme - each VLAN has its own Spanning Tree which is the same in the most of cases. MSTP is deprived of these drawbacks. Instead of using single tree for all VLANs or a set per VLAN trees. MSTP builds several user defined trees and in order maps on them VLANs. Since the most of VLANS are terminated on Core two instances it would be enough. Why two? For balancing on Datalink layer purposes. VLANs are divided nearly on two halves in a sence of load and mapped each to its own MSTP Instance. The first Instance has one Core Switch as a Primary Root and the other Core Switch as a Secondary Root. The second Instance is quite contrary.

As you can see some of VLANs either do not cross the Core (100-102), they exist only on sw-2960 locally, or cross the Core but terminate somewhere else. I'm about Vlan 99. All these VLANs are targeted to sw-2960. So it makes a lot of sence to do it the Root.

per_site_topologies.txt · Last modified: 2016/01/31 11:14 (external edit)
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki