[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

[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

[Originally posted on ccielab.ro]

One of the things that make Command Line Interfaces, like Bash, very efficient for administration is the output manipulation with piping and redirecting. Cisco IOS has most of the Bash equivalent modifiers, and administrators that know how to work with them can do things much more faster… this can make the difference in a lab exam or in the real world. Most show commands support this features and depending on the IOS, you have more or less features.

The usual “show run” command prints a large output, from which you need only a few lines. You can only scroll down with space and enter (the the Linux more command). If you are searching for a keyword in the running config, you can go to the line that contains the string using the slash key, like in vim or more or less in Linux. So, “/KEYWORD” after running the show command, while scrolling, will take you to the wanted line.

If you want from the output just some lines, you can filter them, just like piping the output to grep in Linux. You can use the ” | ” after the show command to see how you can filter (be careful, there is a space before and after the |). To print just the lines that have a keywork, use “ | include KEYWORD“, and to print all lines except the ones what have the keyword, use “ | exclude KEYWORD“. If you want to print out all output starting with a line that contains a keyword until the end of the lines, use “ | begin KEYWORD“.

Taking advantage of the hierarchical structure of the running config, you can print out just a section of the output. For example, “show run | section   router ospf 1” will list the configuration for the OSPF process 1 and “show run | section interface Serial0/0” will print the configuration for the specified interface. Be careful, this is case sensitive and you need to mach the case of the line in the running config (“Serial 0/0″ will work, “serial 0/0″ won’t).

Redirection into a file is also possible. “show run | redirect flash:run” will put the contents of the running config into a file called ‘run’ in flash memory. This is similar to the “>” operand in Bash. Using redirect, the content of the target file will be replaced. You can append to the file (like “>>” in Bash) with “ | append FILE“.  “ | tee FILE” works like redirect, but it also prints the output to the screen.

Regular expressions are also supported. If you like to print from the routing table, the routes received from RIP, you can filter with “show ip route | include R” and the routes from EIGRP with  “show ip route | include D”. But you can do this in one line, filtering with both conditions, with “show ip route | include [RD]“.

Slightly off topic, but good to know, is how to stop output. For example, traceroute to an unreachable location, will try 30 hops before it stops, and this might take a long time. To break the action hit the key combination “Ctrl+Shift+6“.

Conferința How to Web de sâmbătă [1] [2] a fost mai interesantă decât mă așteptăm. Subiectele au fost atractive și organizarea foarte bună pentru o primă ediție a unui eveniment destul de mare.

Prezentările nu au fost aproape deloc tehnice (lucru nu neapărat bun) dar au fost bine adaptate la ideea conferinței, cea de a aduce împreună pasionații web-ului cu profesioniștii lui.

Printre prezentările interesante s-au numărat una despre “User Experience Design”, în care s-a arătat importanța proiectării inteligente a unei interfețe cu utilizatorul (lecția învățată a fost că o interfață trebuie să fie: usable, useful, valuable, desirable, findable, credible, accessible).

Altă prezentare a fost despre “Cloud Computing”, o noțiune destul de nouă și căutată. În prezentare s-a vorbit despre părțile bune și parțile rele ale Cloud Computing.

O prezentare care nu are neapărat legătură cu web-ul ci cu business-ul a fost “Despre Antreprenoriat”. Un cuvânt ce s-a tot rostit pe parcursul conferinței a fost ‘start-up’, ce se referă la o companie (firmă) ce abia a pornit și este în drum spre succes. Prezentarea respectivă ne vorbea despre cum ar trebui abordată pornirea unei afaceri proprii.

Așteptăm ca pozele de la eveniment, precum și slide-urile, să fie postate pe site-ul oficial.

Felicitări pentru organizatori, ASPI [3] pentru o treabă bună făcută și așteptăm ediția de anul viitor.

Follow-up-ul oficial îl găsiți pe siteul How to Web [4]. Un altul, destul de lung, pe mai multe părți, aici [5], [6], [7], [8].

[1] http://www.how-to-web.net/

[2] http://alexj.info/2009/10/22/conferin%C8%9Ba-how-to-web/

[3] http://www.aspi.ro/

[4] http://www.how-to-web.net/2009/11/si-a-fost-how-to-web-2009/

[5] http://pow4ioc.wordpress.com/2009/10/31/how-to-web-part-i/

[Part I]
[Part II]

Clientul este un Linux box. Legătura la Internet este prin eth1, interfață peste care se face tunelul 6to4.

După ce am creat tunelul, am aflat că pot cere o clasă de IPv6 să fie routată prin IP-ul meu v6. Astfel, mi-a fost alocată rețeaua 2001:470:9f00::/48 ( 1208925819614629174706178 adrese adică adică aproximativ 1 milion de miliarde de miliarde de adese), pe care am început să o subnetez.

Prima rețea am alocat-o rețelei de pe eth1 (uplink-ul la Internet, precum și legătura cu alte servere locale). Pentru ușurință în denumire, am ales rețeaua 2001:0470:9f00:0141:0085:0037:0208::/112, adresă obținută prin o concatenare (la nivel de notație) a adresei IPv6 /48 alocate cu adresa IPv4/24 (141.85.37.208). Atenție, valorite în binar sunt total diferite, pentru că adresa IPv6 conține cifre în hexadecimal și IPv4 în decimal.

Configurație prin /etc/network/intefaces:

iface eth1 inet6 static
address 2001:0470:9f00:0141:0085:0037:208:1
netmask 112

Routarea IPv6 nu este implicit activată, și pachetele nu vor trece dintr-o rețea în cealaltă. Pentru aceasta, trebuie modificat fișierul /etc/sysctl.conf și decomentată (sau adăugată) linia:
net.ipv6.conf.all.forwarding=1
urmată de un restart a sysctl
sysctl -p

În continuare am alocat o altă rețea /112 pentru tunelul VPN peste care am o rețea IPv4 172.30.0.0/24 în spatele unui NAT. Partea frumoasă aici este că la IPv6 nu mai este nevoie de NAT pentru că sunt adrese routabile IPv6, deci traficul IPv4 va fi translatat la router în spatele unei singure adrese iar cel IPv6 va fi routat normal spre Internet. Rezultatul final a fost conectivitate IPv6 pe două sisteme care se află în cu totul altă rețea decât cea unde există tuneul 6to4, rețea ce se află in spatele unui NAT. Pentru a ajunge la un server IPv6 extern, aceste stații trebuiat să treacă peste printr-un tunel 6to4 aflat peste o conexiune VPN(OpenVPN) până la server unde era routat în altă rețea IPv6 care trecea peste un alt tunel 6to4 și routat mai departe doar prin IPv6.

[Part I]

De la provider-ul tunelului [1] am primit următoarele:

Server IPv4 address:      216.66.80.30
Server IPv6 address:     2001:470:1f0a:68d::1/64
Client IPv4 address:     141.85.37.208
Client IPv6 address:     2001:470:1f0a:68d::2/64

Între cele două adrese IPv4 este creat un tunel ce are alocată rețeaua IPv6 2001:470:1f0a:68d::/64 ( deci aproximativ 18 milidarde de miliarde de adrese pierdute pentru 2 adrese…dar nu e problemă pentru că sunt destule ).
Configurarea tunelului poate fi făcută în mai multe feluri.

Temporară prin ifconfig/route

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.80.30
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f0a:68d::2/64
route -A inet6 add ::/0 dev sit1

Temporară prin iproute2

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.80.30 local 141.85.37.208 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f0a:68d::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

Permanentă (on boot) prin /etc/network/interfaces
iface he-ipv6 inet6 v4tunnel
endpoint 216.66.80.30
address  2001:470:1f0a:68d::2
netmask  64
mtu 1480
up ip -6 route add 2000::/3 dev he-ipv6
down ip -6 route del 2000::/3 dev he-ipv6

[1] http://www.tunnelbroker.net/

Deși mai configurasem o adresăIPv6 și cu alte ocazii [1], nu intrasem adânc în subiect decât la clasa de BSCI de la Cisco pe care am terminat-o recent. După clasă, pentru că mi-a plăcut subiectul, am încercat să văd IPv6 în viața reală, ceea ce era puțin problematic pentru că legăturile mele la Internet vin numai în varianta IPv4.

Dar am descoperit un site interesant, TunnelBroker [2], care oferă tunele IPv6 peste conexiuni IPv4, gratuit. Provider-ul respectiv are o rețea globală de servere accesibile prin IPv4, dar care routează IPv6 în Internet. Tot ce e nevoie este un server propriu sau un workstation care să aibă un IP public (acesta va fi clientul). Configurația tunelului se face într-o parte automat, pe site și cealaltă parte pe stația locală manual. Instrucțiunile complete se găsesc pe site.

Aceeași firmă ce administrează site-ul TunnelBroker și rețeaua de servere, Hurricane Electric, oferă și o certificare [3] de atestare a cunoștințelor despre IPv6. De exemplu, primul test constă într-un quiz despre IPv6 iar al doilea presupune configurarea unui client care să fie capabil să acceseze o pagină IPv6.

Fun fact: Există un ‘experiment’ pentru a promova IPv6 [4], dar care, momentan, pare a fi mort.

[1] http://alexj.info/?p=92

[2] http://www.tunnelbroker.net/

[3] http://ipv6.he.net/certification/cert-main.php

[4] http://ubergeek.ro/2008/08/22/ipv6-experiment/

Am primit azi un email de la Juniper în care am fost acceptat la Juniper Summer School [1]. Ce a fost interesant e că mi-au trimis și un fișier în care era salvat calendarul programului. Era un fișier .ics, care am aflat că este format iCalendar (by Apple). Cum nu foloseam iCalendar, mi s-a părut inutil, dar în email era menționat faptul că pot folosi fișierul inclusiv în Google Calendar.

Astfel am aflat de funcția de import de la Google Calendar [2] . Sunt compatibile mai multe fișiere, printre care și acesta.

Pentru a importa un calendar, se intră pe Google Calendar. Sub lista de calendare există butonul de Settings, iar pe pagina de setări pentru fiecare calendar, există un link de Import Calendar. Pe pagina de Import se încarcă fișierul și se poate alege ca datele din fișier să fie integrate într-un calendar existent sau să se creeze un calendar nou.

Ce am dorit să fac: un program în Java ce capturează conversații de pe IRC și le stochează într-o bază de date mySQL; din acea bază de date se ia prin PHP și se afișează pe o pagină HTML. Deși pare destul de mult de făcut, necesită puțin cod, dar multă atenție la interconectarea elementlor: programul Java, conectorul dintre Java-mySQL (JDBC), baza de date mySQL și script-ul PHP.

Am creat ‘topologoia’ necesară și programul mergea ok. Dar am descoperit rapid o problemă: pagina web (HTML+PHP) nu afișa diacritice. Și am început să caut prin fiecare element să văd unde era problema ( oricare din componente putea să ducă la problema aceasta).

Am început prin modificarea paginii PHP/HTML și forțarea ca browserul să citeacă caracterele în format UTF-8. Codul nu depinde de PHP (am presupus că el transmite corect din baza de date în HTML) ci de headerul HTML.

<head>  <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />   [...]  </head>

Al doilea test a fost făcut pe mySQL. Implicit, baza de date codează folosind Latin.  Și tabela unde se făcea scrierea trebuia trecută pe UTF.

CREATE TABLE `chats` ( [..] ) DEFAULT CHARSET=utf8;

Cum programul Java imprima corect la stdout diacriticile, problema trebuia să fie la JDBC. Suportul pentru UTF a fost adăugat în JDBC, dar trebuia specificat la conectarea cu baza de date. Acest lucru se face pasând un parametru la  URL-ul bazei de date.

jdbc:mysql://my_server/my_data_base?unicode=true&characterEncoding=utf-8