Tuesday, December 27, 2011
Wednesday, November 9, 2011
VirtualBox and serial consoles
- Enable serial ports for your virtual machine
- Select “Host Pipe”
- Enter /tmp/vboxconsole as the filename
- Use netcat to read the console: nc -U /tmp/vboxconsole
Wednesday, September 28, 2011
Monday, September 26, 2011
Wednesday, September 14, 2011
0x8086: Understanding TCP behavior in Linux 2.6
0x8086: Understanding TCP behavior in Linux 2.6: Lately I have been doing a lot of TCP performance analysis on different configuration settings. TCP is a very complex protocol and have plen...
Using and mounting a RAM disk in Ubuntu – The easy way
Using and mounting a RAM disk in Ubuntu – The easy way
# 2GB ramdisk
mkdir -p /ramdisk
mount -t tmpfs -o size=2048M tmpfs /ramdisk
# 2GB ramdisk
mkdir -p /ramdisk
mount -t tmpfs -o size=2048M tmpfs /ramdisk
Saturday, September 10, 2011
Restrict DHCP response on Cisco 3560 layer 3 switch
DHCP snooping is a DHCP security feature that provides network security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding table.
DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. It also gives you a way to differentiate between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch. For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces.
When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, it verifies that the source MAC address and the DHCP client hardware address match (the default). If the addresses match, the switch forwards the packet. If the addresses do not match, the switch drops the packet.
DHCP snooping considers DHCP messages that originate from any user-facing port that is not a DHCP server port as untrusted. From a DHCP snooping perspective, these untrusted user-facing ports must not send DHCP server type responses, such as DHCPOFFER, DHCPACK, or DHCPNAK.
DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. It also gives you a way to differentiate between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch. For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces.
When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, it verifies that the source MAC address and the DHCP client hardware address match (the default). If the addresses match, the switch forwards the packet. If the addresses do not match, the switch drops the packet.
DHCP snooping considers DHCP messages that originate from any user-facing port that is not a DHCP server port as untrusted. From a DHCP snooping perspective, these untrusted user-facing ports must not send DHCP server type responses, such as DHCPOFFER, DHCPACK, or DHCPNAK.
My story comes that there is a local network cluster connected to the department network. The department network has a DHCP server A which provides DHCP services for all ports that forwards DHCP requests to it. However, my local network cluster has a local DHCP server B too, which provides a local DHCP service for local nodes only. Therefore, a conflict happens when the local cluster node requests DHCP service. This request may get response from DHCP server A or get response from DHCP server B, and it depends on the fact that which is faster to take the necessary action and ring the bell. This conflict is totally caused by the nature of DHCP request broadcast that goes everywhere among the network.
My solution is to block the DHCP packets (DHCP response packets) from the un-necessary department DHCP server A. A sample of such commands on a Cisco 3560 layer 3 switch comes as follows:
cisco3560#configure terminal Enter configuration commands, one per line. End with CNTL/Z. cisco3560(config)#ip dhcp snooping cisco3560(config)#ip dhcp snooping vlan 99 /* my local network vlan number */ cisco3560(config)#ip dhcp snooping information option cisco3560(config)#interface gigabitEthernet0/48 /* my local DHCP server B access */ cisco3560(config-if)#ip dhcp snooping trust cisco3560(config-if)#exit cisco3560(config)#ip dhcp snooping verify mac-address cisco3560(config)#end cisco3560#configure terminal Enter configuration commands, one per line. End with CNTL/Z. cisco3560(config)#interface gigabitEthernet0/47 /* department DHCP server A access */ cisco3560(config-if)#no ip dhcp snooping trust cisco3560(config-if)#end cisco3560#copy running-config startup-config This example shows how to display the DHCP snooping configuration for a switch. cisco3560# show ip dhcp snooping This example shows how to display the DHCP snooping binding entries for a switch. cisco3560# show ip dhcp snooping binding
Reference:
Configuring DHCP Features and IP Source Guard
How to configure a Cisco Layer 3 switch-InterVLAN Routing
A brief history of TCP and its variance
Two main congestion control variations are those offered by TCP Tahoe and Reno. (since not long before, 2005)
The two algorithms were retrospectively named after the 4.3BSD operating system in which each first appeared (which were themselves named after Lake Tahoe and the city of Reno, Nevada). The “Tahoe” algorithm first appeared in 4.3BSD-Tahoe (which was made to support the CCI Power 6/32 “Tahoe” minicomputer), and was made available to non-AT&T licensees as part of the “4.3BSD Networking Release 1”; this ensured its wide distribution and implementation. Improvements, described below, were made in 4.3BSD-Reno and subsequently released to the public as “Networking Release 2” and later 4.4BSD-Lite. The “TCP Foo” names for the algorithms appear to have originated in a 1996 paper by Kevin Fall and Sally Floyd.
The two algorithms were retrospectively named after the 4.3BSD operating system in which each first appeared (which were themselves named after Lake Tahoe and the city of Reno, Nevada). The “Tahoe” algorithm first appeared in 4.3BSD-Tahoe (which was made to support the CCI Power 6/32 “Tahoe” minicomputer), and was made available to non-AT&T licensees as part of the “4.3BSD Networking Release 1”; this ensured its wide distribution and implementation. Improvements, described below, were made in 4.3BSD-Reno and subsequently released to the public as “Networking Release 2” and later 4.4BSD-Lite. The “TCP Foo” names for the algorithms appear to have originated in a 1996 paper by Kevin Fall and Sally Floyd.
Some useful command to save my time
In Linux Ubuntu, the command line ifconfig to configue network interface dynamically:
sudo ifconfig eth0 192.168.0.1 netmask 255.255.255.0 mtu 1500 up
In Linux Ubuntu, the command line ifconfig to configue network interface statically:
sudo vim /etc/network/interfaces, add info and restart network service
(sudo /etc/init.d/networking restart), for example:
auto eth0
iface eth0 inet static
address 192.168.0.1
gateway 192.168.0.254
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
mtu 1500
In Linux Ubuntu, the command to update "locate db" is
sudo updatedb
In FreeBSD, the command to update "locate db" is
/usr/libexec/locate.updatedb
In Linux Ubuntu, the command line to watch clock time is
watch -n 1 -t date
In Linux Ubuntu, the command line to make a patch is
diff -Naur linux-<version>/net/ipv4/tcp_probe.c linux-<version>net/ipv4/tcp_probe_update.c > patch.txt
Reference:
Howto: Ubuntu Linux convert DHCP network configuration to static IP configuration
FreeBSD IP Alias: Setup 2 or More IP address on One NIC
Subscribe to:
Posts (Atom)