13 Jan

Vyatta based VyOS – Linux based network OS

VyOS is quite interesting OS. It’s a open source Linux based network operating system based on Vyatta. It’s config style seems bit like JunOS in terms of hierarchy and set/edit/delete options while editing configuration.

 

Can one use it in a small ISP or a Corporate LAN setup? 

Someone asked me recently if we can have complete open source based router in smaller network doing basic stuff. Not with not-so-streamlined Linux shell but networking OS where network engineers favorite tool “?” works in CLI with options.

Let’s take a possible case with bunch of routers, a server with speedtest-mini running on it and end desktop with Ubuntu-desktop on it along with VyOS based router. Goal here is to have basic features to work (to start with!). I am conducting this test and setup on the VM infrastructure at home but that should have zero impact/configuration of network devices and hence not going to focus on that part. All devices including server, desktop and router are pretty much running on virtual machines or KVM containers.

 

 

To configure and test:

  1. Configuration of interfaces and basic static routing with reachability
  2. Source-NAT on RTR01 for LAN side connectivity with DHCP
  3. Traffic shaping on RTR01 on per user basis
  4. IPv6 autoconfig
  5. Basic firewalling to protect server01

 

Note: I am treating 10.x.x.x range here as public IP wan range in demo while 192.168.1.0/24 as LAN IPs which would be NATted behind WAN IP.

 

1.Static routing with reachability

Configuring VyOS is very much like that of JunOS – basic edit to go inside to hierarchal levels and set to add to config, delete to delete from config.

 

Configuration on transit router’s interface

anurag@Transit-Router# show interfaces
 ethernet eth0 {
     address 10.10.10.1/30
     description "***Connected to server01***"
     duplex auto
     ipv6 {
         address {
             autoconf
         }
         dup-addr-detect-transmits 1
     }
     smp_affinity auto
     speed auto
 }
 ethernet eth1 {
     address 10.10.10.5/30
     description "***Connected to RTR01***"
     duplex auto
     smp_affinity auto
     speed auto
 }
 ethernet eth2 {
     address dhcp
     description "***Management from home LAN***"
     duplex auto
     smp_affinity auto
     speed auto
 }
 loopback lo {
 }
[edit]
anurag@Transit-Router#

 

Configuration on RTR01 interfaces

anurag@rtr01# show interfaces
 ethernet eth0 {
     address 10.10.10.6/30
     description "***Link to Transit router***"
     duplex auto
     ipv6 {
         address {
             autoconf
         }
         dup-addr-detect-transmits 1
     }
     smp_affinity auto
     speed auto
 }
 ethernet eth1 {
     address 192.168.1.1/24
     description "***LAN side interface***"
     duplex auto
     smp_affinity auto
     speed auto
     }
 }
 ethernet eth2 {
     address dhcp
     description "***Magamenet access from production LAN***"
     duplex auto
     smp_affinity auto
     speed auto
 }
 loopback lo {
 }
[edit]
anurag@rtr01#

 

Transit router is without any default route, while server01 & RTR01 have default towards transit and as usual end user desktops have default towards RTR01.

anurag@rtr01# show protocols static
 route 0.0.0.0/0 {
     next-hop 10.10.10.5 {
     }
 }
[edit]
anurag@rtr01#

 

This gives basic connectivity from RTR01 all way up to the server01.

 

Connectivity test

anurag@rtr01:~$ ping 10.10.10.5 count 5
PING 10.10.10.5 (10.10.10.5) 56(84) bytes of data.
64 bytes from 10.10.10.5: icmp_req=1 ttl=64 time=0.728 ms
64 bytes from 10.10.10.5: icmp_req=2 ttl=64 time=0.560 ms
64 bytes from 10.10.10.5: icmp_req=3 ttl=64 time=0.405 ms
64 bytes from 10.10.10.5: icmp_req=4 ttl=64 time=0.516 ms
64 bytes from 10.10.10.5: icmp_req=5 ttl=64 time=0.545 ms

