Cisco SG200-50 Smart Switch Review

Posted: January 2nd, 2018 | Author: jordan | Filed under: Cisco, Networking | No Comments »

Enable VNC for Zentyal Community Server

Posted: February 27th, 2013 | Author: jordan | Filed under: Blog, DNS, Kerberos, krb5, LDAP, Linux, Networking, Work, Zentyal | 4 Comments »

Get a terminal session on your Zentyal box and install the VNC service

sudo apt-get install vnc4server

Next, run the server once to initialize a config file, kill the service and make a backup of the config file and then edit.

vncserver vncserver -kill :1 cp .vnc/xstartup .vnc/xstartup.bak nano .vnc/xstartup

Uncomment one line and add another:

# Uncomment the following two lines for normal desktop: unset SESSION_MANAGER # exec /etc/X11/xinit/xinitrc /usr/bin/lxsession -s LXDE -e LXDE

Then just launch
vncserver

Watch the output so you can ensure what port to connect to. For example, the following means my VNC server is listening on port 5901

jordan@mrsparkle:/etc/X11$ vncserver


New 'mrsparkle:1 (jordan)' desktop is mrsparkle:1

Starting applications specified in /home/jordan/.vnc/xstartup Log file is /home/jordan/.vnc/mrsparkle:1.log

How to Build an 802.1q LACP Trunk for Xen in CentOS 5.5

Posted: September 8th, 2011 | Author: jordan | Filed under: Blog, CentOS, Linux, Networking, Xen | No Comments »

Overview

In this how-to we’re going to install CentOS 5.5 and prep it to become a virtual machine server. Before proceeding PLEASE read our Xen software page so you understand how the VM and network topology works. This how-to was built combining various methods publicly already available. If you find some copy and pasted text just remember: a good sysadmin is a lazy sysadmin.

Prerequisites

LACP bonded 802.1q trunk with necessary VLAN’s assigned

Installation

Install CentOS 5.5, during the package selection screen make sure to enable the Virtualization option.

Configuration

First let’s make sure that xen is running properly. Log into the GUI of the server, if you do not have a GUI then log into an ssh session as root with X forwarding on. Run virt-manager from the console. You should see “dom0” running, if you double click on it you’ll be able to see the statistics for this domain and how much resources it is consuming. If you cannot see this or if virt-manager does not find a dom0 to connect to you have done something wrong. I cannot help you.

1. Physical Networking Devices
What we first need to do is setup our networking devices.
Edit some files in /etc/sysconfig/network-scripts. Remember that bond0 is the physical interface that the trunk is connected to therefore it does not need an IP address.
# ifcfg-bond0 DEVICE=bond0 BOOTPROTO=none ONBOOT=yes USERCTL=no TYPE=BOND BONDING_OPTS="mode=4"

#ifcfg-eth0 DEVICE=eth0 BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no TYPE=Ethernet HWADDR:(MAC-ADDRESS OF ETH0)

#ifcfg-eth1 DEVICE=eth1 BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no TYPE=Ethernet HWADDR:(MAC-ADDRESS OF ETH1F)

Then for every VLAN that you are passing in your trunk create a file as follows. Please replace the ‘N’ with the VLAN ID number
[root@xentest jeunson]# more /etc/sysconfig/network-scripts/ifcfg-bond0.N DEVICE=bond0.N BOOTPROTO=none #IPADDR=192.168.100.51 #NETMASK=255.255.255.0 ONBOOT=yes VLAN=yes TYPE=BOND

Note how the IP address is commented out on this VLAN interface. You can assign an IP address to the VLAN interface that will be the management interface for the hardware.

Finally don’t forget to add the following line to /etc/modprobe.conf
alias bond0 bonding

Now that you’ve created the VLANs and assigned a management interface we edit the file /etc/sysconfig/network
[root@xentest jeunson]# more /etc/sysconfig/network NETWORKING=yes NETWORKING_IPV6=no HOSTNAME=xentest.example.com GATEWAY=192.168.101.254 GATEWAYDEV=bond0.101

