I cover BGP in my migration course, however you don't really get the right feel for it in the small lab environment. I like to direct my students to various BGP looking glasses on the web to view what real tables look like. There is a site that contains a list of HTTP based data as well as live routers with public telnet access, this is much more interesting :).
Give it a shot, scroll down to category 2 and try to telnet into these devices. The "show ip bgp ?" command should get you started!
BGP Looking Glasses
Showing posts with label Cisco. Show all posts
Showing posts with label Cisco. Show all posts
Friday, September 3, 2010
Tuesday, May 25, 2010
ASA 8.3, Firewall Technology update (another one)
In the new version of code for 8.3, you'll notice a few changes, perhaps most obviously the new memory requirements, the 5520s and 5540's for instance now require 4 GB of ram. Besides the new RAM requirements you'll find the following changes:
Wider support for IE8 (32& 64 / win 7, vista, xp) also officially support 10.6 OSX for SSL VPN.
Licensing is now aggregate, that is if you have 100 SSL VPN licenses on your active, and 100 on standby (this is required, even though only the active can terminate connections) starting with 8.3, your active ASA will support the aggregate (200) number of licenses. If there was ever a failure, and one is shipped back to Cisco, the other will support the aggregate for 30 days. That should be plenty of time to replace your backup.
You'll now use "objects" which is your IP to name mapping (think names). You can now define a server once, Mailserver=192.168.168.50, and put that MailServer in several different ACLs and NAT rules, you can then change the mapping and it will follow within the other portions of the configuration. The goal is to move towards a more object-oriented configuration, so it's simpler to configure things and make changes system-wide.
There is a new technique, where you can do a reverse many-to-one NAT, called one-to-many NAT. The idea is that you can have a single host on the inside, that is now matching multiple IP's on the outside, perhaps two different service providers.
ACLs now use a concept called REAL-IP, the idea of REAL-IP is that when you build that ACL for the outside interface, for server 192.168.168.50 that's being mapped to 50.50.50.50, you would previously think about what the packet looks like when it arrives on the interface. So think, on the outside, the packet is destined for 50.50.50.50 (there's a static NAT to the inside host). Well, now you'll use the REAL-IP, or the actual IP of the box. While frustrating for some of the veteran users, the idea is to make it easier for the new guys coming in. They can now look at access from a higher level, and permit or deny access to a server, or host regardless of thinking about the static NAT configuration.
There is also a concept of global ACLs, if you're familiar with Modular Policy Framework, think of a Policy-map that is applied globally. So the global ACL is that you can permit or deny traffic universally, ignoring the interfaces. This is a concept available on competitors products, so Cisco wanted to support it. The traditional ACL implementation is still supported, the idea though is if you have a lot of interfaces and you want to allow access to a specific host on all of them, you can write that rule in a global ACL and not have to create the same entry on every interface. While some of this seems frustrating for the veterans, the end goal is to make our lives easier.
Smart-call-home (introduced in 8.2.2) dumps stats and config (sanitized) details to Cisco, and you can login and view details about your equipment. You can see if there are TAC advisories for your versions of code, if there are issues you can open a TAC case from there. Another fun aspect is that you're looking at spec's on the box (CPU, Memory, Interface) and can log those periodically so it's great for base-lining and if you have an issue TAC can easily see the history right there.
Upgrading to 8.3 will perform a config-conversion, meaning your CLI configuration will look completely different from how it looked prior to upgrade. There will also be a file in flash that's basically a text file that shows any errors that occured in the upgrade.(I performed an upgrade of a fairly complex configuration without any errors by the way). If you're a CLI user, it will feel like you're on a different planet, if you're an ASDM user, you may not be real sure what's different, as the look, feel,and terminology is almost identical.
Your existing config is backed-up to flash, and there is actually a downgrade command, so if you do hate it you can roll back. *note* if you do use the downgrade command, realize that you must specify the name of the file which you can find in flash. (Similar to the downgrade process that appeared when moving from 6.3 to 7.0).
As you may recall from any of my classes, you can perform a zero-downtime upgrade, by moving one ASA at a time to 8.3 from 8.2 and you can have a fail-over pair on different code, and the 8.3 is no different. This should not be used for a long period of time however, it's recommended that you move one then the other as soon as you can. While they can run side-by-side you may get a copy of the 8.3 config (completely different core commands) pushed on top of the 8.2.
You can upgrade without the memory upgrade, and the code will load, but it throws an error. As you can imagine you will be forfeiting support if you chose to do this, as when you call TAC with a problem, they're going to point this out first :)
Wider support for IE8 (32& 64 / win 7, vista, xp) also officially support 10.6 OSX for SSL VPN.
Licensing is now aggregate, that is if you have 100 SSL VPN licenses on your active, and 100 on standby (this is required, even though only the active can terminate connections) starting with 8.3, your active ASA will support the aggregate (200) number of licenses. If there was ever a failure, and one is shipped back to Cisco, the other will support the aggregate for 30 days. That should be plenty of time to replace your backup.
You'll now use "objects" which is your IP to name mapping (think names). You can now define a server once, Mailserver=192.168.168.50, and put that MailServer in several different ACLs and NAT rules, you can then change the mapping and it will follow within the other portions of the configuration. The goal is to move towards a more object-oriented configuration, so it's simpler to configure things and make changes system-wide.
There is a new technique, where you can do a reverse many-to-one NAT, called one-to-many NAT. The idea is that you can have a single host on the inside, that is now matching multiple IP's on the outside, perhaps two different service providers.
ACLs now use a concept called REAL-IP, the idea of REAL-IP is that when you build that ACL for the outside interface, for server 192.168.168.50 that's being mapped to 50.50.50.50, you would previously think about what the packet looks like when it arrives on the interface. So think, on the outside, the packet is destined for 50.50.50.50 (there's a static NAT to the inside host). Well, now you'll use the REAL-IP, or the actual IP of the box. While frustrating for some of the veteran users, the idea is to make it easier for the new guys coming in. They can now look at access from a higher level, and permit or deny access to a server, or host regardless of thinking about the static NAT configuration.
There is also a concept of global ACLs, if you're familiar with Modular Policy Framework, think of a Policy-map that is applied globally. So the global ACL is that you can permit or deny traffic universally, ignoring the interfaces. This is a concept available on competitors products, so Cisco wanted to support it. The traditional ACL implementation is still supported, the idea though is if you have a lot of interfaces and you want to allow access to a specific host on all of them, you can write that rule in a global ACL and not have to create the same entry on every interface. While some of this seems frustrating for the veterans, the end goal is to make our lives easier.
Smart-call-home (introduced in 8.2.2) dumps stats and config (sanitized) details to Cisco, and you can login and view details about your equipment. You can see if there are TAC advisories for your versions of code, if there are issues you can open a TAC case from there. Another fun aspect is that you're looking at spec's on the box (CPU, Memory, Interface) and can log those periodically so it's great for base-lining and if you have an issue TAC can easily see the history right there.
Upgrading to 8.3 will perform a config-conversion, meaning your CLI configuration will look completely different from how it looked prior to upgrade. There will also be a file in flash that's basically a text file that shows any errors that occured in the upgrade.(I performed an upgrade of a fairly complex configuration without any errors by the way). If you're a CLI user, it will feel like you're on a different planet, if you're an ASDM user, you may not be real sure what's different, as the look, feel,and terminology is almost identical.
Your existing config is backed-up to flash, and there is actually a downgrade command, so if you do hate it you can roll back. *note* if you do use the downgrade command, realize that you must specify the name of the file which you can find in flash. (Similar to the downgrade process that appeared when moving from 6.3 to 7.0).
As you may recall from any of my classes, you can perform a zero-downtime upgrade, by moving one ASA at a time to 8.3 from 8.2 and you can have a fail-over pair on different code, and the 8.3 is no different. This should not be used for a long period of time however, it's recommended that you move one then the other as soon as you can. While they can run side-by-side you may get a copy of the 8.3 config (completely different core commands) pushed on top of the 8.2.
You can upgrade without the memory upgrade, and the code will load, but it throws an error. As you can imagine you will be forfeiting support if you chose to do this, as when you call TAC with a problem, they're going to point this out first :)
VTP vs GVRP, the winner? Neither..
In a large network, keeping VLANs synchronized can be a challenge. Having automatic tools to ensure automatic and correct distribution of VLANs helps to reduce the chance of some of our human errors and typo's, and also just to make our lives easier :)
Two fairly well-known protocols that are capable of automatic propagation of VLAN information are: VTP and GVRP. Both protocols provide similar functionality:
1. VTP is a proprietary protocol from Cisco. Which is great for distributing VLAN information between switches, so-long as it's an all Cisco network, things are great.
2. GVRP is a standards based solution, but suffers from a less widespread support, some vendors such as Cisco do not support GVRP (only on the old CatOS)
Either can work find if you only have a single vendor of switch to manage, however in a mixed environment you will likely need a SNMP Manamagent utility that can synchronize between the two, as there doesn't seem to be a Layer-2-protcol based solution, so keep your eyes open for plug-in's for your management applications, or support within the application for VLAN synchronization.
Two fairly well-known protocols that are capable of automatic propagation of VLAN information are: VTP and GVRP. Both protocols provide similar functionality:
1. VTP is a proprietary protocol from Cisco. Which is great for distributing VLAN information between switches, so-long as it's an all Cisco network, things are great.
2. GVRP is a standards based solution, but suffers from a less widespread support, some vendors such as Cisco do not support GVRP (only on the old CatOS)
Either can work find if you only have a single vendor of switch to manage, however in a mixed environment you will likely need a SNMP Manamagent utility that can synchronize between the two, as there doesn't seem to be a Layer-2-protcol based solution, so keep your eyes open for plug-in's for your management applications, or support within the application for VLAN synchronization.
Thursday, May 20, 2010
Useful protocol cheat sheets
I just wanted to share the link to www.packetlife.net this is a useful resource for anyone in the networking field. They have several different protocol "cheat sheets" that you can print and hang in the cube, or just review as needed. There are also notes from studying for different certification exams, which I imagine many of you will find useful.
Monday, January 11, 2010
ASA Technology Update
ASA Technology Update
For those of you who have taken the ASA course with me in the past (8.0 and earlier) this article will serve as a brief introduction to a few of the new features that Cisco has released recently that I thought you may be interested in. This may also prove helpful to those who have not taken the course but administer or are considering using the Cisco ASA 5500 series firewalls.
SNMP V3
Over the last several years when the topic of Simple Network Management Protocol (SNMP) was discussed by security engineers or auditors, the best practice was said to be disabling it. While this is not always an option due to the loss of functionality from a management perspective, it often proved to be a necessity from a security standpoint due to the lack of encryption of management traffic. While routers and switches have supported this functionality for quite some time it has just recently surfaced on the ASA.
As of version 8.2 of the ASA, SNMP V3 is supported, including support of DES, 3DES, and AES for protection of management data. This is great news to those of you who are required to support SNMP yet also expected to pass annual security audits. The only question that remains is whether or not your monitoring software supports SNMP V3.
Botnet Traffic Filter
Another very exciting feature released in the 8.2 release is the Botnet Traffic Filter. This new technology enables the ASA to monitor both inbound and outbound traffic and compare the external IP addresses and hostnames to a dynamic database of offensive IP addresses and domain names. Essentially, after purchasing the license for this feature (30 day trial available) your firewall gains insight to the latest known locations of botnet control points, SPAM distribution points, and other known hostile hosts.
The Cisco Security Intelligence Operations Group maintains this real-time blacklist. The CSIOG is comprised of hundreds of engineers and researches analyzing terabytes of data each day and building a global correlation rule set. Cisco has leveraged technologies that were originally part of the Ironport product (SenderBase) and is know referring to that technology as SensorBase
Imagine a scenario where a spear-phishing attack is used against an accountant or board-level executive. An attack that incorporates a new 0-day PDF exploit is run, which bypasses your antivirus, and the agent attempts to connect to a control point in Russia. If the control point is hosted in a known hostile net block, the ASA can prevent this connection from establishing and send a notification to the administrator of the attempted communication. This makes for a much happier ending that that of which you’ve been reading in the news stories lately.
AnyConnect Essentials
AnyConnect Essentials is a new licensing option for SSL VPN client on the ASA. With the introduction of SSL VPN, Cisco began charging “per connection fees” for remote VPN connections. This came as a shock to many of you who were accustomed to connecting as many users as the box allowed with IPSec and having never given a thought to licensing. The default WebVPN license on the ASA is 2 concurrent WebVPN users, each additional user requires additional licensing.
The traditional WebVPN licensing is a fairly cost prohibitive option for many of the customers I’ve spoken with, however it was only required if you were using WebVPN. The traditional IPSec VPN connections either site-to-site or remote access worked just as before with no licensing fees. The problem is that Cisco did not release a Windows 7 or a 64-bit windows IPSec client, which means for each remote user that has a 64 bit OS, you will need to have a license for each user if they will be connected to the ASA at the same time.
With the AnyConnect Essentials licensing you can purchase a reduced cost license that allows client-based users to build VPN connections if using the AnyConnect client. In other words, if you want to use the web portal (clientless) or support Cisco Secure Desktop you will need the traditional (more expensive) licenses. If you simply need to those 64bit Windows hosts to connect remotely while using a software client you can purchase the AnyConnect Essentials license (less expensive)
For those of you with Apple hardware running snow leopard (10.6) you will be relieved to know that even though you have a 64bit operating system there is built-in support for Cisco IPSec remote access, so you will not have to purchase any additional licensing or even install additional software as it’s built directly into the operating system (although a bit hidden). Simply add a new network interface, select VPN under interface and select CiscoIPSec under VPN Type. There is no need to launch a 3rd party application as done in the past.
Netflow (8.1)
Technically NetFlow support was introduced in 8.1, however I still consider it a very exciting, and relatively new feature. Also I’ve found that many administrators are not aware of it and it’s something I think you all should be using. As you may already know, Cisco Systems developed NetFlow as a way to export information regarding IP flows for detailed monitoring and auditing of network traffic. A flow is essentially the combination of the following pieces of information
• Source & destination IP address
• Source & destination port number
• IP protocol number
• Ingress interface
• Type of service
I like to compare NetFlow data to the detailed information that my cellular provider gives me each month on my bill. I can see whom I communicated with, how long I communicated to them, the times that the communication took place, and how Iwe communicated (whether it was a phone call or a text message). NetFlow is not a full IPlog or capture of all data, it is simply information about the flows of data. We collect these flows and then build detailed reports and statistics from data such as: when are your peak traffic hours, what are your top protocols, which are your top talkers, who’s moving the most data, which protocols or ports were seen today for the first time(botnet communication detection) etc.
NetFlow data is extremely useful to administrators, not only does it serve into a window of current network conditions, but once archived to a database you can gain insight to how long certain hosts have been communicating (days, weeks years) and how often. If there is a host that has been compromised and we see that it’s been communicating with a command & control point we can do a query against all recorded traffic and determine if other hosts are communicating with that same control point, how long this has been occurring, what data has been leaked etc.
It is my opinion that NetFlow collection could be useful to you, and while the full capabilities of NetFlow would be impossible to cover in this short article, I can only suggest you investigate these capabilities in the future. It may also be helpful to know that the ASA exports in a format called NetFlow V9 (or NetFlow Secure Event Logging). Without going into the differences in the different formats, I wanted to point out that the collector you use (central logging point) must support NetFlow V9. NetFlow V9 is not widely supported, however Plixar has a free product called Scrutinizer, which supports the ASA and NetFlow V9. I’ve used scrutinizer and I’m very happy with the results. Many of you will also be happy to know that Scrutinizer has a free version.
For those of you who have taken the ASA course with me in the past (8.0 and earlier) this article will serve as a brief introduction to a few of the new features that Cisco has released recently that I thought you may be interested in. This may also prove helpful to those who have not taken the course but administer or are considering using the Cisco ASA 5500 series firewalls.
SNMP V3
Over the last several years when the topic of Simple Network Management Protocol (SNMP) was discussed by security engineers or auditors, the best practice was said to be disabling it. While this is not always an option due to the loss of functionality from a management perspective, it often proved to be a necessity from a security standpoint due to the lack of encryption of management traffic. While routers and switches have supported this functionality for quite some time it has just recently surfaced on the ASA.
As of version 8.2 of the ASA, SNMP V3 is supported, including support of DES, 3DES, and AES for protection of management data. This is great news to those of you who are required to support SNMP yet also expected to pass annual security audits. The only question that remains is whether or not your monitoring software supports SNMP V3.
Botnet Traffic Filter
Another very exciting feature released in the 8.2 release is the Botnet Traffic Filter. This new technology enables the ASA to monitor both inbound and outbound traffic and compare the external IP addresses and hostnames to a dynamic database of offensive IP addresses and domain names. Essentially, after purchasing the license for this feature (30 day trial available) your firewall gains insight to the latest known locations of botnet control points, SPAM distribution points, and other known hostile hosts.
The Cisco Security Intelligence Operations Group maintains this real-time blacklist. The CSIOG is comprised of hundreds of engineers and researches analyzing terabytes of data each day and building a global correlation rule set. Cisco has leveraged technologies that were originally part of the Ironport product (SenderBase) and is know referring to that technology as SensorBase
Imagine a scenario where a spear-phishing attack is used against an accountant or board-level executive. An attack that incorporates a new 0-day PDF exploit is run, which bypasses your antivirus, and the agent attempts to connect to a control point in Russia. If the control point is hosted in a known hostile net block, the ASA can prevent this connection from establishing and send a notification to the administrator of the attempted communication. This makes for a much happier ending that that of which you’ve been reading in the news stories lately.
AnyConnect Essentials
AnyConnect Essentials is a new licensing option for SSL VPN client on the ASA. With the introduction of SSL VPN, Cisco began charging “per connection fees” for remote VPN connections. This came as a shock to many of you who were accustomed to connecting as many users as the box allowed with IPSec and having never given a thought to licensing. The default WebVPN license on the ASA is 2 concurrent WebVPN users, each additional user requires additional licensing.
The traditional WebVPN licensing is a fairly cost prohibitive option for many of the customers I’ve spoken with, however it was only required if you were using WebVPN. The traditional IPSec VPN connections either site-to-site or remote access worked just as before with no licensing fees. The problem is that Cisco did not release a Windows 7 or a 64-bit windows IPSec client, which means for each remote user that has a 64 bit OS, you will need to have a license for each user if they will be connected to the ASA at the same time.
With the AnyConnect Essentials licensing you can purchase a reduced cost license that allows client-based users to build VPN connections if using the AnyConnect client. In other words, if you want to use the web portal (clientless) or support Cisco Secure Desktop you will need the traditional (more expensive) licenses. If you simply need to those 64bit Windows hosts to connect remotely while using a software client you can purchase the AnyConnect Essentials license (less expensive)
For those of you with Apple hardware running snow leopard (10.6) you will be relieved to know that even though you have a 64bit operating system there is built-in support for Cisco IPSec remote access, so you will not have to purchase any additional licensing or even install additional software as it’s built directly into the operating system (although a bit hidden). Simply add a new network interface, select VPN under interface and select CiscoIPSec under VPN Type. There is no need to launch a 3rd party application as done in the past.
Netflow (8.1)
Technically NetFlow support was introduced in 8.1, however I still consider it a very exciting, and relatively new feature. Also I’ve found that many administrators are not aware of it and it’s something I think you all should be using. As you may already know, Cisco Systems developed NetFlow as a way to export information regarding IP flows for detailed monitoring and auditing of network traffic. A flow is essentially the combination of the following pieces of information
• Source & destination IP address
• Source & destination port number
• IP protocol number
• Ingress interface
• Type of service
I like to compare NetFlow data to the detailed information that my cellular provider gives me each month on my bill. I can see whom I communicated with, how long I communicated to them, the times that the communication took place, and how Iwe communicated (whether it was a phone call or a text message). NetFlow is not a full IPlog or capture of all data, it is simply information about the flows of data. We collect these flows and then build detailed reports and statistics from data such as: when are your peak traffic hours, what are your top protocols, which are your top talkers, who’s moving the most data, which protocols or ports were seen today for the first time(botnet communication detection) etc.
NetFlow data is extremely useful to administrators, not only does it serve into a window of current network conditions, but once archived to a database you can gain insight to how long certain hosts have been communicating (days, weeks years) and how often. If there is a host that has been compromised and we see that it’s been communicating with a command & control point we can do a query against all recorded traffic and determine if other hosts are communicating with that same control point, how long this has been occurring, what data has been leaked etc.
It is my opinion that NetFlow collection could be useful to you, and while the full capabilities of NetFlow would be impossible to cover in this short article, I can only suggest you investigate these capabilities in the future. It may also be helpful to know that the ASA exports in a format called NetFlow V9 (or NetFlow Secure Event Logging). Without going into the differences in the different formats, I wanted to point out that the collector you use (central logging point) must support NetFlow V9. NetFlow V9 is not widely supported, however Plixar has a free product called Scrutinizer, which supports the ASA and NetFlow V9. I’ve used scrutinizer and I’m very happy with the results. Many of you will also be happy to know that Scrutinizer has a free version.
Thursday, December 10, 2009
VRF - WTF?
While giving classes over the years I have encountered a great number of students who are not familiar with Virtual Routing and Forwarding (VRF) I explain that it's the practice of maintaining separate routing policies for different subnets / interfaces on the same piece of hardware. Well, the guys at Plixer did a great explanation that I wanted to reference that goes into more depth if you care :)
VRF article
Also The Plixer guys maintain a blog with new articles every few days dealing with network analysis.
VRF article
Also The Plixer guys maintain a blog with new articles every few days dealing with network analysis.
Netflow rap, from the scrutinizer guys, you know scrutinizer rocks right?
So I love geeky youtube videos to begin with, but add Cisco to it an one of my new favorite toys (Scrutinizer) and you have geek utopia :) The lyrics are great but it's super-fast.
Check it out here
Check it out here
Monday, November 16, 2009
Network visualization with Cisco ASA
I've implemented a lot of Cisco firewalls over the years, and one common thing that was missing was a method of doing external traffic analysis beyond syslog/snmp. Fortunately in recent versions of the ASA code Cisco has added support for Netflow output.
The only catch to this is that is generates Netflow V9 output (v5 is more commonly used). The only missing piece is a netflow collector. I have setup Scrutinizer and so far I'm very pleased.
Tuesday, February 3, 2009
DNS rewrite on PIX / ASA firewalls, MYSTERY SOLVED!
Ok so DNS Doctoring (aka dns rewrite) on the PIX's and ASA's have stumped me for some time now. I've implemented this a number of times, and sometimes it works flawlessly, other times not at all. Today it all became clear.
First off, what is DNS rewrite? When an internal host makes a query to an external DNS server about an internal resource the IP address returned will be external (see image) . In other words the host making the query is on the same network as the webserver which is Cisco.com. When the user queries a DNS server, for instance Verizon's DNS at 4.2.2.1, the answer returned will be a public IP. If you look at the static DNS mapping, within the ASA's configuration you will see that the public IP is mapped to an internal IP. Well, DNS rewrite monitors DNS traffic, and if a DNS reply contains an IP address that is used in a static statement it will alter the DNS reply to point to the inernal IP( again see image). Therefore, the client connects to the internal resource by it's actual IP address (not the static NAT). Where is the mystery then? Well I have configurd this many times, it's straight foreward, but it doesn't always work.
It turns out that if you are using static PAT, so a single IP address on the outside, doing port forward to different servers on the inside, DNS rewrite simply does not work, it's documented here:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#req
If you have individual IP's for each server it works fine.
This has eluded me for years but became clear today :)
First off, what is DNS rewrite? When an internal host makes a query to an external DNS server about an internal resource the IP address returned will be external (see image) . In other words the host making the query is on the same network as the webserver which is Cisco.com. When the user queries a DNS server, for instance Verizon's DNS at 4.2.2.1, the answer returned will be a public IP. If you look at the static DNS mapping, within the ASA's configuration you will see that the public IP is mapped to an internal IP. Well, DNS rewrite monitors DNS traffic, and if a DNS reply contains an IP address that is used in a static statement it will alter the DNS reply to point to the inernal IP( again see image). Therefore, the client connects to the internal resource by it's actual IP address (not the static NAT). Where is the mystery then? Well I have configurd this many times, it's straight foreward, but it doesn't always work.
It turns out that if you are using static PAT, so a single IP address on the outside, doing port forward to different servers on the inside, DNS rewrite simply does not work, it's documented here:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#req
If you have individual IP's for each server it works fine.
This has eluded me for years but became clear today :)
Monday, April 28, 2008
Cisco to partner with VMWare , Virtual switch on ESX?
While this news is about 6 months old it snuck by me somehow.
If you're not already aware, VMware's ESX Server is a small stable environment that is essentially a tiny linux distro, a few drivers and hypervisor in roughly 32MB of space. This leaves all of the remaining resource to be free for the guest operating systems. While this alone is exciting Cisco is rumored to be releasing a virtual switch and other technologies to combine with VMware.
http://www.virtualization.info/2007/07/cisco-to-announce-first-3rd-party.html
If you're not already aware, VMware's ESX Server is a small stable environment that is essentially a tiny linux distro, a few drivers and hypervisor in roughly 32MB of space. This leaves all of the remaining resource to be free for the guest operating systems. While this alone is exciting Cisco is rumored to be releasing a virtual switch and other technologies to combine with VMware.
http://www.virtualization.info/2007/07/cisco-to-announce-first-3rd-party.html
Subscribe to:
Posts (Atom)
Posts