--- 10.10.10.5 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.405/0.550/0.728/0.108 ms
anurag@rtr01:~$
anurag@rtr01:~$
anurag@rtr01:~$ ping 10.10.10.2 count 5
PING 10.10.10.2 (10.10.10.2) 56(84) bytes of data.
64 bytes from 10.10.10.2: icmp_req=1 ttl=63 time=0.836 ms
64 bytes from 10.10.10.2: icmp_req=2 ttl=63 time=0.717 ms
64 bytes from 10.10.10.2: icmp_req=3 ttl=63 time=0.784 ms
64 bytes from 10.10.10.2: icmp_req=4 ttl=63 time=0.774 ms
64 bytes from 10.10.10.2: icmp_req=5 ttl=63 time=0.709 ms

--- 10.10.10.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.709/0.764/0.836/0.046 ms
anurag@rtr01:~$
anurag@rtr01:~$
anurag@rtr01:~$
anurag@rtr01:~$ traceroute 10.10.10.2
traceroute to 10.10.10.2 (10.10.10.2), 30 hops max, 60 byte packets
 1  10.10.10.5 (10.10.10.5)  2.226 ms  1.907 ms  1.830 ms
 2  10.10.10.2 (10.10.10.2)  1.766 ms  1.700 ms  1.649 ms
anurag@rtr01:~$

 

2.Source-NAT on RTR01 for LAN side connectivity

So we have eth1 on the transit router facing on LAN side. Just like all other LANs, it would need a combination of DHCP + NAT of private against WAN IP for outgoing packets.

 

Configuration DHCP

anurag@rtr01# show service dhcp-server
 disabled false
 shared-network-name LAN {
     subnet 192.168.1.0/24 {
         default-router 192.168.1.1
         dns-server 8.8.8.8
         start 192.168.1.2 {
             stop 192.168.1.200
         }
     }
 }
[edit]
anurag@rtr01#

 

Note: Here subnet and default router IP belongs to IP used on eth1 interface. Now we have 192.168.1.0/24 as LAN pool, and we need to NAT it against WAN IP which is on eth0 – 10.10.10.6.

NAT configuration

anurag@rtr01# show nat
 source {
     rule 1 {
         outbound-interface eth0
         source {
             address 192.168.1.0/24
         }
         translation {
             address masquerade
         }
     }
 }
[edit]
anurag@rtr01#

This ensures that all packets with source IP from pool 192.168.1.0/24 going to outside world via eth0 – WAN would be “re-written” to  source IP address of WAN.

Once this is done, Ubuntu-desktop shows IP 192.168.1.2 which it learnt from RTR01.

Ubuntu Desktop - learnt IP via DHCP

 

 

Testing it’s connectivity to end destination server01 which is on WAN IP 10.10.10.2

Connectivity test from desktop

 

Quick check on NAT table on RTR01

anurag@rtr01:~$ show nat source translations
Pre-NAT              Post-NAT             Prot  Timeout
192.168.1.2          10.10.10.6           udp   2
192.168.1.2          10.10.10.6           udp   18
192.168.1.2          10.10.10.6           udp   12
192.168.1.2          10.10.10.6           udp   8
192.168.1.2          10.10.10.6           udp   25
192.168.1.2          10.10.10.6           udp   7
192.168.1.2          10.10.10.6           udp   20
192.168.1.2          10.10.10.6           icmp  29
anurag@rtr01:~$

 

3. Traffic shaping on RTR01 on per user basis

All works well. Now, I am running speedtest-mini script on the server01. So browsing http://10.10.10.2/speedtest on end desktop to test speeds.

(Note: As I said this is virtualized environment and hence extremely likely I am going to hit resource limit much before actual theoretical speeds of port. Aim of this test is just sample and to assist in bandwidth shaping.)

 

Speedtest on Desktop

Screen Shot 2016-01-13 at 2.10.32 AM

 

Screen Shot 2016-01-13 at 2.12.04 AM

 

 