Now restart the networking with /etc/init.d/network restart It should restart with out any errors
Shutting down interface bond0.100: Removed VLAN -:bond0.100:- [ OK ] Shutting down interface bond0.101: Removed VLAN -:bond.101:- [ OK ] Shutting down interface bond: [ OK ] Shutting down loopback interface: [ OK ] Disabling IPv4 packet forwarding: net.ipv4.ip_forward = 0 [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface bond0.100: Added VLAN with VID == 100 to IF -:bond0:- [ OK ] Bringing up interface bond0.101: Added VLAN with VID == 101 to IF -:bond0:- [ OK ]

2. Xen Networking Scripts
First modify /etc/xen/xend-config.asp and change the netdev device from eth0 to bond0. You’ll probably have to reboot the computer.

A.Modify the network-bridge script

Now that we’re done that we need to configure Xen to tell it what networking interfaces to use. First make a backup of the xen network-bridge script and edit as follows.
cp /etc/xen/scripts/network-bridge /etc/xen/scripts/network-bridge.orig
Change around line 78 from
[ -f "/sys/class/net/$1/bonding/slaves" ] to [ -f "/sys/class/net/$1/bonding/slaves" ] || [ -f /proc/net/vlan/$1 ]

B. Modfiy xend-config.sxp
The second change involves modifying the xend configuration file to use a new network initialization script.
[root@xentest scripts]# cd /etc/xen [root@xentest scripts]# cp -p xend-config.sxp xend-config.sxp-dist
Change the network-script configuration directive to the new script name – such as network-multi-bridge. After the modification:
[root@xentest xen]# diff xend-config.sxp-dist xend-config.sxp 91c91 < (network-script network-bridge) --- > (network-script network-multi-bridge)
C. Create network-multi-bridge script
This script uses the two VLAN interfaces previously defined.

[root@xentest scripts]# cd /etc/xen/scripts [root@xentest scripts]# more network-multi-bridge #!/bin/sh dir=$(dirname "$0") "$dir/network-bridge" "$@" vifnum=0 netdev=bond0 bridge="xbr_trunk"

/sbin/ifup eth0.100
“$dir/network-bridge” “$@” vifnum=1 bridge=”xbr_v100″ netdev=”bond0.100″
/sbin/ifup eth0.101
“$dir/network-bridge” “$@” vifnum=2 bridge=”xbr_v101″ netdev=”bond0.101″

At this point you should reboot your server to make sure that everything comes up cleanly. Use the logs to debug problems and look out for which type of bond your computer connects to the switch as.

How to Force Propagation on Apple Secondary DNS Server

Posted: May 16th, 2011 | Author: jordan | Filed under: Blog, DNS, Mac OS X Server, Networking, Snow Leopard | Tags: Apple, dns, Mac OS X, mac os x server, network, networking, snow leopard, snow leopard server | No Comments »

As you all probably know that using Apple’s DNS server can be challenging at times. If you make changes on the primary you usually have to wait some time before those changes propagate to the secondaries. However with the following commands you can force this propagation without having to nuke files or folders in /var/named

1. On the secondary server, run this command. (use whatever zone you want to transfer in place of lan.example.com
rndc -p 54 retransfer lan.example.com IN com.apple.ServerAdmin.DNS.public

2. Reload configuration
rndc -p 54 reload

3. Forcing client cache flush
dscacheutil -flushcache

The reason I think this is better in my opinion is it gets rid of the potential “oops” of deleting critical files in /var/named.

How to Calculate MTU for Tunnels

Posted: April 7th, 2011 | Author: jordan | Filed under: Blog, Networking | Tags: gre, ipsec, mtu, networking, tunnels | 3 Comments »

WARNING: BORING ALERT!!!!

Packet Fragmentation Example

If you have any tunnels in your network you may notice at times packet loss between subnets or perhaps stalled web sessions. This usually has to do with a combination of MTU negotiation and packet fragmentation.

MTU 101

Maximum Transmission Unit refers to how much data in bytes the data layer can send forward. For ethernet the size is 1500 bytes, which coincides with how much data can fit in an ethernet frame. Within the MTU is another size called MSS (Maximum Segment Size) which refers to how much TCP data can be transmitted. This is also known as the payload and is usually 1460 bytes. The 40 bytes difference between the MTU and MSS sizes are for TCP/IP headers. But this can create a problem when GRE is introduced.

Enter the Tunnel

The big problem with GRE is that it doesn’t fit into the 7 layer dip of the OSI model. It acts as a separator between the network and transport layers. GRE adds a header to all the packets that will traverse the GRE tunnel, thus consume some of the 1500 bytes of the ethernet frame. The MTU then needs to be decreased to allow the packet to fit within the frame. This can result in packet fragmentation or packet loss as some packets will have a “don’t fragment” bit set.

Determine MTU

To optimize your network performance it would be best practice to determine the MTU through the tunnel. This size my vary depending upon encapsulation, encryption, and routing. To determine the MTU size we will conduct some tests with “don’t fragment” ping packets from a host on one side of the tunnel to a host on the other side of the tunnel.

First let’s take a look at how “don’t fragment” pings work. We’re going to send two pings (-c 2) with the don’t fragment (-D) bit set and specify the payload to be 1472 bytes (-s 1472)
homer:~ jordan$ ping -D -c 2 -s 1472 4.2.2.2 PING 4.2.2.2 (4.2.2.2): 1472 data bytes 1480 bytes from 4.2.2.2: icmp_seq=0 ttl=54 time=37.163 ms 1480 bytes from 4.2.2.2: icmp_seq=1 ttl=54 time=34.799 ms

This shows us that the MTU between us and 4.2.2.2 which is a public root DNS server is 1500. The difference between the MTU size (1500) and ping payload size (1472) is the ICMP headers of 28 bytes. This is important to note, as ping payloads used to test the MTU must be 28 bytes lower than the MTU value you are testing.

If we add one byte to this test it will cause the ping to be lost.
homer:~ jordan$ ping -D -c 2 -s 1473 4.2.2.2 PING 4.2.2.2 (4.2.2.2): 1473 data bytes ping: sendto: Message too long ping: sendto: Message too long

So let’s try and determine the MTU for this sample network. We have a host on each side with a default MTU of 1500 and tunnel in between the two of them. To determine the MTU we issue the command listed above
homer:~ jordan$ ping -D -c 2 -s 1472 172.16.10.10 PING 172.16.10.10 (172.16.10.10): 1472 data bytes ping: sendto: Message too long ping: sendto: Message too long

Clearly this shows us the payload is too large and thus the MTU is lower than 1500. So let’s lower the payload by 10 bytes and round it down, if it fails decrement the payload by 10 bytes again and again while testing until you have a successful test. Then increment by 1 byte until it stops working. The last test payload size, plus 28 bytes is your MTU.

Example:
homer:~ jordan$ ping -D -c 2 -s 1460 172.16.10.10 PING 172.16.10.10 (172.16.10.10): 1460 data bytes ping: sendto: Message too long ping: sendto: Message too long homer:~ jordan$ ping -D -c 2 -s 1450 172.16.10.10 PING 172.16.10.10 (172.16.10.10): 1450 data bytes ping: sendto: Message too long ping: sendto: Message too long homer:~ jordan$ ping -D -c 2 -s 1440 172.16.10.10 PING 172.16.10.10 (172.16.10.10): 1440 data bytes 1448 bytes from 172.16.10.10: icmp_seq=0 ttl=254 time=72.199 ms 1448 bytes from 172.16.10.10: icmp_seq=1 ttl=254 time=78.266 ms homer:~ jordan$ ping -D -c 2 -s 1441 172.16.10.10 PING 172.16.10.10 (172.16.10.10): 1441 data bytes ping: sendto: Message too long ping: sendto: Message too long
Tada, the last payload that worked was 1440, therefore our MTU is 1468. Ping payload size of 1440 bytes + ICMP header of 28 bytes = MTU of 1468 bytes

I hope you enjoyed yourself as much as I have, please feel free to leave questions in the comments here.

Calculate Subnet Network Masks and CIDR notation

Posted: April 6th, 2011 | Author: jordan | Filed under: Blog, Networking | Tags: calculate, networking, subnets | No Comments »

How to calculate the network mask from a CIDR notation, or a CIDR notation from a network mask. To figure this out we need to understand the relationship between the two. A network mask when written in binary will be 32 bits long. This also means that each octet of a network mask can hold a total of 8 bits.
255.255.0.0 == 11111111.11111111.00000000.00000000 255.255.255.0 == 11111111.11111111.11111111.00000000 255.255.255.192 == 11111111.11111111.11111111.11000000

Example 1-1: Calculate the network mask from CIDR Notation /16

1. First subtract the CIDR notation from the total number of bits available in CIDR notation. This is the number of bits occupied in the mask.

2. Next, place no more than 8 bits into each octet starting with the one the on the right.

3. Move the bits into an exponent of two and calculate

4. Subtract one from each octet and you now have your reverse mask

5. Inverse the reverse mask to finally find out your network mask

The network mask for CIDR notation /16 is 255.255.0.0

Example 2-1: Calculate the CIDR notation from network mask 255.255.0.0

This is exactly the procedure above but just reversed

1. Inverse the network mask to find out your reverse mask

2. Add one to each populated octet

3. Find the exponent value of 2 for each octet (PROTIP: double 2 in your head until you hit the number, that is the number of bits ie {2 4 8 16} = 4…)

4. Add up all the exponent values and subtract from 32

Example 1-2: Calculate the network mask from CIDR Notation /13