[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.

[Originally posted on ccielab.ro]

Unlike Linux’s iptables, Cisco’s filtering via Access Control Lists sometimes has hidden behavior.

Let us test how ACL filtering works using the following topology. We assume that we have Layer 3 connectivity via static routes. We will apply ACLs on the outbound direction of F1/0 on R2 (we want it to be somewhere in the path from R1 to R3)

With no ACLs applied anywhere, all traffic will flow.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent

Let’s start with the basics and make a classic standard access list that denies R1′s loopback.

R2(config)#access-list 42 deny host 1.1.1.1
R2(config)#int f1/0
R2(config-if)#ip access-group 42 out

The loopback on R1 is blocked…

R1#ping 3.3.3.3 source 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

… but so is any other traffic that goes out of R2′s F1/0.

R1#ping 3.3.3.3 source F0/0
U.U.U
Success rate is 0 percent (0/5)

The first rule of Cisco’s ACLs is that there is an implicit deny (ip) all (all) rule at the end of every ACL. But this is not visible anywhere. You have to know it.

R2#sh access-lists
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

But if that ACL is empty? What if you apply an access list that does not contain any rules (was not declared)?

R2(config)#int f1/0
R2(config-if)#ip access-group 28 out
R2(config-if)#do sh access-lists
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic passes. The inexistent ACL applied on an interface is ignored. But this is because you can’t have an empty classical (numbered) ACL. What if you do the same thing with a named ACL?

R2(config)#ip access-list standard EMPTY_ACL
R2(config-std-nacl)#exit
R2(config)#do sh ip access-list
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Standard IP access list EMPTY_ACL
Extended IP access list BLOCK_HTTP
R2(config)#int f1/0
R2(config-if)#ip access-group EMPTY_ACL out

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic is still not filtered. So, the rule is that a empty (inexistant or deleted) ACL is ignored by the interface filter.

One more ACL applied on R2 with a deny all rule (no traffic should pass out of F1/0).

R2(config)#ip access-list standard DENY_ALL_ACL
R2(config-std-nacl)#deny any
R2(config-std-nacl)#do sh ip access
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Standard IP access list DENY_ALL_ACL
10 deny any (8 matches)
Standard IP access list EMPTY_ACL
10 deny any (8 matches)
Extended IP access list BLOCK_HTTP
R2(config-std-nacl)#int f1/0
R2(config-if)#ip access-group DENY_ALL_ACL out

Ping form R1 is filtered.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

Since no traffic should go out the interface, a ping from R2 to R3 should also fail, yet it doesn’t.

R2#ping 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/44 ms

As a final rule, traffic generated by a router is never filtered by an ACL applied any interface of that router.

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

[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?

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

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/

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ă.

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

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.

[Originally posted on ccielab.ro]

Frame Relay is still very much a popular subject in exams, labs and in the real networks.

Any lab with topologies that run different protocols over FR must start with the layer 2 configuration of the Frame Relay switched network. FR Topologies like full mesh or hub and spoke require a Frame Relay Switch. A FR Switch is a normal router but specifically configured to do Frame Relay switching.

First of all, we need to tell the router to start switching Frame Relay traffic. From global configuration mode we need to issue the frame-relay switching command.

Then, on the interfaces to Frame Relay clients, we need to start sending keepalives (LMIs) by configuring the interface as DCE with the frame-relay intf-type dce command.

The last thing that the FR Switch needs to do is to route DLCI on the virtual cicuits. This is done to tell an interface where to put a received frame with a DLCI. The frame will be put on another interface with another DLCI. The configuration is done per interface with the frame-relay route command. The command requires that you specify the incoming DLCI, on which the switching decision will be maide, the outgoing interface, and the DLCI with which the frame will be sent (“freame-relay route IN_DLCI OUT_INT OUT_DLCI”).

If Inverse ARP is not disabled on the FR Switch, no DLCI-IP mappings will be required.

Topology:

Configuration:

R1(config)#int s0/0
R1(config-if)#no shut
R1(config-if)#encapsulation frame-relay
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0

R2(config)#int s0/0
R2(config-if)#no shut
R2(config-if)#encapsulation frame-relay
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0

FR-Sw(config)#frame-relay switching
FR-Sw(config)#int s0/1
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 102 interface s0/0 201
FR-Sw(config-if)#int s0/0
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 201 interface s0/1 102

Running Configurations:

R1:

interface Serial0/0
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end

R2:

interface Serial0/0
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end

FR-Sw:

interface Serial0/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay intf-type dce
frame-relay route 201 interface Serial0/1 102
end

interface Serial0/1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 102 interface Serial0/0 201
end

[Originally posted on ccielab.ro]

This is the simplest use of a Frame Relay encapsulation and it’s between two routers, without a Frame Relay Switch. PPP or HDLC would make more sense to use in these types of links, but it is useful in labs.

In a back-to-back scenario is important to remember what the FR Switch should be doing: being the DCE and sending the keepalives to maintain the layer 2 link to the client router. Because of the fact that no FR Switch is present, the lack of keepalives being sent must be ignored using the “no keepalive” command. Also, Inverse ARP won’t work, so manual IP-DLCI mapping will be needed.

The FR Switch should be the one doing swapping of DLCIs on the network so the frames arrive at their destination with the correctly mapped DLCIs. In this case, we will need to have the same DLCI set in the manual mapping so the routers match entries in the mappings.

The topology:

Configuration:

R1(config)#int s0/1
R1(config-if)#no shut
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay map ip 10.1.2.2 42
R1(config-if)#no keepalive

R2(config)#int s0/1
R2(config-if)#no shut
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0
R2(config-if)#encapsulation frame-relay
R2(config-if)#frame-relay map ip 10.1.2.1 42
R2(config-if)#no keepalive

Running configurations:

R1:

interface Serial0/1
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
no keepalive
clockrate 128000
frame-relay map ip 10.1.2.2 42
end

R2:

interface Serial0/1
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
no keepalive
frame-relay map ip 10.1.2.1 42
end