This shows quite decent speeds. Now coming to traffic shaping, let’s shape everyone on LAN to 10Mbps symmetric. Here we can make use of “traffic shaper“. One key thing with traffic shaper is that it works only in OUT direction and hence it can shape packets going in out direction from port. Thus to have symmetric effect, we can apply it on both eth0 – WAN (for capping uploads) and eth1 – LAN (for capping downloads).

anurag@rtr01# show traffic-policy
 shaper User-Download-Cap {
     bandwidth 10Mbit
     default {
         bandwidth 50%
         ceiling 100%
         queue-type fair-queue
     }
 }
 shaper User-Upload-Cap {
     bandwidth 10Mbit
     default {
         bandwidth 50%
         ceiling 100%
         queue-type fair-queue
     }
 }
[edit]
anurag@rtr01#

 

Next, we need to call appropriate shaper on interfaces. Calling “User-Upload-Cap” on eth0-WAN in outbound direction and “User-Download-Cap” in  outbound in eth1-LAN direction.

 

Speedtest after cap

Speedtest after cap

 

And capping works! One can more fine tune it as per requirement like capping just specific traffic for specific set of users etc.

 

4. IPv6 autoconfig

So next goes is to have full IPv6 auto configuration. I would also dual stack interfaces of server01 to make IPv6 work end to end between server01 to desktop.

Following RFC 3849, I will use 2001:DB8::/32 for this sample configuration / documentation purpose.

2001:DB8::/32 – Main allocation

2001:DB8:1::/48 – Transit Router Pool
2001:DB8:1:1::/64 – Connectivity with server01
2001:DB8:1:2::/64 – Connectivity between Transit Router and RTR01
2001:DB8:2::/48 – IPv6 pool for RTR01 routed to it
2001:DB8:2:a::/64 – LAN pool for allocation to end customers

 

Dual stacking eth0 interface of Transit-Router which is facing server01 & eth1 facing RTR01

anurag@Transit-Router# show interfaces ethernet eth0
 address 10.10.10.1/30
 address 2001:db8:1:1::1/64
 description "***Connected to server01***"
 duplex auto
 smp_affinity auto
 speed auto
[edit]
anurag@Transit-Router#

anurag@Transit-Router# show interfaces ethernet eth1
 address 10.10.10.5/30
 address 2001:DB8:1:2::1/64
 description "***Connected to RTR01***"
 duplex auto
 smp_affinity auto
 speed auto
[edit]
anurag@Transit-Router#

 

Next, routing 2001:DB8:2::/48 behind RTR01 (2001:DB8:1:2::2)

anurag@Transit-Router# show protocols static
 route6 2001:DB8:2::/48 {
     next-hop 2001:DB8:1:2::2 {
     }
 }
[edit]
anurag@Transit-Router#

 

 

Configuration RTR01 interfaces with IPv6

anurag@rtr01# show interfaces ethernet eth0
 address 10.10.10.6/30
 address 2001:DB8:1:2::2/64
 description "***Link to Transit router***"
 duplex auto
 ipv6 {
     address {
         autoconf
     }
     dup-addr-detect-transmits 1
 }
 smp_affinity auto
 speed auto
 traffic-policy {
     out User-Upload-Cap
 }
[edit]
anurag@rtr01# show interfaces ethernet eth1
 address 192.168.1.1/24
 address 2001:DB8:2:a::1/64
 description "***LAN side interface***"
 duplex auto
 ipv6 {
     router-advert {
         prefix 2001:DB8:2:a::/64 {
         }
     }
 }
 smp_affinity auto
 speed auto
 traffic-policy {
     out User-Download-Cap
 }
[edit]
anurag@rtr01#

anurag@rtr01# show protocols static
 route 0.0.0.0/0 {
     next-hop 10.10.10.5 {
     }
 }
 route6 ::/0 {
     next-hop 2001:DB8:1:2::1 {
     }
 }
[edit]
anurag@rtr01#

 

Setting up router advertisements

