Archive for the Category ◊ Computer Science Dept. ◊

LXR
Thursday, January 26th, 2012 | Author:

This week I want to pay tribute to an open source project called the LXR Cross Referencer. LXR is  a web tool that lets you browser the source code of a software project, navigating link by link based on included source files, functions or variables.

LXR can be downloaded from the project’s website [1] and applied to any software project.

The most popular instance of LXR is found on the project’s initial page [2] as an instance for the Linux Kernel. This site has a complete history of the Linux code since version 0.0.1 to latest stable version. Opening two windows of two different versions of a file, you can compare the code and see what’s been added or changed between the versions.

It’s very useful for finding where a function or a constant has been used, or to see in what header a function has been declared, defined and then used.

Note that all of the above can de done via command line tools like ctags or cscope alongside vim or emacs, with grep -r, diff and git. But the friendly part of lxr.linux.no is that everything is already on the site so you don’t need to download anything locally and you can use everything there as long as you have an Internet connection.

[1] http://lxr.sf.net/

[2] http://lxr.linux.no/

[CCIELab] IOS + Linux = Quagga
Thursday, January 05th, 2012 | Author:

[Originally posted on ccielab.ro]

Cisco IOS’s shell is a popular interface for devices in the networking world. But also in the network world, there are a lot of Linux/Open Source fans. The Quagga open source project tries to bring together IOS and Linux, by providing an IOS-like interface for configuring Linux’s interfaces, routing table and firewall, along side its own implementations of RIP, OSPF and BGP daemons.

The Quagga Software Routing Suite comes as a set of daemos. The main one is the zerbra daemon (Zebra is the old name of the project). This core daemon does the interaction with the Linux kernel and, also, with other daemons like ripd (RIP daemon), ospfd (OSPF daemon), bgpd (BGP daoemon). Quagga is modular, so you can implement new protocols if needed via a standard API.

To configure Quagga, you first need to start the daemons (at least the core one), in the /etc/quagga/daemons file. Each daemon has its own configuration file (ex. /etc/quagga/zebra.conf, /etc/quagga/ripd.conf etc.). Accessing the IOS-like shell is done via the vtysh command. Once in this shell, most commands available in Cisco’s IOS are available.

Router / # cd
Router ~ # vtysh

Hello, this is Quagga (version 0.99.18).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

Router# conf t
Router(config)# hostname  LinuxRouter
LinuxRouter(config)# exit
LinuxRouter# show ?
bgp             BGP information
clns            clns network information
daemons         Show list of running daemons
debugging       State of each debugging option

[...]

Keep in mind that some things are not 100% identical to a Cisco router (ex. the interface names). Here’s an example of how to configure an interface.

LinuxRouter# conf t
LinuxRouter(config)# interface  eth0
LinuxRouter(config-if)# ip address  141.85.42.1 ?
A.B.C.D/M  IP address (e.g. 10.0.0.1/8)
LinuxRouter(config-if)# ip address  141.85.42.1/24
LinuxRouter(config-if)# link-detect

Monitor output (show commands) are similar aside some Linux specific details (ex. Kernel routes are available in Linux, but not in IOS).

Router# sh ip route
Codes: K – kernel route, C – connected, S – static, R – RIP, O – OSPF,
I – ISIS, B – BGP, > – selected route, * – FIB route

