My lab will require me to console into 4 switches. I don’t want to buy another router to be my terminal server, and I also don’t want to have to swap out console cables every 2 minutes.
Thankfully I don’t have to. Linux has a handy tool to turn a regular PC with a bunch of USB serial ports into a terminal server.
All you need is a bunch of USB ports (a USB hub will do), some rollover cables and a bunch of these which I found on ebay:
I bought 3 of the above, as the PC itself already has 1 serial port.
The app I’m going to use is called ser2net. Let’s install it
darreno@CCIE:~$ sudo apt-get install ser2net
Now let’s see if Ubuntu 10.10 has reconised my USB serial cables:
darreno@CCIE:~$ dmesg | grep tty [ 0.000000] console [tty0] enabled [ 0.932016] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.932314] 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 6.625434] usb 6-1: ch341-uart converter now attached to ttyUSB0 [ 6.649441] usb 6-3: ch341-uart converter now attached to ttyUSB1 [ 6.672443] usb 3-2: ch341-uart converter now attached to ttyUSB2
Looks good so far. ttyS0 is my physical serial port and the ttyUSBx ports are the 3 USB-Serial cables. I’ll now configure ser2net to map TCP ports to my onboard port and my 3 USB ports.
darreno@CCIE:~$ sudo vi /etc/ser2net.conf
At the bottom of that file you’ll see this:
2000:telnet:600:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT banner 2001:telnet:600:/dev/ttyS1:9600 8DATABITS NONE 1STOPBIT banner 3000:telnet:600:/dev/ttyS0:19200 8DATABITS NONE 1STOPBIT banner 3001:telnet:600:/dev/ttyS1:19200 8DATABITS NONE 1STOPBIT banner
Let’s change it to this:
2000:telnet:600:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT banner 2001:telnet:600:/dev/ttyUSB0:9600 8DATABITS NONE 1STOPBIT banner 2002:telnet:600:/dev/ttyUSB1:9600 8DATABITS NONE 1STOPBIT banner 2003:telnet:600:/dev/ttyUSB2:9600 8DATABITS NONE 1STOPBIT banner
save and quit, then restart ser2net:
darreno@CCIE:~$ sudo /etc/init.d/ser2net restart * Restarting Serial port to network proxy ser2net [ OK ]
Now to test!
My dynamips box has an IP of 10.20.30.11. If I want to get to the physical serial port from my laptop, I only need to do this:
C:\Users\Darren>telnet 10.20.30.11 2000 ser2net port 2000 device /dev/ttyS0 [9600 N81] (Debian GNU/Linux) C3560# C3560#
What about a USB cable?
C:\Users\Darren>telnet 10.20.30.11 2003 ser2net port 2003 device /dev/ttyUSB2 [9600 N81] (Debian GNU/Linux) C3550# C3550#
I use a tabbed telnet/SSH app called ZOC. From there I can specify the telnet ports and which switch they map to. I can now console into all of them without the need of a terminal server. The actual USB-Serial cables only cost me £2 each, and you can have loads of them.
(2011/02/19) EDIT: Dariush below mentioned that you can get multiple serial adaptors through a single USB port. This is an example: http://www.amazon.co.uk/NEWLink-Serial-Quad-Cable-Adaptor/dp/B003DA5TG4
If you don’t want to go the USB hub root, this could certainly work. Serial cables aren’t exactly high bandwidth. I’ve even found an 8 port model here, but no price: http://www.delock.com/produkte/gruppen/USB+Adapter/Delock_Adapter_USB_8x_Serial_61519.html
At home I’ve been using a Linksys WRT54GL loaded with DD-WRT for quite some time. I think it’s time has come and gone though. 100Mb LAN speed and no ‘N’ wireless speed.
I’ve decided upon the Asus RT-N16 and I’m going to load Tomato USB on it. This thing supports Wireless ‘N’, has gigabit lan, a faster CPU and hopefully better performance.
I wanted to do a baseline performance comparison of my current set up first. I have an Acer Revo 3610 in my lounge hard wired to my router. The 3610 has a gig onboard NIC. My PC has a gig NIC and is also hardwired. I have a Synology ds210j NAS that has a gig NIC onboard and is hardwired. I also have a Acer Revo 3600 in my bedroom which currently uses it’s onboard Wireless ‘G’ NIC, which xbmc doesn’t seem to like playing media through: http://mellowd.co.uk/ccie/?p=1081 – I also have various other wireless devices.
I have iperf installed on all my main devices, so let’s see what kind of results I get with the Linksys WRT54GL
NAS <==> 100Mb Hard Wired 3610
Simba> iperf -s -p 555 -i 10 ------------------------------------------------------------ Server listening on TCP port 555 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ mellowd@XBMCLive:~$ iperf -c 10.20.30.4 -p 555 -i 10 -t 90 ------------------------------------------------------------ Client connecting to 10.20.30.4, TCP port 555 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.30.140 port 50237 connected with 10.20.30.4 port 555 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 112 MBytes 94.3 Mbits/sec [ 3] 10.0-20.0 sec 112 MBytes 94.1 Mbits/sec [ 3] 20.0-30.0 sec 112 MBytes 94.0 Mbits/sec [ 3] 30.0-40.0 sec 112 MBytes 94.1 Mbits/sec [ 3] 40.0-50.0 sec 112 MBytes 94.1 Mbits/sec [ 3] 50.0-60.0 sec 112 MBytes 94.1 Mbits/sec [ 3] 60.0-70.0 sec 112 MBytes 94.1 Mbits/sec [ 3] 70.0-80.0 sec 112 MBytes 94.1 Mbits/sec [ 3] 80.0-90.0 sec 112 MBytes 94.0 Mbits/sec [ 3] 0.0-90.0 sec 1010 MBytes 94.1 Mbits/sec
mellowd@XBMCLive:~$ sudo iperf -s -p 555 -i 10 ------------------------------------------------------------ Server listening on TCP port 555 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ Simba> iperf -c 10.20.30.140 -p 555 -i 10 -t 90 ------------------------------------------------------------ Client connecting to 10.20.30.140, TCP port 555 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.30.4 port 51931 connected with 10.20.30.140 port 555 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 112 MBytes 94.1 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 10.0-20.0 sec 112 MBytes 94.1 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 20.0-30.0 sec 112 MBytes 94.2 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 30.0-40.0 sec 101 MBytes 84.5 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 40.0-50.0 sec 54.5 MBytes 45.7 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 50.0-60.0 sec 54.6 MBytes 45.8 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 60.0-70.0 sec 54.5 MBytes 45.8 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 70.0-80.0 sec 54.5 MBytes 45.7 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 80.0-90.0 sec 54.6 MBytes 45.8 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 0.0-90.0 sec 710 MBytes 66.2 Mbits/sec
I had already tested the wireless Revo 3600, but here were it’s results:
NAS <==> Wireless Revo
Simba> iperf -s -p 555 -i 10 ------------------------------------------------------------ Server listening on TCP port 555 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ mellowd@XBMCLive:~$ iperf -c 10.20.30.4 -p 555 -i 10 -t 600 ------------------------------------------------------------ Client connecting to 10.20.30.4, TCP port 555 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.30.110 port 45553 connected with 10.20.30.4 port 555 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 19.2 MBytes 16.1 Mbits/sec [ 3] 10.0-20.0 sec 19.4 MBytes 16.3 Mbits/sec [ 3] 20.0-30.0 sec 18.6 MBytes 15.6 Mbits/sec [ 3] 30.0-40.0 sec 18.4 MBytes 15.4 Mbits/sec [ 3] 40.0-50.0 sec 18.5 MBytes 15.5 Mbits/sec [ 3] 50.0-60.0 sec 18.4 MBytes 15.4 Mbits/sec [ 3] 60.0-70.0 sec 15.7 MBytes 13.1 Mbits/sec [ 3] 70.0-80.0 sec 16.9 MBytes 14.2 Mbits/sec . . . . . . [ 3] 270.0-280.0 sec 18.7 MBytes 15.7 Mbits/sec ^C[ 3] 0.0-285.7 sec 503 MBytes 14.8 Mbits/sec
Basically an avergage of between 66-94Mb on the wire and 14.8Mb on the wireless. How does the Asus hold up?
NAS <==> 1Gb Hard Wired 3610
Simba> iperf -s -p 555 -i 10 ------------------------------------------------------------ Server listening on TCP port 555 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ mellowd@XBMCLive:~$ iperf -c 10.20.30.4 -p 555 -i 10 -t 90 ------------------------------------------------------------ Client connecting to 10.20.30.4, TCP port 555 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.30.6 port 44203 connected with 10.20.30.4 port 555 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 752 MBytes 631 Mbits/sec [ 3] 10.0-20.0 sec 753 MBytes 632 Mbits/sec [ 3] 20.0-30.0 sec 742 MBytes 622 Mbits/sec [ 3] 30.0-40.0 sec 751 MBytes 630 Mbits/sec [ 3] 40.0-50.0 sec 747 MBytes 627 Mbits/sec [ 3] 50.0-60.0 sec 743 MBytes 623 Mbits/sec [ 3] 60.0-70.0 sec 750 MBytes 629 Mbits/sec [ 3] 70.0-80.0 sec 748 MBytes 627 Mbits/sec [ 3] 80.0-90.0 sec 746 MBytes 626 Mbits/sec [ 3] 0.0-90.0 sec 6.57 GBytes 627 Mbits/sec
NAS <==> Wireless 3610
mellowd@XBMCLive:~$ iperf -c 10.20.30.4 -p 777 -i 10 -t 60 ------------------------------------------------------------ Client connecting to 10.20.30.4, TCP port 777 TCP window size: 16.00 KByte (default) ------------------------------------------------------------ [196] local 10.20.30.14 port 55378 connected with 10.20.30.4 port 777 [ ID] Interval Transfer Bandwidth [196] 0.0-10.0 sec 38.9 MBytes 32.6 Mbits/sec [196] 10.0-20.0 sec 37.6 MBytes 31.5 Mbits/sec [196] 20.0-30.0 sec 38.8 MBytes 32.5 Mbits/sec [196] 30.0-40.0 sec 39.3 MBytes 33.0 Mbits/sec [196] 40.0-50.0 sec 36.1 MBytes 30.3 Mbits/sec [196] 50.0-60.0 sec 40.0 MBytes 33.6 Mbits/sec [196] 0.0-60.0 sec 231 MBytes 32.2 Mbits/sec
Basically, the wired LAN has improved loads, but not exactly running at 1Gbps. Also the wireless speed has doubled, but nothing to write home about. It’s great for surfing, but forget about streaming HD video
My last post about Traceroute over here: http://mellowd.co.uk/ccie/?p=609 – got some interesting conversation going on in the comments.
Basically there is quite a big difference in the way in which Windows and Linux handle traceroute. I tested on both Windows 7 and Ubuntu 10.04, but my guess is that all Windows follow the same format as do all *nix’s (please let me know if otherwise though!)
I would recommend reading the above post again quickly to get all the basics out the way before we delve into the differences.
Step-wise, this is what happens on Windows:
- The OS send a DNS PTR request to 1.2.2.4.in-addr.arpa to get the hostname for 4.2.2.1
- I get a DNS PTR response giving me a hostname
- The OS send an ICMP ECHO request with a TTL of 1
- I get an ICMP TTL Exceeded packet back from my local router
- 3 & 4 above happens twice more
- The OS send a DNS PTR request to my local router
- My local router responds with it’s hostname
- The cycle above (3-7) is then repeated with a TTL of 2, then 3 and so on
- We finally get to 4.2.2.1 – which sends back an ICMP ECHO reply – Once I get 3 the job is complete.
Ubuntu does this completely differently though. Step-wise this is what’s going on:
- The OS immidiately sent 3 UDP packets with a high port number straight to 4.2.2.1 with a TTL of 1
- The local router responded with 3X ICMP TTL Exceeded message
- The above (1 & 2) is then repeated until we get to 4.2.2.1
- 4.2.2.1 does not generate a ICMP ECHO reply as an ECHO request was not sent. Rather we get 3 ICMP Code 3 (Port unreachable) replies
- The OS now throws out 7 DNS PTR request specifically to each IP it determined in the path from above (Including 4.2.2.1 iself!)
- As soon as all the replies come, the job is complete.
The main differences are that Windows will send a DNS PTR request from the start, then send ICMP ECHO requests. At each hop it’ll send a DNS PTR request and then move onto the next hop.
Linux starts with sending UDP packets to a high port number straight away. When it finally gets to the last hop it’ll then send out a mass DNS PTR request to every hop in the path that it has determined.
Traceroute is a powerful tool. Extremely useful when checking the path of a packet through the network. But how does it ACTUALLY work? What is REALLY going on?
Layer3 packets all have a TTL. A Time To Live. If a router receives a packet with a TTL of 1 (and the packet is addresses to a host not directly connected to this router) it will drop the packet. It will also then create an ICMP error packet and send it back to the original source of the packet to let it know that the address was unreachable this time.
If you ping another machine, the OS will generally create a TTL of 255 for sent packets, though it doesn’t HAVE to be 255.
Traceroute will force an ICMP error message so it can get more information from each hop in the path.
As an example, let’s run a quick traceroute to 4.2.2.1 and see what it gives us:
C:\Users\Darren>tracert 4.2.2.1 Tracing route to vnsc-pri.sys.gtei.net [4.2.2.1] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms DD-WRT [10.50.80.1] 2 8 ms 9 ms 8 ms 10.3.280.1 3 8 ms 9 ms 26 ms walt-cam-1a-ge96.network.virginmedia.net [80.1.170.69] 4 18 ms 7 ms 8 ms popl-core-1a-ae2-0.network.virginmedia.net [195.182.175.229] 5 8 ms 6 ms 16 ms popl-bb-1a-as2-0.network.virginmedia.net [213.105.174.234] 6 31 ms 15 ms 15 ms 195.50.91.69 7 12 ms 13 ms 31 ms ae-11-51.car1.London1.Level3.net [4.69.139.66] 8 14 ms 16 ms 22 ms vnsc-pri.sys.gtei.net [4.2.2.1] Trace complete.
I’ve loaded up Wireshark to tell me exactly what’s going on. The very first packet sent from my PC was sent with a destination IP of 4.2.2.1 – but with a TTL of only 1.
When my router (10.50.80.1) received that packet, it noticed that the TTL was 1, but also that 4.2.2.1 was not directly connected to it. It responded to my PC with an ICMP code 11 – Time-to-live exceeded. It also responded with it’s own source address.
Traceroute now knows that the very first hop to 4.2.2.1 happens to be my local router. It also knows that the routers IP is 10.50.80.1 – It send 3 ECHO reply requests with a TTL of 1. This is the reason you see the 3 values in the traceroute output
It doesn’t stop there though. As soon as traceroute knows that 10.50.80.1 is the first hop, it’ll ask 10.50.80.1 what it’s hostname is via a DNS PTR request. The router will respond to my PC with a DNS PTR response letting it know the hostname. Now traceroute knows what the IP address and hostname is for the first hop. Note that not ALL devices on the internet will respond with a PTR record and so you won’t ALWAYS get a hostname.
Traceroute will now start again and send 3 more packets with a TTL of 2. Exactly the same will happen as above, but for the second hop in the path. This will continue to happen until we eventually get to the host, or we run into the maximum hop count.
When we finally get ICMP echo replies from 4.2.2.1 – traceroute knows it’s job is complete.
btw, traceroute attempts to get PTR records from the devices in the path only when it gets a TTL time exceeded reply. The actual host you are trying to get to is different though. As soon as I ran traceroute 4.2.2.1 it immediately tried to get the PTR record of 4.2.2.1 first. Once it had that it started with all of the above.
The diagram is the same as my last VPN Lab. Also it uses my MPLs topology found over here: http://mellowd.co.uk/ccie/?p=522
This is the topology for this lab (click for a bigger image):
- Customer1 and Customer 2 both have MPLS vpn’s through the ISP core.
- Customer1 is using OSPF and Customer2 is using EIGRP
- Customers should have no access to each others networks
- Customers should be able to reach all their sites from all their sites
- The ISP wants to monitor the CPE routers via their monitoring server. Create another loopback on each CPE router and give them all a /32 loopback in the 172.16.1.1/24 range – i.e. 172.16.1.1/32 for CPE1, 172.16.1.2/32 for CPE2 and so on
- Ensure the monitoring router can get to all these /32 routes (and ONLY these /32 routes) – It should not know about any customer routes – CPE routers should only see their OWN loopbacks in the routing table
- Now enable CPE3 and CPE6 to see each others subnets. All other CPE routers should see no change in their routing tables
Comments