anurag@rtr01# set ipv6 router-advert
[edit interfaces ethernet eth1]
anurag@rtr01# commit
[ interfaces ethernet eth1 ipv6 router-advert ]
Re-generating radvd config file for interface eth1...
Starting radvd...
Starting radvd: radvd.

[edit interfaces ethernet eth1]
anurag@rtr01#

Checking now on end user desktop

IPv6 connectivity test

(This shows IPv6 getting automatically configured on the end user’s desktop)

 

IPv6 connectivity test

 

Speedtest on IPv6

 

Speedtest over IPv6 is also capped since cap was based on interfaces and traffic flow and hence works on both IPv4 and IPv6 world.

 

5.Basic firewalling to protect server01

In current configuration, server01 has all open ports. Let’s try to allow only and only tcp port 80 traffic and drop everything else. Out ports from server01 to outside should work.

 

Step 1 – Create firewall rule to drop all traffic by default and just allow tcp port 80 and established + related connections so that return traffic (initiated from server) could work.

anurag@Transit-Router# show firewall
 name server01-Inbound {
     default-action drop
     rule 1 {
         action accept
         destination {
             port http
         }
         protocol tcp
     }
     rule 2 {
         action accept
         state {
             established enable
             related enable
         }
     }
 }
[edit]
anurag@Transit-Router#

 

Step 2 – Next, apply this policy on the “out” direction on the interface connecting the server01 so packet going towards the server can be filtered.

anurag@Transit-Router# show interfaces ethernet eth0 firewall
 in {
 }
 out {
     name server01-Inbound
 }
[edit]
anurag@Transit-Router#

 

And finally testing and looking at firewall statistics

anurag@Transit-Router:~$ show firewall statistics

-----------------------------
Rulesets Information
-----------------------------
--------------------------------------------------------------------------------
IPv4 Firewall "server01-Inbound":

 Active on (eth0,OUT)

rule  packets   bytes     action  source              destination
----  -------   -----     ------  ------              -----------
1     0         0         ACCEPT  0.0.0.0/0           0.0.0.0/0
2     86        7.22K     ACCEPT  0.0.0.0/0           0.0.0.0/0
10000 6         504       DROP    0.0.0.0/0           0.0.0.0/0

anurag@Transit-Router:~$

 

 

All works pretty well. We can surely use such box in a small network.

 

Next logical step – using it for more cool features like full redundancy using VRRP, OpenVPN tunnels, BGP with route-maps etc.

 

 

Note: I would presenting a paper on “Disconnected Network Islands” at SANOG 27 on 25th. Meet and greet if you are around! 🙂

26 Aug

Multiple IP’s on Linux servers

One of things which people often asked me around in past was on how to have multiple IPs on Linux machine under various circumstances. I know there are ton of blog posts about this but very few explain how it works and possible options under different use cases etc.

 

I will share router side and server side config with focus on how it should be done from server end. Assuming server side config to be for Ubuntu/Debian. You can find similar concept for CentOS.

 

Say you have a router on IP 10.10.10.1 and server on IP 10.10.10.2 on a /24 (255.255.255.0) subnet. Assming that entire 10.10.10.0/24 is available for server’s connectivity. Setup would be like:

R1 - Server 01 connectivity

Configuration so far is super simple. You have got 10.10.10.1 placed on R1’s interface (g1/0) which connects to server01 and server01 has 10.10.10.2.

R1#sh run int g1/0
Building configuration...

Current configuration : 127 bytes
!
interface GigabitEthernet1/0
 description ***Link to server01***
 ip address 10.10.10.1 255.255.255.0
 negotiation auto
end

R1#

 

and on server’s config is:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp
#iface eth0 inet6 auto

iface eth0 inet static
address 10.10.10.2
netmask 255.255.255.0
gateway 10.10.10.1

 

Now let’s say you want to add additional IP’s to the server. There can few ways:

  1. You may add more IP’s from this same pool i.e un-used IP’s from within 10.10.10.0/24.
  2. You may add more IP’s from all together different pools say from 192.168.1.0/24.

 