K * 0.0.0.0/0 via 192.0.2.1, venet0 inactive
O 10.10.12.0/24 [110/10] is directly connected, eth0, 00:03:41
C>* 10.10.12.0/24 is directly connected, eth0
O 10.10.14.0/24 [110/10] is directly connected, eth1, 00:03:36
C>* 10.10.14.0/24 is directly connected, eth1
O>* 10.10.23.0/24 [110/20] via 10.10.12.2, eth0, 00:02:46
O>* 10.10.24.0/24 [110/20] via 10.10.12.2, eth0, 00:02:14
*via 10.10.14.4, eth1, 00:02:14
O>* 10.10.25.0/24 [110/20] via 10.10.12.2, eth0, 00:02:41
O>* 10.10.35.0/24 [110/30] via 10.10.12.2, eth0, 00:01:21
* via 10.10.14.4, eth1, 00:01:21
O>* 10.10.45.0/24 [110/20] via 10.10.14.4, eth1, 00:02:08
C>* 127.0.0.0/8 is directly connected, lo
C>* 127.0.0.1/32 is directly connected, venet0
C>* 172.10.10.0/32 is directly connected, venet0
K>* 192.0.2.1/32 is directly connected, venet0

Configuring a routing protocol instance is also similar:

LinuxRouter# conf t
LinuxRouter(config)# router ospf
LinuxRouter(config-router)# network  192.168.123.0/0 area 0

As you can see, coming from an IOS background, this tool is very easy to use on your Linux box. It is far from perfect since it doesn’t have the years in production like IOS or iproute2, but it is cool to test out.

[TechBlog] Stack Allocation
Sunday, December 18th, 2011 | Author:

[Originally posted on techblog.rosedu.org]

Stack space is the part of each process’ virtual memory where function arguments and return addresses are stored, along with local variables declared within a function. Usually, the stack begins at the high address space of the virtual memory and grows down.

At every function call, a new stack frame is created on the stack. It contains the parameters sent to the function, the return address (the address of a code in the caller function) and the locally declared variables.

For each function call, the SP/ESP (Stack Pointer/Extended Stack Pointer) is set so the stack has a big enough size to accommodate local variables. For example, in theory, if you have a local char variable and an int variable, the SP should be set (moved) to 5 bytes.

In practice, the compiler will allocate stack space a little different than expected. It will allocate local variables space in increments of a fixed size, so sometimes having two int variables or three int variables will be the same.

As an example, gcc will allocate in increments of 16 bytes. Let’s make an experiment… we take a simple C program and turn into assembly code.

The C file looks something like this:

int main(void)
{
	int a=1, b=2;
	return 0;
}

The variables must be used after declaration or they will be ignored by the compiler.

The resulting assembly code (with an gcc -S) looks like this:

main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	movl	$1, -4(%ebp)
	movl	$2, -8(%ebp)
	movl	$0, %eax
	leave
	ret

Notice the subl instruction that clears 16 bytes in the stack space by decrementing the ESP. Those 16 bytes are enough for four 32bit integers. If you have 1,2,3 or 4 local variables declared (and used), you get those 16 bytes.

If we declare 5 integers, the allocated space will now be 32bytes. Same thing for 6, 7, or 8. If we have 9 to 12 integers the compiler will allocate 48 bytes. An so on…

What if we don’t only have integers? Let’s add some chars.

int main(void)
{
	int a=1, b=2;
	char c=3, d=4;
}

Result:

main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	movl	$1, -8(%ebp)
	movl	$2, -12(%ebp)
	movb	$3, -1(%ebp)
	movb	$4, -2(%ebp)
	movl	$0, %eax
	leave
	ret

The function would need 10 bytes, but still gets 16. So the allocation is in increments of 16 bytes no matter what.

The question remains why? It has to do with the cache alignment. The compiler will try to structure the memory usage so that the executed code can be easily fetched from memory and cached. A correct alignment will cause minimum cache misses for memory access.

Credits to SofiaN for help with initial observations and tests.

ROSEdu Tech Blog
Saturday, November 26th, 2011 | Author:

This fall, ROSEdu[1] introduced a new project: TechBlog [2]. Since we managed to gather a lot of technical-oriented in our  community, each having things to say about different technologies, we built a place where to share such knowledge in the form of a blog.

Here is my first contribution.

Rescuing executable code from a process [3]. Comments on reddit [4].

