2014-04-18 “IPv6 Deployment in Sofia University” lecture at RIPE-SEE-3

April 18th, 2014 by Vasil Kolev

This is my talk from RIPE-SEE3, on the deployment of IPv6 in Sofia University. The presentation can be downloade in pdf or odt format.

I’ve put the slide number or the notes/comments I have in [], the rest is as close to what I said as I remember, with some corrections.


Hello. I’m going to talk about the IPv6 deployment in Sofia University. It’s an important example how this can be done on a medium-to-large scale, with no hardware upgrades or hidden costs.

This presentation was prepared by Vesselin Kolev, who did most of the architecture of the network there and was involved in its operations until recently.

(I want to clarify, we’re not the same person, and we’re not brothers, I get that question a lot)


Please note that I’m only doing this presentation, I was not involved in the deployment or any network operations of the university’s network.


These are the people that did and operated this deployment. Most of them aren’t there any more – Vesselin Kolev is at Technion in Israel, Nikolay Nikolov and Vladislav Rusanov are at Tradeo, Hristo Dragolov is at Manson, Radoslav Buchakchiev is at Aalbord University, Ivan Yordanov is at Interoute, Georgi Naidenov is a freelancer. Stefan Dimitrov, Vladislav Georgiev and Mariana Petkova are still at the university, and some of them (and some of the new people there) are at this conference, so if you have questions related to the current operations there, they’ll probably be able to answer better than me.


So, let me start with the addressing.


This is the current unicast network that’s in use in the university. It was assigned around February 2011 and was used from the 11th of February 2011 onwards. It’s a /47, later on I’ll explain why.

Also please note that the maintenance of the records in the RIPE database for the network is done only with PGP-signed emails, to protect this from hijacking. As noted by one previous speaker, there are a lot of cases in RIPE NCC, where bad people try to steal prefixes (as their value is rising), and that’s possible mostly because there aren’t good security measures in place in a lot of LIRs.


Before that, the university used a /35 from SpectrumNet (since then bought by Mobiltel), until they got their own allocation.

It should be noted that in IPv6, the renumbering is a lot easier than in IPv4 and this was done very fast.


Now, on the allocation policy,


this is how unicast addresses are assigned. It’s based on RFC4291, and for the basic entities in the university (faculties) there’s a /60, for each backbone network, server farm or virtual machine bridge there’s a /64, and all the additional allocations are the same as the initial size (on request).
Also, allocations of separate /64 are available for special/specific projects.


The university also utilizes RFC4139 addresses, for local restricted resources. The allocations are done on /32 basis.


Now, onto the intra- and inter-AS routing,


The software used is Quagga on CentOS.
There is a specific reason for using CentOS – the distribution is a recompilation of RHEL, and follows it closely, which means that it’s as stable as it gets – if there’s a security or other important update, just the pieces are backported to the current version of the software, which effectively means that you can have automatic updates running on your servers and routers and be confident that they won’t break horribly.
That’s in stark contrast with almost every router vendor I can think of.


The current transit providers for the university network are Unicom-B (the academic network in Bulgaria), and SpectrumNet (now owned by Mobiltel).
The university has private peering with Digital systems, Evolink (it changed it’s name from Lirex), ITD, Netissat and Neterra. It also provides an AS112 stub node.

(For the people that don’t know, AS112 is somewhat volunteer project run anycast nodes for the DNS servers for some zones that generate crap traffic, e.g. “example.com”, or the reverse zones for the RFC1918 addresses)


This is the basic schema of the external connectivity. The university has two border router, each of which is connected to both upstream providers (and to the private peers, but that would’ve cluttered the drawing too much). They’re interconnected through one of the MAN networks, and are in the Lozenetz campus (where the University Computing Center is, the main operator of the network) and the Rectorate.


These are the prefixes that the university originates. Here we can see why the university has a /47 – so it could be de-aggregated, for traffic engineering of the inbound traffic. That’s one problem that nothing has solved yet, and that would plague us for a lot more years…
Here each border router announces a /48, and both announce the /47, so they can effectively split the inbound traffic.

There’s also the IPv6 prefix for AS112, announced from both borders.


This is what every router should do for the prefix announces it receives. Basically, everything from a private ASN is dropped, and all prefixes that are not in 2000::/3 (the unicast part of the IPv6 space), are shorter than /3 or longer than /49 are also dropped.


Here you can see the schema of the backbone network – the two border routers, and the access routers of the faculties. They’re all under the administrative control of the network operations team.


For this schema to work efficiently, the two border routers do the job of route reflectors, and the access routers are route reflector clients – e.g. each access router has two BGP sessions, one with each border router, and that way it learns all the routes coming from the rest of the access routers.
This setup would’ve been unmanageable otherwise, as doing a full mesh of so many routers would’ve resulted in full mess.
[Ok, I didn't think of that pun at the presentation]

[back to 16]

The initial idea was to actually have the border routers be route reflectors only, and have all the access routers in the VLANs of the external BGP peers, for the traffic to flow directly and not have the two borders as bottlenecks. This wasn’t implemented because of administrative/layer8-9 issues.


This is how the core network connects with the faculty networks – the access router is connected in a network with the routers of the faculty, and via OSPF (or RIP in some cases) it redistributes a default route to them.

(Yes, RIP is used and as someone told me a few hours ago, if it’s stupid and it works, maybe it’s not that stupid)


Now here’s something I would’ve done differently :)

Both OSPF and RIP are secured using IPSec, here’s how the config looks like.


This is not something that you usually see, mostly because it’s harder to configure and the weirdness in the interoperability of different IPSec implementations. For an university network, where risk factors like students exist, this provides a layer of protection of the routing daemons (which, to be frank, aren’t the most secure software you can find) from random packets that can be sent in those segments.
It’s reasonable to accept that the kernel’s IPSec code is more secure than the security code of the routing daemons.