When adding new IP’s/additonal IPs to server, you must understand that they would be either via layer 2 (i.e those IP’s will generate ARP packets on the interface connected to the router) or would be layer 3 i.e routed IP’s which are routed “behind” an existing working IP (like 10.10.10.2) in this case. Another case you can have is additonal IP’s which are eventually NATTed behind public IPs which I will also discuss in the end.

 

Layer 2 based addition

When IP’s are from layer 2 – they are are supposed to be present on the interface so that they reflect in ARP and hence machines on the LAN do IP to MAC conversion and route packets destination for those IPs. Currently connected interface here is eth0 and hence new IP’s should be eth0 only. Thus you can add those IP’s by creating so called “alias interface”. eth0 can have eth0:1, eth0:2 etc as alias. IP’s can also be added on same single eth0 interface.

Since entire pool is available for use between R1 and server01, this doesn’t needs any change at R1 end. On server end, we can add IP as:

 

Temporary addition (will get removed after reboot):

anurag@user-1:~$ sudo ip -4 addr add 10.10.10.3/24 dev eth0
[sudo] password for anurag: 
anurag@user-1:~$ 
anurag@user-1:~$ 
anurag@user-1:~$ sudo ip -4 addr add 10.10.10.4/24 dev eth0
anurag@user-1:~$ 

 

So there we go – two IP’s added on eth0 itself.

anurag@user-1:~$ sudo ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.10.10.2/24 brd 10.10.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.10.10.3/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 10.10.10.4/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
anurag@user-1:~$

 

 

Let’s try to ping them from router:

R1#ping 10.10.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/43/48 ms
R1#ping 10.10.10.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/42/48 ms
R1#

 

And so it works. Now, if we examine ARP table for g1/0 interface of router (which connects to server01) we will find all these three IP’s which are in use by server.

R1#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.2             14   0800.2787.d567  ARPA   GigabitEthernet1/0
Internet  10.10.10.3              1   0800.2787.d567  ARPA   GigabitEthernet1/0
Internet  10.10.10.1              -   ca01.349f.001c  ARPA   GigabitEthernet1/0
R1#

 

Another way of doing same thing is by creating alias interface and adding IP’s on it. So we can add following in the /etc/network/interfaces:

auto eth0:1
iface eth0:1 inet static
address 10.10.10.3
netmask 255.255.255.0

auto eth0:2
iface eth0:2 inet static
address 10.10.10.4
netmask 255.255.255.0

 

Being those interfaces up using: ifup eth0:1 and ifup eth0:2. A logical question  – where to put gateway often comes up and confuses. Keep in mind as of now all IP’s are coming from same single device R1 and IP at R1 end is 10.10.10.1 and hence single gateway in eth0 config is good enough to ensure that traffic to any IP outside 10.10.10.0/24 pool can be routed via 10.10.10.1. Let’s say you want to add IP from a completely different pool (for some reason) on server like 192.168.1.0/24. Here you can do it via layer 2 by first defining an IP as secondary on R1 and add IP as alias on the server.

R1#sh run int g1/0
Building configuration...

Current configuration : 175 bytes
!
interface GigabitEthernet1/0
 description ***Link to server01***
 ip address 192.168.1.1 255.255.255.0 secondary
 ip address 10.10.10.1 255.255.255.0
 negotiation auto
end

R1#

 

On Server01 end:

auto eth0:1
iface eth0:1 inet static
address 192.168.1.2
netmask 255.255.255.0

 

This simply ensures that both R1 and Server01 get in single broadcast domain which has broadcast address 192.168.1.255 and hence can speak to each other. Again, in this case as well on router end – router gets ARP for IP and that tells how to reach. ARP table (IP to MAC address conversion) and forwarding of packets based on Mac (Mac table: Mac >> Interface conversion).

R1#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.2              0   0800.2787.d567  ARPA   GigabitEthernet1/0
Internet  10.10.10.1              -   ca01.349f.001c  ARPA   GigabitEthernet1/0
Internet  192.168.1.1             -   ca01.349f.001c  ARPA   GigabitEthernet1/0
Internet  192.168.1.2             0   0800.2787.d567  ARPA   GigabitEthernet1/0
R1#

 

Another way of layer 2 setup can be by either patching an un-used extra port and have separate network on it (separate IP / subnet mask). You can also have a setup where you send tagged VLAN till server and untag it on the server. I will put blog post about it later on.

 

Layer 3 based addition

Due to scalability as well as scarcity of IPv4 address issue, layer 2 based method isn’t the best one when it comes to adding of additional IP’s. Layer 3 setup is simply where additional IP’s are “routed” behind a working single public IP.

So e.g thought it’s better to use /30 for P2P (infact /31!) but let’s keep same case going. We have 10.10.10.1 on R1 and 10.10.10.2 on Server01 and both are in /24. Now to allocate say 10.10.10.3 to server, we can route this IP behind 10.10.10.2.

 

So setup on R1:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip routing 
R1(config)#ip route 10.10.10.3 255.255.255.255 10.10.10.2
R1(config)#end
R1#wr
Building configuration...

*Aug 21 19:21:53.495: %SYS-5-CONFIG_I: Configured from console by console[OK]
R1#

 

This will ensure that all packets going towards 10.10.10.3/32 (single IP) are routed to 10.10.10.2 which is on server01. Next, we can add this IP on existing loopback interface lo or a new alias of loopback as lo:1.

ip -4 addr add 10.10.10.3/32 dev lo for temporary addition (removed after reboot) and

auto lo:1
iface lo:1 inet static
address 10.10.10.3
netmask 255.255.255.255

R1#ping 10.10.10.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/43/48 ms
R1#

 

So how exactly this works? It’s important to understand it as it explains key difference between IP’s added on interface Vs IP’s routed. Let’s see “sh ip route” output for 10.10.10.2 and 10.10.10.3:

R1#sh ip route 10.10.10.2
Routing entry for 10.10.10.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet1/0
      Route metric is 0, traffic share count is 1




R1#sh ip route 10.10.10.3
Routing entry for 10.10.10.3/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.10.10.2
      Route metric is 0, traffic share count is 1

R1#

 

Here clearly there’s a “directly connected route” 10.10.10.2 while for 10.10.10.3 there’s a static route towards 10.10.10.2.

 

Some of key comparison point layer 2 Vs layer 3 based setup:

  1. With layer 3 method you can have as many IP’s as want on server without getting into CIDR cuts. So e.g if you want to add entirely new pool to server, you would need at least 2 IP’s (a /31). If you want just 3 IP’s then you would need a /29 (consuming 8 IPs) and so on. This approach has issue as it wastes lot of IPs and that becomes critical when we are almost out IPv4. In IPv6 that’s no issue at all.
  2. With layer 3 you can have a setup where addition of IP’s doesn’t really creates any layer 2 noise (ARP packets). So e.g you can use just 10.10.10.0/31 and then route entire 192.168.1.0/24 behind server. This will ensure that server can use 192.168.1.0/24 without generating any ARP for it and router will just have one single routing table entry for that enture /24. ARP would be just for single IP which is used to connect R1 with the server.

 

 

I hope this will help you !

23 Sep

Back at College | Final year | Life in US |Thoughts on Linux!

 

Finally blog post after long time! 

Last few months were busy with US trip, and roaming around.  Things are pretty much funny as usual at college. US went OK as usual – finding better infrastructure, more politeness in general but weird relationship and culture in few cases. Quite a different food in Michigan and those $8-$10 bills for each dinner! It is always interesting to see how much different US is in reality then what we always hear from people around us and movies etc. 

 

Things which look strange to me whenever I visit US:

  1. How well system works with discipline
  2. No predicable eating pattern – a Apple can be breakfast one Monday, while entire Pizza on Tue!
  3. People drink more soft drinks in general then water. It is easy to find drinks over water.
  4. Internet is way too faster then India. (Will fix ours in a while!) 🙂
  5. Quite a few people live life on paycheck with absolutely zero savings.
  6. Too much of “step” brother/sister/father/mother concept, which isn’t fun when looking from Indian eyes.
  7. McDonald food is cheap (which is relatively expensive in India!) + no vegetarian food!
  8. Size of Walmart & Best Buy itself is a surprise & mystery!
  9. Efficient & quick legal systems help regulators to great extent 
  10. How inefficient & ridiculous Indian paper oriented bureaucracy has become!
  11. How boring a place looks with less population to Indian eyes which are used to crowd all around! 🙂

 

 

Linux…

 

Finally I am back in village into my “student life“. We have some interesting courses including Linux and Broadband Communications.  Syllabus for Linux looks good but classes are going awful. Well no offence to our teachers but seriously entire design of Linux courses in B.tech degree is crap. 

The course in B.tech 7th semester under Kurukshetra University covers basics of Linux from commands to basic idea of Linux Kernel, GRUB boot loader, Linux Networking (yay!), LDAP and other integration methods with Windows and finally Linux security concepts via PGP keys, firewall, NAT etc. To be true – course pretty much covers a lot if done in right manner but seriously based on few classes I have attended so far I can clearly see there won’t be much to learn for students in general from this “yet another subject” at college.

 

Here’s the image of Linux which most of students have:

  1. It’s all CLI and that too from UNIX days 🙂
  2. Fedora and CentOS are awesome, while simple ones like Ubuntu aren’t “powerful enough” to even try!
  3. Linux is all about cramming commands with all their arguments (well no concept of man tool here!) 
  4. Linux is all for geeky servers and can’t be used on desktop
  5. Linux is without any pre-compiled debian .deb or red hat .rpm packages and one must hit head on tasteless .tar.gz for installation
  6. File system is super hard to understand!
  7. No clue on Debian based Vs Red Hat based! (strange bird names huh?)

 

Now almost all these points are wrong based on what I have seen so far. I have been using Linux from over 6 years and being working a Linux systems admin from over 4 years. Linux has way too cool GUI  with gnome and KDE. Though I personally never liked KDE much due to instability but still it is way too better then assuming Linux is all about commands and one can’t even move a file without remembering mv command! 🙂

With regard to commands, this is a core fault in University’s course design. I expect students to be getting Linux GUI only version in one semester where one can get familiar with “life outside windows”, meaning of Linux file system etc rather then just cramming commands whole day long. Also, I was myself surprised on number of arguments taught for each command – seriously way too high and mostly useless. One can always find most of less used ones via manual tool (man $command) and thus there’s no point in cramming all of them in start or even ever!

With regards to distro – for some strange reason everyone prefers Fedora or CentOS missing the fact that they run laptops on their laps and servers tops! 🙂 
Most of these hard core Linux distros are more for non-GUI based servers and surely graphics look so un-developed and scary one. One has to understand that a powerful distro on server is not really the most powerful one on Laptop too. I would love to go for CentOS on my servers but would stick with Ubuntu, Mandriva, or Mint for desktop experience.  

Also, to start with one should stick with distro which has better repository as we don’t expect new Linux users to be messing up with compiling software packages. With regards to file system – college/syllabus does puts enough effort but still this all look meaningless to people unless they could simply roam around into file system with decent GUI rather then looking at / on testing ls command. 🙂

  

With hope that we will have more Linux admins out of young B.tech students, time to end this post!

 

 

Some important life changes…

Sidenote: I am not with Cloudaccess.net anymore. It was very nice experience of setting up AS54456 from scratch along with design of anycasting DNS instances.  Wishing Cloudaccess.net good luck for time ahead.

I just started working with Packet Clearing House (PCH). Looking forward towards exciting time ahead! Interesting pages to checkout – Anycasting DNS for TLDs  & Peering information

Thanks for reading.