A process is an instance of a binary executable file. This means that when you ‘run’ a binary, the code from the storage media is copied into the system’s memory, more precisely, into the process’ virtual memory space. From a single binary, several processes can be spawned.

The virtual memory of a process, made up of pages, is mapped to several things, like shared objects(libraries), shared memory, stack and heap space, read-only space and executable space. A good way to view what is mapped to what is with the pmap utility, or by just looking in the /proc directory hierarchy. The /proc/$PID/maps file (where $PID is the process ID of the targeted process) has the page mappings. Also in /proc/$PID, you can find other useful files, like the exe file that contains a symlink to the executable or the fd directory that contains symlinks to all the files opened as file descriptors in a process.

Except useful information, what can we get out of the procfs? Here is a situation that has been known to happen. You are in a console, with your bash shell, and you manage to delete some important files, like /bin/bash. Without that executable, you cannot run new shells and on a restart, your system will be inaccessible. What can you do?

The code of your bash is no longer on the hard drive, but it is in the virtual memory of the process you are currently running. You can find out what’s the PID of the current shell instance using $$ enviroment variable . Knowing that, you can cd to the /proc/$$ and access the content of the exe file there.

Although the exe file is shown as a link to the original file that is now deleted (thus the link should be broken), if you cat it, you will get its binary content. In fact, all the original binary file. Here is the step by step process:

/bin # md5sum bash
e116963c760727bf9067e1cb96bbf7d3  bash
/bin # rm bash
/bin # echo $$
5051
/bin # cd /proc/$$
/proc/5051 # ls -la exe
lrwxrwxrwx 1 root root 0 2011-11-15 23:47 exe -> /bin/bash (deleted)
/proc/5051 # cat maps
[snip]
00f9e000-00f9f000 rw-p 0001c000 08:01 263123     /lib/i386-linux-gnu/ld-2.13.so
08048000-0810c000 r-xp 00000000 08:01 284760     /bin/bash (deleted)
0810c000-0810d000 r--p 000c3000 08:01 284760     /bin/bash (deleted)
0810d000-08112000 rw-p 000c4000 08:01 284760     /bin/bash (deleted)
[snip]

/proc/5051 # cat exe>/bin/bash_rescued
/proc/5051 # cd -
/bin # md5sum bash_rescued
e116963c760727bf9067e1cb96bbf7d3  bash_rescued
/bin # chmod +x bash_rescured
/bin # mv bash_rescured bash

What other things can we rescue? How about a file that was opened by a process? For example, a video file, opened by a player:

alexj@hathor ~ $ md5sum movie.ogv
9f701e645fd55e1ae8d35b7671002881  movie.ogv
alexj@hathor ~ $ vlc movie.ogv &
[1] 6487
alexj@hathor ~ $ cd /proc/6487/fd
alexj@hathor /proc/6487/fd $ ls -la |grep movie
lr-x------ 1 alexj alexj 64 2011-11-16 00:11 23 -> /home/alexj/movie.ogv
alexj@hathor /proc/6487/fd $ rm /home/alexj/movie.ogv
alexj@hathor /proc/6487/fd $ ls -la |grep movie
lr-x------ 1 alexj alexj 64 2011-11-16 00:11 23 -> /home/alexj/movie.ogv (deleted)
alexj@hathor /proc/6487/fd $ cp 23 /home/alexj/movie_rescued.ogv
alexj@hathor /proc/6487/fd $ md5sum /home/alexj/movie_rescued.ogv
9f701e645fd55e1ae8d35b7671002881  /home/alexj/movie_rescued.ogv

These things are possible because the instances of the files are still kept and used by the kernel. The VFS (the Virtual File System) still has references to the inodes of the files. They won’t be released until the processes will be finished.

[1] http://www.rosedu.org

[2] http://techblog.rosedu.org

[3] http://techblog.rosedu.org/rescuing-executable-code-from-a-process.html

Python is like music…
Wednesday, July 20th, 2011 | Author:

Sunt foarte amator în ceea ce privește muzica (nu mă refer la ascultat muzică :P ). Și dacă nu era de ajuns că încercam să cânt fără talent la chitară, mai nou încerc să învăț să cânt la pian. Dar dacă la chitară oricine poate să cânte ceva, la pian, aparent ai nevoie de ceva cunoștințe de teorie muzicală.

Și m-am apucat de acorduri la pian, bazându-mă pe ce știam la chitară. Dar cum ureche muzicală nu am, calculam pe hârtie care sunt notele echivalente între cele două instrumente.

Dar parcă nu era eficient… hai să aducem puțin geekyness în ecuație. Și la Python sunt amator, dar totuși sunt mai talentat în programare :P . Așa că hai să scriem niște generatoare de note și acorduri. Câteva zeci de minute mai târziu, “biblioteca” python de muzică de mai jos.

Așa că cine știe teorie muzicală și vrea să invețe python, sau cine știe python și vrea să vadă ce e acela un acord, să se uite pe pychords.

#!/usr/bin/python

def next_note(note):
# note can be A,B,C,D,E,F,G
	if note == 'G':
		return 'A'
	else:
		return chr(ord(note)+1)

def next_semitone(semitone):
# semitone can be A,A#,B,C,C# etc.
	if len(semitone)>1 :
		if semitone[1] == '#':
			return next_note(semitone[0])
	if semitone[0] == 'B':
		return 'C'
	if semitone[0] == 'E':
		return 'F'
	return semitone[0] + '#'

def next_nth_semitone(semitone, n):
	for i in range(n):
		semitone = next_semitone(semitone)
	return semitone

def next_pitch(pitch):
# pitch can be A0,A#0,C4 etc.
	if pitch[1] == '#':
		semitone = pitch[:2]
		octave = int(pitch[2:])
	else:
		semitone = pitch[0]
		octave = int(pitch[1:])
	semitone = next_semitone(semitone)
	if semitone == "C":
		octave = octave+1
	return semitone + str(octave)

def next_stream(init, function, size):
	stream = []
	for i in range(size):
		stream.append(init)
		init=function(init)
	return stream

def major_chord(note):
	print note+" chord:"
	print note,next_nth_semitone(note, 4),next_nth_semitone(note, 7)

def minor_chord(note):
	print note+"m chord:"
	print note,next_nth_semitone(note, 3),next_nth_semitone(note, 7)

# Guitar with standard tuning (fret 0 is open fret)
print next_stream("E4", next_pitch, 13)
print next_stream("B3", next_pitch, 13)
print next_stream("G3", next_pitch, 13)
print next_stream("D3", next_pitch, 13)
print next_stream("A2", next_pitch, 13)
print next_stream("E2", next_pitch, 13)

major_chord("A")
minor_chord("B")

Dacă am făcut ceva greșeli, commentariile sunt binevenite, cât timp sunt malițioase :P .

Și iată și rezultatul inițial dorit, și anume cum arată notele pe o chitară standard.

['E4', 'F4', 'F#4', 'G4', 'G#4', 'A4', 'A#4', 'B4', 'C5', 'C#5', 'D5', 'D#5', 'E5']
['B3', 'C4', 'C#4', 'D4', 'D#4', 'E4', 'F4', 'F#4', 'G4', 'G#4', 'A4', 'A#4', 'B4']
['G3', 'G#3', 'A3', 'A#3', 'B3', 'C4', 'C#4', 'D4', 'D#4', 'E4', 'F4', 'F#4', 'G4']
['D3', 'D#3', 'E3', 'F3', 'F#3', 'G3', 'G#3', 'A3', 'A#3', 'B3', 'C4', 'C#4', 'D4']
['A2', 'A#2', 'B2', 'C3', 'C#3', 'D3', 'D#3', 'E3', 'F3', 'F#3', 'G3', 'G#3', 'A3']
['E2', 'F2', 'F#2', 'G2', 'G#2', 'A2', 'A#2', 'B2', 'C3', 'C#3', 'D3', 'D#3', 'E3']

Poate să calculeze și acordurile majore și minore:

A chord:
A C# E
Bm chord:
B D F#
RIP lab: Send RIP routes to remote neighbours
Tuesday, July 19th, 2011 | Author:

[Originally posted on ccielab.ro]

Scenario:
You have two routers running RIP, but the two routers aren’t directly connected because there is a third router between them. See topology below. How do you get routes across because RIP only communicates with routers that are directly connected?
riplab

The simple answer is to create a GRE tunnel between R1 and R3 so a tun interface simulates a direct connection of the two routers. But let’s take a more didactic approach to remember some things about RIP.

RIP v2 sends the updates to the address 224.0.0.9 that is a local multicast address (TTL=1). But there is another, very important in some situations (like some Frame Relay networks), way to send routes, and that is via unicast to a statically configured neighbor. Configuration is done via the neighbor command in the router rip configuration. The routes will be encapsulated in normal IP unicast packets and since RIP runs on top of UDP, they should be routed as any other packet.

R1:

interface Serial0/0/1
ip address 10.1.2.1 255.255.255.0
interface Loopback 0
ip address 192.168.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 192.168.0.0

neighbor 10.2.3.3
no auto-summary

R3:

interface Serial0/0/1
ip address 10.2.3.3 255.255.255.0
interface Loopback 0
ip address 172.16.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 172.16.0.0
neighbor 10.1.2.1
no auto-summary

You still need to have a network command for the interfaces when you send and receive the updates (in this case 10.0.0.0) otherwise the received updates will be ignored.

First thing you should be careful of is the fact that R1 and R3 need layer3 communication. So you do need static routes for the R1 and R3 routers through R2.

Having connectivity between each other, the router starts sending unicast packets with the routes. debug ip rip would show the following:

RIP: sending v2 update to 10.1.2.1 via Serial0/0/1 (10.2.3.3)
RIP: build update entries
172.16.0.0/24 via 0.0.0.0, metric 1, tag 0

Notice the update is sent to an unicast address and not 224.0.0.9.

Routes are received but they still are not in the routing tables. debug ip rip shows why:

RIP: ignored v2 update from bad source 10.2.3.3 on Serial0/0/1

This reminds us of how RIP works: if a router receives an update it checks to see if the source of the packet is on the same subnet as the IP configured on the interface. If they don’t match, the update is ignored. In our case, the source of the updates are not on the same network because R2 does not modify the packet source/destination in any way.

The solution to this is to disable the default mechanism with the no validate-update-source command in the router rip configuration. This way any updates will be accepted.

Here is a wanted route in the routing table of R3:

R 192.168.0.0/24 [120/1] via 10.1.2.1, 00:00:27

Notice that the next hop is not directly connected so it need to do a recursive lookup and use the static route to send it to R2 first.

S 10.1.2.1/32 [1/0] via 10.2.3.2

Ixia + UPB = 5 years
Thursday, May 12th, 2011 | Author:

Astăzi a avut loc evenimentul anual Ixia [1] din UPB, ocazie cu care s-au și sărbătorit 5 ani de colaborare între firma de soluții de testare a rețelelor și Universitatea Politehnica București.

Ixia este o firmă din California, dar care, de mai mulți ani are o filială în România, ce s-a dezvoltat foarte puternic. Firma a investit foarte mult în acești ani în colaborarea cu UPB, fiind probabil cea mai vizibilă firmă pentru studenții de la Calculatoare.

Prima investiție, de acum 5 ani, a fost Laboratorul de Cercetare pentru Studenți, sala EG106, sală în care se țin și laboratoarele de Sisteme de Operare (SO – anul 3, Calculatoare). Anul acesta, Ixia a făcut din nou o investiție în laborator prin reînnoirea tuturor calculatoarelor, făcând sala EG106 cea mai modernă din facultate. De asemenea, Ixia sponsorizează și un concurs pentru studneții cursului de Sisteme de Operare 2 (SO2 – anul 4, Calculatoare), oferind premiu pentru cea mai bună temă. Concursul, ce se desfășoară anual, a avut premierea azi și a f0st premiată cu cu tablet Samsung Galaxy persoana ce a făcut cea mai bună impementare a unui protocol de transport în kerneul Linux. Tot în cadrul evenimentului au fost prezentate și proiectele de licență din cadrul facultății ce sunt sponsorizate de Ixia România.

Anul acesta, pe lângă concursul tehnic, Ixia a sponsorizat și un concurs de business planing [2], ce avut un premiu de 20 000$, bani ce vor finanța un start-up. Și pentru că cei de la Ixia au dorit să sponsorizeze și proiectele Open Source, a organizat o excursie pentru studneții de anul acesta ai cursului ROSEdu, CDL [3].

[Personal]

Ixia România este compusă din foarte mulți oameni tineri, majoritate dintre ei (cel puțin cei pe partea tehnică), fiind absolvenți de Calculatoare. Au o politică de promovare și angajare prin care investește foarte mult în oameni noi. Mulți studenți de Calculatoare fie au făcut un internship pe vară, fie s-au angajat la firmă după absolvire. Vara trecută am avut ocazia de a face un intership la Ixia în departamentul de IxOS (kernel development). Experiența a fost una foarte plăcută și Ixia România pare a fi una dintre firmele unde multor oameni le-ar plăcea să lucreze. Și pentru că nu am publicat un articol când am terminat stagiul, îmi pare bine că am ocazia acum.

Thank you, Ixia! And keep it up!

[1] http://ixiacom.com

[2] http://ixiacontest.ro/

[3] http://cdl.rosedu.org/2011/

Cisco Expo 2011 Live
Wednesday, March 30th, 2011 | Author:

Sunt pentru a treia ediție consecutiv la Cisco Expo și nu puteam să nu scriu un articol despre el și să stric tradiția.

La fel ca anul trecut, evenimentul se desfășoară într-o singură zi, tot la JT Marriot. Tema de anul acesta este “Collaborative and Virtualization without Borders”.

Programul este împărtit pe trei bucăți:

* sesiuni comune, în sala principală, până la ora 12:00

* sesiuni în paralel în sălile mai mici, până la 15:00

* sesiuni tehnice până la 18:00

Până acum prezentările au sublinitat două buzz-word-uri: “social” și “cloud”. Și, practic, la orice prezentare se ajungea la Facebook, Apple și Google (sau, tehnic, la virtualizare).

Prezentarea interesantă, până acum, a fost o teleconferință cu Dr. Raed Arafat, care a prezentat o situație destul de neașptată: multe spitale și ambulanațe din România sunt dotate cu echipamente care oferă video conferintă. Mai multe spitale din Târgul Mureș comunică între ele prin servicii de tip Telepresence pentru ca medicii să ofere diagnosticuri la distanță. Ambulanțele pot trimite date despre starea medicală a unui pacient ce se află în drum spre spital și poate fi tratat de paramedici sub supravegherea la distanță a unor medici.

[11:50: End of part 1]

Am ieșit la pauza de masă, unde, ca de obicei era algomerație mare. Partea bună a fost mâncarea care a fost mult mai multă și mai bună ca anii precedenți (asta pentru cei care merg la conferințe doar pentru mâncare).

Imediat după masă am fost la prezentarea ținută de Cronus despre “Emerging Threats and Next -Generation Security”, care  a fost foarte interesantă.  Andrei [1] și Bogdan [2], de la Cronus, au prezentat evoluția motivelor  pentru care există “criminali IT”, de la a fi hacker pentru faimă, la a fi hacker pentru bani, până în prezent, când atacurile IT au în spate motive politice sau sociale. Ne-au prezentat nivelul la care atacurile pot face daune în ziua de azi (Hacking as a Service, pentru a fi în temă cu lumea cloud computing), cu exemple pe cazuri ca Stuxnet, dar au și prezentat soluția Cisco care ar trebui să vină să salveze ziua.

Statusul standurilor pe care am ținut să le văd și anul acesta a fost destul de neimpresionant. Partenerii clasici erau prezenți și doar două nume noi au fost. Din păcate, numărul de echipamente sau tehnologii prezentate practic la stand au fost destul de redus și firmele s-au concentrat mai mult pe a prezenta mape.  Singura chestie pe care am testat-o a fost WebEx pentru Android, instalându-mi pe Hero-ul meu.

Din păcate, la ultima parte, cea de sesiuni tehnice, nu am putut sta pentru că trebuia să plec. Așa că experiența mea la aceasta ediție a fost destul de scurtă.

FOSDEM 2011
Tuesday, February 08th, 2011 | Author:

These days I’m in Bruxelles, .be, at FOSDEM 2011 [1], together with friends from ROSEdu.
The Free and Open Source Developers’ European Meeting is a two day conference that brings together Open Source enthusiasts, stuffs them into a building and waits for them to fight with each other in geekiness.
The two day schedule is very crowded, from 9 AM to 6 PM, with event in 10 rooms at the same time. Alongside the presentations, communities and companies have stands in the hallways. Everyone who is anyone is here. Fedora, Mandriva, CentOS, OpenSUSE, Debian and Ubuntu, Gnome and KDE, Mozilla, OpenOffice and LibreOffice, PostgreSQL, BSD, Perl and many others. You can buy T-Shirts, badges and other geeky souvenirs from practically every stand (I bought a couple of gifts I can’t wait to give). O’Reilly has a huge list of open source related books for sale. CACert.org brought assurers for the Web of Trust (I didn’t get to assure any new people, but I did do some 0 points assurances of other assurers). In the Embedded building, communities/companies like BeagleBoard have a showcase for embedded devices that run Android or other embedded distros.
The presentations were form boring to very interesting, but I didn’t get to see more than a few. The first one I went to was a bout LLVM, a new compiler that is suppose to be the next gcc. Went to one about HTML5 and it was the first time I heard talking about the fact that “HTML5 is here” and not “HTML5 is coming” (I can’t wait to hear the same thing about IPv6) and learned some interesting things about HTML5. One more presentation, on a similar topic was about “The browser as a desktop” and how the web will evolve. Another one was about Google’s Go programming language… interesting, but I still didn’t get why Go was better than other languages. As part of the lightning talks of 15 minutes, an interesting one was about CyaTLS, an implementations similar to OpenSSL, only for embedded devices. Another interesting presentation was one from OpenStack about open source Cloud solutions, but could have used more technical details. But the most interesting presentation for me was the very last one, “How kernel development goes wrong”, from a Linux kernel developer with an inside look into the Linux Development Community.
The event was interesting. talked to some people there (for example some guys from Mozilla Europe that told me about a rising community in the Balkans, so that would Include Romaina, and told him that maybe we might collaborate). I learned about some new things, found out more about already known things. So, overall, it was an interesting experience.

[1] http://fosdem.org/2011

Private Networks – Introduction and Legacy Solutions
Friday, January 28th, 2011 | Author:

META: This article is a draft for a chapter of my Research Paper for this semester.

Introduction

An Enterprise Network is usually a network of a medium-to-large company that has multiple branches in different geographical locations, each branch with its own local data networks. The branches need to communicate in order to access each other’s resources (for example the company’s centralised database). Having its own direct cable connections between all the branches is practically impossible, so the company will have to depend on a Service Provider (SP) for interconnecting the sites. This can be done in several ways, using different technologies and protocols, each with its pros and cons, varying in price, ease of implementation, features, throughput and security.

A generic topology consists of the following:

P – Provider Equipment
PE - Provider Edge Equipment
CE – Customer Edge Equipment
C – Customer Equipment

The Service Provider has its network (cloud) of PE and P equipments, the Provider Equipments being in the core of the network and the Provider Edge Equipments at the border. The client company has in each branch a CE connected to a PE, and behind the CE all the rest of the Customer Equipment.

Depending on the technologies used, each of these equipments can take different forms.

Leased lines

The most basic connection type for the Service Provider to provide a leased line. This would practically give the company a virtual cable between two locations. The edge routers in the branches would see each other as they were directly connected, as a point to point connection.

Having a leased line gives you control over both Layer 3 and Layer 2. This means that the company can choose the encapsulation of the line. It can go for a simple PPP connection, or PPP with PAP or CHAP configuration for privacy against Layer 1 attacks, or configure compression for traffic or any other encapsulation wanted. The edge routers would be in a common broadcast domain meaning that the company can also chose the Layer 3 protocol (IPv4, IPv6,
CLNS).

Leased lines are rather expensive and they do not scale well. The approach is acceptable if the company has two branches, but for n branches, n*(n-1)/2 lines would be needed to have full connectivity. Frame Relay could be used to solve this problem.

Frame Relay

To have a scalable network, the company could use a technology like Frame Relay, connecting several sites over the Server Provider’s network infrastructure. Frame Relay is a Layer 2 protocol and it connects the company’s
edge routers to a Frame Relay Cloud (ran by the Service Provider). The SP is in charge of providing point-to-point or point-to-multipoint connections between routers by the use of Virtual Circuits (VC).

Several companies can use the the same physical infrastructure of the SP, but each company will have its own set of Virtual Circuits so data will not be visible between companies, securing privacy of data.  The Virtual Circuites are switched in the FR Cloud with the use of an identifier called a DLCI that is attached to each frame sent in the Cloud. The SP will use DLCIs to get data from one edge router to another. It is easier and cheaper to have new Virtual Circuits than new physical connections between different sites. But the fee of the SP is still on a per VC basses, so rather than having full mesh topologies companies will chose hub and spoke topologies (the Headquarter usually being the hub).

Configuration example (IOS based equipment)

hostname CE1
!
interface Serial2/0
ip address 123.0.0.1 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
!

hostname PE1
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
frame-relay intf-type nni
frame-relay route 300 interface Serial2/0 100
!
interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
frame-relay intf-type dce
frame-relay route 100 interface Serial1/0 300
frame-relay route 102 interface Serial1/0 102

hostname P
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
frame-relay intf-type nni
frame-relay route 300 interface Serial1/1 400
!
interface Serial1/1
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
frame-relay intf-type nni
frame-relay route 400 interface Serial1/0 300

hostname PE2
!
interface Serial1/1
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
frame-relay intf-type nni
frame-relay route 400 interface Serial2/0 200
!
interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
frame-relay intf-type dce
frame-relay route 200 interface Serial1/1 400
frame-relay route 201 interface Serial1/1 201

hostname CE2
!
interface Serial2/0
ip address 123.0.0.2 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
!

Observations

These two solutions, very commonly used until recently, are by design private because the traffic between the company’s offices can’t be seen by anyone except the Service Provider. If layer 2 or upper mechanisms of data encryption are used, even the SP will be prevented from reading the data. The company can’t be attacked with malitios data because outside traffic won’t reach the Customer Equipments.

The downfall of these solutions came with the rise of the Public WAN, the Internet. A company that wanted a WAN  connection between the sites and connection(s) to the Internet needed to purchase two separate services. Because of the cheap nature of the Internet, companies preffer to have the Internet connections for their offices and also use it as a way of connecting different branches. This solves some problems, but introduces others.