This the only thing that this setup provides more than the other options – a pre-shared key is used, as there aren’t any implementations that have IKEv1 and can be used for this task.

Also, this is harder to operate and configure for untrained personnel, but the team decided to go ahead with the extra security.


And of course, there has to be some filtering.


Here’s a schema of one external link – in this case, to Neterra.


Here we can see the configuration of the packet filtering. This is basically an implementation of BCP38.

First, let me ask, how many of you know what BCP38 is?
[about 25-30% of the audience raise their hands]
And how many of you do it in their own networks?
[Three times less people raise their hands]
OK, for the rest – please google BCP38, and deploy it :)
[Actually, this RFC has a whole site dedicated to it]

Basically, what BCP38 says is that you must not allow inbound traffic from source addresses that are not routed through that interface. In the Cisco world it’s known as RPF (Reverse path filtering), AFAIK in Juniper it’s the same.

In Linux, this is done best using the routing subsystem. Here what we can see is that on the external interface we block everything that’s coming from addresses in our network, and on the internal – anything that’s not from the prefixes we originate.


Here we can see the setup on an access router (as we can see, BCP38 is deployed on both the border and access routers). Here we can differentiate and allow only the network of the end-users.


On the border routers, there’s also some filtering with IPtables, to disallow anyone outside of the backbone network to connect to the BGP daemon, and also to disallow anyone to query the NTP server.
(what’s not seen here is that connection tracking is disabled for the rest of the traffic, not to overload it)


On the access routers, we also have the filtering for the BGP daemon and the NTP server, but also


we filter out any traffic that’s not related to a connection that was established from the outside. This is the usually cited “benefit” of NAT and the reason for some ill-informed people to ask for NAT in IPv6.

With this, the big-bad-internet can’t connect directly to the workstations, which, let’s be frank, is a very good idea, knowing how bad the workstation OS security is.


The relevant services provided by the university have IPv6 enabled.


Most of the web server have had support since 2007.

The DNS servers too, and there’s also a very interesting anycast implementation for the recursive resolvers that I’ll talk in detail about later.

The email services also have supported IPv6 since 2007, and they got their first spam message over IPv6 in on the 12th of December, 2007 (which should be some kind of record, I got mine two years ago, from a server in some space-related institute in Russia).


ftp.uni-sofia.bg has been IPv6 enabled since 2010, it’s a service for mirroring different projects (for example Debian).

The university also operates some OpenVPN concentrators, that are accessible over IPv6 and can provide IPv6 services.


The coverage of the deployment is very good – in the first year they had more than 50% of the workstations in the Lozenetz campus with IPv6 connectivity, and today more than 85% of the workstation in the whole university have IPv6 connectivity.
(the rest don’t have it because of two reasons – either they are too old to support it, or they are not turning it on because they had problems with it at the beginning and are refusing to use it)

Around 20% of the traffic that the university does is IPv6.
[question from the public - what is in that traffic? We should be showing people that there's actually IPv6 content out there, like facebook and youtube]

From my understanding (the university doesn’t have a policy to snoop on the users’ traffic) this is either to google(youtube), or to the CERN grid (which is IPv6 only). Yes, there actually exists a lot of content over IPv6, netflix/hulu have already deployed it, and it’s just a few of the big sites (twitter is an example) that are still holding back.

The university provides both ways for the configuration of end-nodes – Router Advertisement (RA) and DHCPv6. For most cases they’re both needed, as RA can’t provide DNS servers, and DHCPv6 can’t provide a gateway (which is something that’s really annoying to most people doing deployments).


Here’s how the default route is propagated in the network.


This was actually a surprise for me – there are actually two default routes in IPv6. One is ::/0, which includes the whole address space, and there is 2000::/3, which includes only the unicast space. There is a use for sending just 2000::/3, to be able to fence devices/virtual machines from the internet, but to leave them access to local resources (so they can update after a security breach, for example).


Here is how you redistribute ::/0, by first creating a null route and adding it in the configuration.


And here’s how it’s propagated in the network, using OSPF.


We can do the same for 2000::/3,


and push it to the virtual machines, who also have connectivity to the local resources through a different path.


Now, this is something very interesting that was done to have a highly-available recursive DNS resolver for the whole network.

[40 and 41 are the same, sorry for the mistake]


This is how a node works. Basically, there’s a small program (“manager”) that checks every millisecond if the BIND daemon responds, and if it’s just starting, it adds the anycast resolver addresses to the loopback interface and redistributes a route through OSPF.

(note the addresses used – FEC0::.. – turns out that this is the default resolver for MS windows, so this was the easiest choice. Seems that even in the land of IPv6 we still get dictated by MS what to do)


If the name server daemon dies, the manager withdraws the addresses.

Also, if the whole nodes dies, the OSPF announce will be withdrawn with it.


Here you can see what changes when a node is active. If one node is down, the routers will see the route to the other one, and send traffic accordingly.


And if they’re both operational, the routers in both campuses get the routes to the node in the other campus with lower local preference, so if they route traffic just to their own, and this way the traffic is load-balanced.


Thank you, and before the questions, I just want to show you again


the people that made this deployment. They deserve the credit for it :)

[In the questions section, Stefan Dimitrov from SU stood up and explained that now they have three border routers, the third one is at the 4th kilometer campus]


April 15th, 2014 by Vasil Kolev

И мина RIPE-SEE-3.

Проведе се в х-л Кемпински, за два дни, беше с малко лекции/workshop-и и доста разговори/networking (видях се с хора, с които не се бях виждал от 10+ години).

Пропуснах първите неща от първия ден, че бях зает да си нося лаптопа на ремонт (и все пак да се наспя), та хванах сесиите след обяда. Първо слушах човека от DT по темата за новата мрежа, която правят (TeraStream) – интересна идея, забавното беше как чак 2011 осъзнали, че мрежата им е остаряла и не става, но па сега я правят както трябва – чист ipv6 (ipv4 е service с тунели отгоре), 100gbps и anycast на интересните услуги. Също така им е хрумнало в адреса да слагат няколко бита, които да играят ролята на QoS битовете, и да раздават няколко префикса на потребител, например един за видео/телевизия, един за voice, един за internet, и мислят как да стандартизират процеса за избиране на source адрес.
RIPE разказаха за различните неща, които правят – конференции и т.н., Erik Vinecke от cisco разказа нещо за мерене на ipv6 deployment-и, което заедно със следващите две неща не слушах, понеже си препрочитах моята лекция.
(чух някакви части от лекцията на Nathalie Trenaman за нейния deployment на ipv6 у тях, и си беше интересно и доста мъчително, Мариян я пита във въпросите що се е мъчила да се занимава с vendor-и, вместо да ползва opensource неща)

Моята (реално на Весо) лекция мина много по-добре, отколкото очаквах, и понеже няма записи малко по-късно ще я напиша на текст и кача заедно с презентацията. Хората изглеждаха заинтересувани, и даже се водеше една от по-техническите на конференцията.

Накрая на първия ден вечеряхме във Весело село (в което никога не бях ходил, и ми стана ясно защо), но храната ставаше, и успяхме даже да направим нещо интересно – да подкараме група на мрежовите оператори (за пореден път), понеже всеки, който питахме там каза “да, бих се записал”. Да видим :)

Втория ден започна с лекция за Ansible (което се оказа някакъв вариант на chef/puppet/cfengine), нищо интересно, след което имаше доста интересна лекция за “Crowdsourcing Infrastructure Geolocation”, т.е. проект, който по различни начини определя къде се намират ip-тата на разни router-и, за да може човек да си визуализира traceroute (note to self, да си оправя всичките DNS LOC записи). Искрено се надявам проекта да успее :)

От следващите неща слушах IXP панела, където от няколко български exchange-а, един чешки и (май единствения) сръбски хората обсъждаха различни оперативни неща. За съжаление не успяха да стигнат до техническата част, но доста дъвкаха for-profit и non-profit моделите, което пак беше интересно.

Следващият слот беше по “Governance” темата и привлече най-страшните въпроси. Първо говори един човек от CERT България (който не беше лектора по програма) и беше в общи линии изяден с парцалите, понеже нищо не знаеше.
После говори Венета Донова за net neutrality-то в Европа и в България, основно за законовите моменти около него – беше разширение и update на лекцията и от openfest (ако не се лъжа), и се получи доста добре.
Последва я Аглика Клайн от Europol EC3 – отдел, който се занимава с техническата част на разследванията, анализа и координиране на операции. В общи линии въпросите към нея бяха “защо да ви вярваме”, “вие сте тия, дето ни тровят най-много живота”, спряхме се на това как детското порно се използва основно срещу доставчиците (имаме си достатъчно такива случаи в България) и т.н., и т.н.. Успя да издържи на въпросите, но се измъкна от някои въпроси. Имаше и момента, че от една страна нямат право да приемат feedback и каквото и да е от хората или фирмите (само от държавите-членки), но от друга страна са пускали по молба на microsoft advisory, да кажат на хората, че XP-то спира да се поддържа.
(после имаше и допълнителни разговори и обяснение как една от причините никак да не ги обичаме е, че ги използват много усилено срещу нас, и че те са от хората, които трябва да се борят за улесняване на security research-а, не срещу него (както са направили в Германия със забраната да се пишат exploit-и), трябва да и пратя на FX лекцията за хардуера, който law enforcement хората ползват и колко е счупен)

Имаше три lightning talk-а, от които единия беше за BGNOG-а (който споменах по-горе), успяхме да стигнем от идея до реализация за около 12 часа.

В последният слот интересните лекции бяха две. Едната беше за RIPE Atlas проекта, и за anchor машините (за които мисля да взема една в нашия datacenter, Мариян се замисли за три), самият проект има лесен начин да се интегрира в monitoring системите ми и мисля тия дни да му отделя малко време. Другата лекция беше сравнителен анализ на internet-а в България, Турция и Румъния, гледан от BGP гледна точка, от Renesys – накратко, в Турция нещата не са добре, при нас и в Румъния са доста по-чисти, като в Румъния са около три пъти по-големи. Удобни сме от гледна точка на латентност за финансови и т.н. институции да си слагат тук нещата, дано успеем да се възползваме.

Като цяло събитието беше страхотно, и трябва да се направи пак (следващото е в Белград догодина, и може би след това пак да се случи при нас), много беше полезно от всякакви гледни точки – и контакти, и свършена работа, и никак не съжалявам за двата изкарани дни. Вероятно ще се сещам още неща и ще дописвам в идващите дни :)

Update: Трябваше да привлачим и Яна на събитието, понеже изкарах накрая поне половин час да давам идеи как да привлекат повече хора – имаше около 220 дошли, и те го считаха за голям успех, но аз си мисля, че даже чистите мрежови администратори в България са поне 150-200 и щеше да им е интересно да дойдат. Едното нещо, което може да помогне е NOG-а, другото – просто да си говорят директно с някакво количество хора/LIR-ове, не през някакви тежки mass mail-вания до адреси от базата им, щото тях никой не ги чете сериозно.

Update 2: Сайт с наземни кабели, за който не знаех (като допълнение на за подводните).

2014-04-14 Филм за гледане

April 13th, 2014 by Vasil Kolev

“Чичо Тони, тримата глупаци и ДС”трейлър).

Почти никой не прави у нас филми, дето да си заслужават времето дори да ги изтеглиш, какво остава да ги гледаш. Явно па тези, които си струват, се намира кой да ги преследва и да се опитва да ги спре/забрани.

Весела Казакова е направила филм за човекът зад голяма част от анимациите, които се водят на Доньо Донев, и който не е признат основно защото ДС не са го харесвали. Пробвайте се да отделите малко време, да не трябва да се примиряваме с “Хубав е филма, като за български”.

Весела Казакова е говорила пред Капитал по темата.

2014-04-13 Краков 3,4

April 13th, 2014 by Vasil Kolev

Втория ден, след като се намързелувах и се появиха хора в Краковския hackerspace, отидох да ги видя.

Мястото не е лошо (и сравнително лесно се намира). Имат звънец, който отваря вратата автоматично, ако позвъниш Y в морзов код (ама дългите тонове трябва да са наистина дълги, над секунда), прилично количество място, бая хардуер и като цяло весели хора. Бяха малко под пара, че предната вечер беше имало хакатон, а през деня щеше да има някакъв workshop, но успяхме да поговорим и да ми покажат мястото, ако имате път натам – идете им кажете здрасти :)

А аз в неделя сутрин докато тихичко си работех ми опука дисплея на лаптопа, та по случая тия дни ще съм малко offline през деня (ще съм на RIPE SEE-3 и ще съм малко ограничен в това кога ще мога да съм си пред машината).

(имах един таблет с мен и от него свърших някакви неща, ама клавиатурата му е нечовешка. Добре поне, че gps-а му работеше добре и че offline картите на OSM са точни, та да ми е полезен)

2014-04-11 Краков – 2

April 11th, 2014 by Vasil Kolev

И днес беше деня на посещението в Аушвиц.

(четох си по пътя “Dominion” на C.J.Sansom, частта в която изселват евреите в Англия, беше странно)

Обиколката продължи няколко часа – първо в Аушвиц 1, после в Аушвиц 2 – Биркенау. Първият лагер е доста по-малък, вторият прилича на набор бараки за животни посред полето. Доста са запазени, особено телените огради и доста от сградите, и си е интересно да видиш на живо как са изглеждали нещата (и например как изглеждат два тона човешка коса). Не мисля, че преживяването е за хора с по-слаби нерви, нищо, че екскурзоводите са доста внимателни и се стараят да обясняват спокойно и нетормозещо.

Жалко, че няма така запазени лагери от ГУЛАГ-а, да може да се направи едно хубаво сравнение.

2014-04-10 Краков – 1

April 10th, 2014 by Vasil Kolev

И дойде време да си използвам странния подарък за рождения ден – екскурзия до Аушвиц/Биркенау (Освиенцим).

Полетът ми беше в нормално време и с online checkin-а даже идиотското задръстване по Цариградско шосе не беше проблем. Летях през Виена и стигнах съвсем спокойно в Краков (само в последния полет имаше някакъв пиян руснак с трима цивилни полицаи около него).

Валеше, сега още духа доста вятър, но май времето не е много по-различно от София.

Съвсем лесно си намерих мястото за спане (един много готин таван в една кооперация без асансьор), след което с помощта на един таблет с gps и osmand на него си намерих един супермаркет, в който да си напазарувам храна (който освен, че супер много приличаше на малките български от рода на Пикадили експрес, беше и бая евтин).
(цените в/у две са в лева, в/у четири – в евро, доста лесно се смята)

Та, аз мисля да се излежавам, чета и може да попиша по една лекция, ако на някой му трябвам – няма ме :)

(обществено-полезната работа я свърших, писах mail на админа на www.uni-sofia.bg, че са vulnerable за heartbleed проблема)

2014-04-08 openssl vulnerability CVE-2014-0160

April 8th, 2014 by Vasil Kolev

Не че не сте видели от други места, но:
официалния сайт на openssl.

apt-get update && apt-get -y dist-upgrade и ритнете каквото трябва.

(алтернативното заглавие беше fuckfuckfuckfuckfuckfuckfuckfuckfuckfuck)

Update: Сайт, който тества за проблема.
Update 2 command-line test tool.

2014-04-07 иде RIPE-SEE-3

April 7th, 2014 by Vasil Kolev

RIPE SEE-3 ще се проведе следващата седмица в София. Ще има двама български лектори (Венета Донова и аз), публикували са програма, ако искате да дойдете, все още може да се регистрирате.

2014-04-05 Лекция “Single points of failure и избягването им” от RogueConf 2014

April 5th, 2014 by Vasil Kolev

Това ми е в общи линии лекцията от rogueconf, презентацията може да се свали от тук, записът от тук. Има прилични разлики в това, което говорих, и реално ми се искаше да наблегна много повече на дистрибутирането, но нямах време да се подготвя и да го събера в нормалното време.

(и определено можеше да е по-добре, не става добре да говоря на конференции, където имам занимания и с организацията)

Single points of failure

[за какво става въпрос]

Single point of failure е единичен компонент от система, при чиито отказ цялата система спира да работи.

В системите, които правим/ползваме и са повече от един сървър, на който ни е всичко (т.е. един гигантски SPOF) такива неща пак се срещат доста често.

[авиационен модел]

Това е мечтания модел, който даже съществува в реалния свят. Това е напълно подсигурена система, при която имате главен компютър с един софтуер и един хардуер, backup компютри с два различни хардуера и един софтуер, който е различен от главния, и система за следене и кворум. В самолета освен това има и двама пилоти и всякакви резервни варианти.

[авиационен модел 2]

Това е скъпо. Толкова скъпо, че го правят само за случаи, при които умират хора (т.е. дори и в медицинската апаратура не се стига до такива подсигурявания).

Също така системите стават твърде усложнени, като пример – A380, който е наистина подсигурена система, има в себе си 530км кабели. Цената да се изгради и да се поддържа такава система не е по силите на някой друг.

[три неща]

И три неща, за които няма да говоря подробно.


Софтуерните SPOF-ове никой не се опитва да ги заобикаля, или поне не сериозно. Правенето на няколко независими реализации на дадено нещо рядко е оправдано, отнема двойно повече усилия и се дебъгват два пъти подобни проблеми без да може кой-знае колко да се приложат знанията от едното в другото. Поддръжката на две различни системи за същото нещо и комуникацията между тях правят цялото нещо повече от два пъти по-скъпо и сложно.

А проблемите, които се получават от тях са доста по-неприятни, понеже са лавинообразни – ако на няколко места имате същия софтуер, може да очаквате, че ще се чупи по същия начин и в същото време.


Човешките SPOF-ове са още по-гадна работа. Известни са още като “Bus factor”, т.е. колко човека трябва да ги блъсне автобус, за да спре да работи даден проект (и в много случаи факторът е 1).

В по-големите фирми се правят опити да се реши тоя проблем чрез взимане на повече хора, които да могат да поемат работата един на друг, но синхронизацията м/у хора се оказва още по-сложен проблем и не подлежащ на автоматизация.

Метод за омекотяване е писането на документация, което па всички го мразят.


Оценката кога си струва да се вложат средства, за да се избегне SPOF не винаги е тривиална и е за друг вид лекция. Има неща като risk assessment, гадаене по черва на гълъби, хвърляне на зарчета и статистически анализи, които се използват за целта, но много често и хората, които ги предлагат ги объркват…
(който се интересува от проблемите на анализа на риска, може да зачете Насим Талеб)

Като едно лично правило, гледам системите да нямат в себе си нещо, което е наистина трудно за дистрибутиране, или ако го има, да е максимално подсигурено (хубав хардуер, monitoring, резервни части, някакъв вариант да се реагира).


И нека се хванем с основния проблем във всички тези неща – състоянието, или state, както му викаме.

От машините на Тюринг насам състоянието е нещо основно в това, което правим. Няма система без някакъв state, и съответно една голяма част от решаването на проблемите със SPOF-овете идват от там (иначе просто щяхме да хвърляме хардуер, докато нещата почнат да изглеждат добре).

Искам да го повторя и да покажа, не съществуват stateless системи.

[примерна не-stateless система]

Ето един често срещан пример – смята се, че ако имаме такава схема, то web сървърите ни са stateless, понеже реално са взаимозаменяеми.

От гледна точка на системата те имат два вида state. По-маловажният са заявките, които се обработват в момента (които не се смятат за важни и съответно дори да се загубят, се смята, че може да се повторят. Важният state е един бит, който казва дали този сървър е активен или не, и дали може да обработва заявки.

Съответно цялата система трябва да е сравнително сихронизирана за този един бит, за да може да работи правилно (т.е. ок е сървърът да работи, и системата да не смята така, не е ок да не работи и системата да се опитва да го ползва).


Ето няколкото типа решения на проблема.

[do nothing]

Това е стандартния план – повчето хора не очакват, че нещо лошо ще се случи, носят розови очила и не бива да бъдат допускани да мислят системи.

[backup plan]

Може да не е толкова безсмислен като тоя от слайда :)
Тук решението е да знаем какво правим, ако нещо се счупи. За някои по-малко важни системи например backup plan-а може да е “машината е в гаранция, ако се счупи нещо, обаждаме се на тия от които сме я взели и така”, или “обаждаме се на другарче”.

[cold spare]

Това вече влиза в категорията на решения, които уважаващ себе си админ би приложил. В реалния свят това е да имате резервна гума, някъде в шкафа резервни електрически крушки, или при системите – една готова цяла машина, която може да замести останалите, дискове или някакви други резервни части, за офис – втора internet връзка през някое 3g, която може да се ползва временно, ако наоколо са прекопали някой кабел.

Това е и едно от най-често срещаните решения, понеже доста лесно се прави. От друга страна може да предизвика прилично количество donwtime, докато се “стопли” резервата.

(някъде тук на лекцията се оказа, че има хора, които не държат резервни крушки у тях…)

[hot spare]

Това е също доста често срещано – имате готов топъл spare, който във всеки един момент е синхронизиран с това, което прикрива и при нужда автоматично може да поеме работата на изгорелия компонент.

Това много често се изполва в setup-и с бази данни или подобни неща, при които чистото дистрибутиране (за което ще говоря по-нататък) не може да стане заради CAP теоремата.
(ще намразите cap теоремата след малко)

Тук има един специфичен момент, т.нар. fencing – ако втората система поема работата на главната, трябва по някакъв начин да се гарантира, че главната е спряла и не прави нищо, за да не се стигне до омазване на shared state или нещо такова. За целта има няколко типа решения, някои от които просто спират тока на главната :)

[CAP теорема]

И така, преди да си говорим за най-хубавия начин – да имате N на брой машини, те да вършат едновременно работа и хем да се scale-вате, хем да сте защитени от сривове, да кажа защо това е непостижима мечта…

Теоремата е съвсем проста и гласи следното: една дистрибутирана система може да има най-много две от следните три свойства: Консистентна, винаги достъпна, издържаща разделение.

Консистентна значи, че във всеки един момент една заявка към нея ще даде същия отговор, без значение към коя част от нея се обръщаме, т.е. ако питаме базата “колко реда има в таблица X”, всичките и сървъри ще кажат същото нещо.

Винаги достъпна значи, че дори да са отпаднали някакви компоненти, тя все пак ще продължи да ни отговаря.

Издръжливостта на разделение значи, че не може да се достигне т.нар. split brain ситуация – ако системата се раздели на две части, не може двете да мажат в/у данните и да се получи при тях различна версия.

Това например значи, че не може по някакъв елементарен начин да си направите master-master репликация на базата данни.


И да си поговорим за мечтата, всичко да е дистрибутирано. Винаги ми се е искало да мога просто да добавям нов хардуер и нещата да работят и на него. Дори за някои неща това сме го постигали …

Това е постижимо, с някои ограничения. Понеже не ми хрумна по-добър начин, ще ви дам няколко примерни системи, които почти успяват да решат проблема :)

[load ballancers + web]

Това е един доста класически случай за повечето сайтове, на които не им се иска да имат downtime. Слагате отпред два load ballancer-а, които знаят кой от web сървърите отзад работи и балансират м/у тях заявките. Това работи много добре, сравнително стандартизирано е и сглабянето му не отнема особено много време. Достатъчно стандартно е, че amazon да предлагат компонентите му като някакъв service.

При отпадане на компоненти системата го усеща и спира да му подава трафик.

RAID масивите са доста близки като идея до това.

[синхронни бази]

По принцип повечето ACID бази данни използват сихнронна репликация, т.е. всяка заявка за писане се счита за завършена (т.е. се казва на клиента) когато всички компоненти от системата са я потвърдили. Това е почти същото като предния вариант.

[hack-ът за eventual consistency]

И има една добавка, като удобен hack при системи, при които има случаи, в които може да се прочетат стари данни, т.нар. eventual consistency.

В общи линии това представлява система, за която операциите за писане са приключили при запис в X компонента, като обикновено X=N/2 + 1. Тогава имаме inconstent четене, което може да чете от 1 компонент, и ако ни трябва консистентно, четем от N-X+1 компонента. Това се използва основно за системи, при които консистетният read е рядка операция.

[sharding + replication]

Това е текущият метод за репликиране на база данни. В общи линии умножавате факторите за на колко искате да разделите данните (за performance) и за redundancy и получавате колко железа ви трябват (в случая са 2X2).

Това обаче върши работа основно за прости заявки. В момента, в който трябва да съберете данни от две машини, за да направите join или нещо такова, нещата започват да се объркват.

2014-04-02 “Is Parallel Programming Hard, And, If So, What Can You Do About It?”

April 2nd, 2014 by Vasil Kolev

Преди няколко седмици излезе първото издание на “Is Parallel Programming Hard, And, If So, What Can You Do About It?” – книга под creative commons на Paul McKinley (по принцип kernel developer). Полезна е и информацията в нея е доста прясна и точна (а и като гледам, голяма част от нещата там не са се променяли от доста време, и има неща като RCU, memory бариери и т.н.) и я препоръчвам на всички.

Аз разпечатах десетина копия, и в момента има по едно в initLab, VarnaLab, BurgasLab и hackafe, като се планира втори print run, ако има хора, които имат желание да си вземат. Цената ще е около 30лв на копие, ако имате желание, пишете.
(или може да си я четете online или да си я разпечатате сами, не е сложно:) )

2014-04-02 Ro[gu]e conf 2014

April 1st, 2014 by Vasil Kolev

Мина RogueConf 2014. Направихме го тоя път в Боровец, в х-л Radina’s way, и си изкарахме доста добре.


(има странен момент с името. На разни материали беше объркано и беше Rougeconf (“розова конференция”), та това в един момент стана официалното име. Мисли се догодина да е RoughConf (а ако Стефан реши да е RogeConf, аз няма да ида))

Този път форматът беше малко по-различен – в четвъртък направихме unconference (т.е. имаше слотове, и всякакви хора се записваха да си говорят по някаква тема) заедно с малко lightning talk-ове, а в другите два дни направихме нормалната програма с лекции и lightning talk-ове.
(unconference толкова се хареса на хората, че може за в бъдеще изобщо да не правим лекции)

Аз направих една дискусия на тема гадостите в криптографията, с които се сблъсках (колкото повече четеш, толкова повече атаки намираш, и толкова по-трудно е да се измисли несчупена система, а атаките са отвратителни), която май беше интересна за всички и някой ден може да напиша една по-подробна лекция за изминатия път до някой хубав дизайн (ако изобщо успеем да докараме такъв). От тоя ден има запис само на lightning talk-овете.

Най-хубавия елемент обаче си бяха разговорите – успяхме да говорим за какво ли не, да открия нови неща, да се измислят и счупят няколко дизайна около нашата криптография (с което май бая забавлявахме хората), изобщо, доста радващо беше, въпреки че бях супер уморен.

От лекциите мога да препоръчам:

“Storpool – Reinvent all the wheels” на Боян Кроснов (трябва да я направи в два часа);
Общество.бг на Димитър Димитров(lightning talk)
“СофтУни – докъде сме с проекта” на Светлин Наков (голямо шоу);
Maycamp arena на Валентин Михов – невероятно идеен и готин проект, силно препоръчвам;

Разходка през съвременния CPU pipeline на Борислав Станимиров – освен, че беше много добре описано, беше и ултра забавно, страхотна лекция за всички, които искат да разберат как работят модерните процесори;

…и като цяло да разгледате всичките лекции.

А от не-лекциите, Стефан жонглира.

За моята лекция ще пиша отделно (не се получи толкова добре, колкото исках, и ми се иска да кача пооправения текст).

(за “масонския” елемент, т.е. че беше invite only и пак някакви хора се оплакват, че не са поканени – нещастните от това хора могат да си организират собствена и да не ни канят)

Update: Явно много ми се е спяло снощи. Още няколко интересни неща:
Боби трябва да направи някой ден лекция с резултатите от трите мъжки въпроса, които задава;
Титов направи интересен кратък talk за linux fibers, в който за съжаления няма код, но е едно от по-забавните неща, които сме правили в последните няколко месеца;
Аз разказах на хората какво е ИББ и защо трябва да има повече такива събития;

2014-03-25 обява за работа

March 25th, 2014 by Vasil Kolev

(това може да го приемате и малко като спам)

Тия дни писахме една сравнително хубава обява за работа и я пуснахме в jobs.bg и stackoverflow. До тук няма кандидати, та въпросите ми са:

1) толкова ли е зле обявата?
2) хора ли няма, дето да отговарят?
3) На грешното място ли я пускаме?

Ако 2) е вярно, явно ще трябва да почна да правя деца и да ги уча…

2014-03-19 трева

March 19th, 2014 by Vasil Kolev

Има много изписано и изговорено на темата за тревата/марихуаната, наказуемост, полезност/вредност и т.н.. В последния проект за НК има някакви малоумия по темата, и понеже не ми се навлиза в спора, искам просто да споделя едно мое лично наблюдение.

Преди да ме оперират миналата година ме боля много. Стигнал бях до момента да не помага тегретола (в големи количества) и ми изписаха трамадол (опиат, от по-началната категория, но все пак на зелена рецепта), който помагаше и с който внимавах.

Опиатите са и много ефективни, и много опасни. Нямаме други толкова добри обезболяващи (дори оперативното прекъсване на нерви може да не е толкова ефективно), но от друга страна се стига до физическо пристрастяване и други неприятни странични ефекти.

Понеже не беше ясно дали операцията щеше да реши проблема (имаше шанс проблемът да не идва от артерията, която притискаше нерва, имаше шанс и да не се получи), реших да проверя дали все пак нямам някакъв друг резервен вариант, освен опиатното наркоманство. Един приятел ми намери малко трева от някакъв много успокояващ/отпускащ сорт и тествахме.

Нямаше особено отнасящ ефект, и не ме хвана по някакъв сериозен начин, но сложи една горна граница на болката – пробвах се да си предизвикам проблема, и не се получаваше стандартния каскаден ефект. Т.е. се оказа, че тревата в моя случай (на невропатична болка) е достатъчно добър заместител на опиатите, и определено подейства по-бързо от тях.

YMMV, на мен ми помогна. Бях планирал ако операцията не свърши работа, да редувам тревата и опиатите, така че да не привиквам към нито едното от двете, и си мисля, че ако имаше вариант докторите да я предписват на подобни случаи (доколкото знам, помага и на хора, болни от някакъв рак), светът щеше да е едно малко по-приятно място.

Update: Казаха ми, че все пак си ми личало, че съм бил пушил.

Update 2: Направо не мога да повярвам, българския съд е направил нещо добро по въпроса.

2014-03-19 ИББ на 26.03

March 19th, 2014 by Vasil Kolev

На 26.03 ИББ ще бъде в “Кривото” на НДК (вместо на “Дондуков”), поради ремонт. Ще са ни запазили маси и т.н..

Update: на 26ти МАРТ, не април.

2014-03-09 RailsGirls Sofia

March 9th, 2014 by Vasil Kolev

В последните два дни бях на RailsGirls Sofia (Kaladan е качил малко снимки).

Мисля, че се получи добре – игрите бяха интересни, lightning talk-овете също (Митьо обясни как можем да променяме света с програмиране, аз показах някакви дребни радости, Мариян показа идеята си за автоматизация на гардероб, Свилен показа двоично търсене с тесте карти и май другите не ги следих), а участничките, с които говорих после изглеждаха зарибени. Въпреки, че събитието е далеч от идеята ми за правилно преподаване на програмите, изглежда да си постига целта :)

Иначе, като малко бележки за бъдещи събития там (проведе се в академията на Телерик):

- да са по-разпръснати хората, че на моменти не се дишаше;
- да изберем по-свястно тиксо, че два часа махахме очертаните лабиринти от пода;
- wireless-ът им не издържа, или да добараме достъп да видим дали не може да се направи нещо, или да си носим наш;
- internet-ът им има странни филтрирани портове и много ми се искаше да им се добера до firewall-а с един конзолен кабел;

и извън това

- memento е твърде малко заведение за afterparty-то, освен ако не го запазим цялото. За малко да ме хване клаустрофобията вътре.

Иначе – това е N-тото нещо в последните няколко седмици, в което се набутвам и мисля да разкарам всичките си социални ангажименти за поне една седмица и да поработя на спокойствие.
Уморен съм.

2014-03-06 втори не-курс

March 6th, 2014 by Vasil Kolev

Преди няколко години направих един не-курс по системна администрация, чиято цел беше да даде на участниците опит, достатъчно близък до практическия. Работим по въпроса с Данчо и Леков да направим още един такъв тази година, с още по-забавни задачи (днес обсъждахме част от тях и бях обявен за извратен човек (за пореден път)), въпросът е има ли желаещи и колко ще са?

Ако ви се вижда интересна идеята, пуснете един коментар.

2014-03-02 спирт

March 2nd, 2014 by Vasil Kolev

(отдавна се каня да го напиша)

Преди някакво количество години бях решил да пробвам различни уискита (след като Велин поиска за една работа да му се плати с една бутилка Ardbeg, щото му беше станало интересно), бяхме седнали в един бар в студентски град (“Masterpiece”, имат огромна колекция), бяхме отворили wikipedia и гледахме статията за Islay. След като нямаха Laphroaig, ми сипаха един Lagavulin и аз толкова се влюбих в него, че в следващите дни си намерих доставчик на едро, и когато се изнасях от предната квартира открих, че имам около 1 куб. метър кутии от него.

С годините тествах различни неща и открих, че в крайна сметка човек след като мине на пушени уискита, другите не са му интересни. Също така по-трудно се попада на ментета, и от тях глава не боли (а съм изпивал бая…). Ето малко бележки по нещата, които съм пробвал, ако някой иска повече информация, Iain Banks е писал книга по темата – “Raw Spirit” (питали го “не искаш ли да обиколиш Шотландия, да пробваш всичките уискита и да напишеш книга, и той в първия момент си помислил, че се шегуват с него. Всички, на които казал после го питали дали не иска помощ…).

Пушените уискита идват основно от Islay в Шотландия (малък остров с малко хора и много алкохол). Това, което най-лесно може да се намери от там по нашите магазини е Lagavulin и Laphroaig. Аз съм тествал:

Ardbeg – много торфено и доста остро. Някои хора много го обичат, аз не толкова. Имам един Ardbeg Corryvreckan, който е доста по-мек и който е печелил уиски на годината преди 2-3 години, и се хареса доста на последния запой вкъщи.

Laphroaig – Хората се делят на два лагера, има такива, дето го харесват и такива, дето не (аз съм от вторите). Пак е доста остро, малко по-малко от Ardbeg-а.

Lagavulin – първото ми любимо уиски. По-меко от Ardbeg и Laphroaig, много опушено, с истински, пълен вкус. Много хора казват, че им мирише на терпентин/доктор/акварелни боички (за другите какво казват, не ми се ще да мисля), но като цяло за мен то е централния вкус на уискито от тоя остров. Води се май едно от най-опушените уискита там (като изключим някои неща като octomore).

Kilchoman – това е най-новата дистилерия на острова, и определено ми станаха новото любимо питие от там. Kilchoman machir bay има още по-приятен аромат от Lagavulin-а, пак е меко и като цяло се пие с голямо удоволствие.

Octomore е един странен експеримент на дистилерията Bruchladdich, направили са най-опушеното възможно уиски. Има мярка за опушеност, ppm (parts per millon) на фенолите, и Lagavulin е 45ppm, Octomore 3 е 152ppm. Има няколко версии, като моите любими са 3 и Comus (5 горе-долу ставаше, новите – 10 и т.н., вече не стават). Също така са по около 60 градуса и много точно може да усетите първата глътка как си прави път през вас.

Bruchladdich имат още много други различни неща, например едно Cuvee (неопушено), ама те искат още research от моя страна.

Горе-долу това са тези от Islay, които са ми били интересни. От опушените има още едно, което много ми хареса – Glen Els Ember – немско уиски, пушено на дърво, провах го на CCC конгреса миналата година, и което трябва да се намери начин да се внася в България.

Имам и някакво количество не-опушени неща, които държа основно за други хора – основно Cardhu, на което аз викам “дамско уиски”, щото го пият основно девойките, дето не харесват пушеците.

(за мен най-голямото предимство на това пиене е, че всъщност върши много хубава работа за борба с вътрешния ми алкохолзъм. Не мога да седна да пия ей-така, трябва да имам подходящото настроение и да ми се услади, усещам как в последните години съм започнал да пия много по-малко, отколкото преди)

2014-03-02 Sativa и Center

March 2nd, 2014 by Vasil Kolev

И пак имаше концерт на Sativa и Center в JetRock, като миналата година.

Силно размазващо, претовари ми се куфелния мускул. Sativa бяха приятни, Center луди, и накрая имаше половин час импровизация от музикантите от двете групи плюс още някакви (вкл. барабанистът на “Mental Architects”, които определено трябва да чуя). Може би ми е толкова весело, щото ми е разбъркан мозъка все още, но определено трябва това да го правят по-често :)
(миналата година импровизацията беше час и половина, ама нека да не бъдем алчни)

(питах, Sativa имали 4 записани и немиксирани парчета, та може някой ден да изкарат албум)

2014-02-27 DKIM

February 27th, 2014 by Vasil Kolev

Това чак не е интересно.

Ровейки един spam, който един приятел е получил, се загледах в DKIM подписите. Оказва се, че DKIM-а се лови от тривиално replay-ване, т.е.:

Правите си account на някое уважавано място (например gmail, в конкретния случай обаче е abv.bg). Пращате си mail до себе си, който ви генерира едни валидни подписи. Взимате цялото съобщение като source, един ваш smtp сървър, и го пращате на който си искате. От гледна точка на хората, уважавания доставчик е минал през вашия сървър и е пратил съвсем валидно писмо…

DKIM-а не знам кой го е мислил, но ето header-ите му:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out;
	t=1393422571; bh=4dLtPPWnymIO/8L0CLbvGZYxlQ5bZYMBimz0R/Li/JY=;

Превод в ефир: Ето мой подпис на ето тези полета, които съм си харесал, които са тривиални за фалшификация.

Това е толкова тривиално, че чак българските spamer-и го ползват. Чак се чудя дали това с валидния DKIM подпис е нарочно или просто така е станало…

Интересна работа. Имаме SPF (описване на валидни източници) и DKIM (подписване на header-и от валидните източници), и нямаме свястна комбинация от двата протокола, която ДА ВЪРШИ НЯКАКВА РАБОТА.
(и разбира се, ако сте с валиден DKIM подпис, gmail и разни други мърлячи ще показват в получения ви mail картинки от външни линкове. Ето как тривиално спамерите ще видят дали ви е верен/работещ/четен mail-а)

2014-02-23 крокодиловден

February 23rd, 2014 by Vasil Kolev

И стандартния post за празнуването на крокодиловден.
(празнувах на 22ри, щото 23ти е неделя и в понеделник никой нямаше да иде на работа)

Събрахме се, пихме, веселихме се, т.е. стандартното. Очаквах, че като ставам на 33 някой ще ми върне жеста и ще ми сковат кръст и т.н., но имаше само един чук и пирони…

Най-странния/интересен подарък е екскурзия до лагера в Аушвиц (не във влак с товарен вагон…). Чудя се все пак дали някои от хората не са мислели, че подаръкът е еднопосочен билет натам и че лагерът още оперира…

От останалите неща това, което мога да фокусирам:
Glenfidich 18, Glenfidich 12 и един Gentlemen Jack;
Един стар Sun сървър;
Един търмък и подобни инструменти за градина/user-и;
Надуваема овца, вазелин и т.н. (познайте от кого);
Тиган за палачинки (с идеята да каня хората, дето ми го подариха и да им готвя, оптимисти);

…и други. Като ми се спи малко по-малко, ще ги допиша.

Весело беше, догодина пак.