server | IPNET

Cisco makes its Nexus 1000v virtual switch less virtual

Cisco Systems is making its virtual switch, the Nexus 1000v, a little less virtual.

The Nexus 1000v virtual switch replaces the vSwitch embedded in VMware hypervisor software and aims to give network administrators more control and visibility into the switching that takes place between virtual machines on a virtual host server. To date, however, the Nexus 1000v has existed as a virtual machine — a turn-off for network administrators who are accustomed to being able to see and touch their physical network devices.

“I think a lot of network administrators were leery about having [Nexus 1000v] as a virtual appliance because it’s something that’s beyond their control,” said Eric Siebert, senior system administrator with restaurant chain Boston Market and a TechTarget contributor. “Traditionally, the virtual administrators have control over [any virtual machines on a host server].… I think the Nexus 1010 gives them the option to have that type of control in a physical chassis.”

Cisco adds rack server to data center computing system

Cisco this week extended its Unified Computing System data center convergence platform with rack mountable servers, saying the new form factor represents an “entry level” into UCS and more choice for customers.

Cisco, however, did not disclose pricing for the 1RU and 2RU servers, which will be available in the fourth quarter.

The new C-Series rack-mount servers are designed to help accelerate the adoption of the Cisco unified computing and data center virtualization system. Like the predecessor B-Series blades, the C-Series rack mount servers utilize X86 Intel Xeon 5500 processors and are optimized for Cisco’s memory expansion and virtualized adapter technologies, which are integral to UCS.

The addition of the C-Series lets customers pick the compute form factor that fits their current and future data center environments, Cisco says.

Read the full article on NetworkWorld.com…

Can Cisco sell ‘unified’ vision to a tough server crowd?

Cisco Cisco’s biggest challenge in gaining market acceptance for its new Unified Computing System is to convince data center managers to buy blade servers from the router giant instead of from traditional, incumbent suppliers.

“Server buyers don’t have a relationships with Cisco,” says James Staten of Forrester Research. “It will be tough to convince them of the need for another player in this market.”

Cisco last week finally took the wraps off of its long-anticipated UCS platform, which incorporates internally developed blade servers and is designed to tightly integrate data center computing, storage, networking and virtualization capabilities. The blade server component has been the focus of much industry speculation over the past year, and what it might mean to Cisco’s relationships with longtime partners and blade server makers HP and IBM.

Cisco acknowledges that it will now compete with those titans in the data center blade server market. But it also claims it had no choice – and that those trying to pit Cisco and UCS directly against HP and IBM blade servers are missing the point.

Read the full article on NetworkWorld.com…

Cisco: Very simple NTP configuration

NTP (Network Time Protocol) is usually very simple to configure on Cisco devices. Of course you can reach complex configuration, but since I work in this field I didn’t saw somebody to push the things to extreme in NTP configuration.

NTP is based on server – client relation. It is recommended that in a Cisco network environment, you should use online the client part of the NTP, and to choose some external NTP sever to synchronize with. This is because using a NTP server (master) on your networ violates NTP’s hierarchical trust model. You should use a NTP master only is there is no possibility to reach an external one or if some corporate policies dictate this.

NTP can operate in 4 different modes. See a short explanation below:
-> Client: A NTP client is configured to let its clock be set and synchronized by an external NTP timeserver. NTP clients can be configured to use multiple servers to set their local time and are able to give preference to the most accurate time sources. They will not, however, provide synchronization services to any other devices.
-> Server: A NTP server is configured to synchronize NTP clients. Servers can be configured to synchronize any client or only specific clients. NTP servers, however, will accept no synchronization information from their clients and therefore will not let clients update or affect the server’s time settings.
-> Peer: With NTP peers, one NTP-enabled device does not have authority over the other. With the peering model, each device shares its time information with the other, and each device can also provide time synchronization to the other.
-> Broadcast / Multicast: Broadcast/multicast mode is a special server mode with which the NTP server broadcasts its synchronization information to all clients. Broadcast mode requires that clients be on the same subnet as the server, and multicast mode requires that clients and servers have multicast access available and configured.

For our simple NTP configuration we will use the server and client mode. For this tutorial we will use the same topology like in the post “Cisco: BGP path selection for outgoing traffic” where we have already a working BGP environment. If you do not have the topology, you can download it here. Please see the tutorial below: