Pavel Stefanov’s Blog

Позволих си да преведа тази статия, защото много ме накефи.

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

The Pirate Bay track-ва около 1 милион торенти и 8 милиона peer-и по всяко време. Това е доста голяма промяна в сравнение с миналата година и няма никакъв знак, че тази тенденция ще спре в близко бъдеще.

Декември 2006

576 080 торенти
4 274 698 peers

Декември 2007

914 717 торенти
8 390 682 peers

За да може да отговори на изискванията на потребителите си, The Pirate Bay е добавил още hardware към server farm-а си. Друга значима промяна е преминаването от Anakata’s Hypercube към open-source Opentracker software. Новият software e по-стабилен, използва по-малко ресурси и поддържа UDP tracking.

Brokep от TPB казва, че те ще могат да поемат 2 пъти повече peers на тракерите си без никакви hardware upgrades.”От последния ни performance и router tuning премахнахме всичките bottlenecks.” Също така, според него броят на peer-ите ще достигне 10 million през следващия голям празник.

Уви, тези добри новини са и резултат и от разширяването на TPB, поради проблемите, които имаха Demonoid тази година и това, че IsoHunt (TorrentBox) забрани достъпа на американци до тракерите им, заради проблемите, които имаха с MPAA.

Demonoid и TorrentBox бяха съответно 2-рият и 4-тият най-използвани Bittorent тракери и това беше голяма загуба. Изчислено е че приблизително 50% от всички публични торент файлове се track-ват от TPB и е немислимо да си представим какви би станало, ако TPB тракерите спрат да работят.

За щастие има и добри новини, след като тракери като sumotracker.org и denis.stalker.h3q.com станаха доста известни само за няколко месеца, които заедно track-ват около 1 милион peer-и. Освен това, TPB обявиха, че възнамеряват да си останат най-големият тракер и просто да се преместят в някоя друга държава, ако използването на торенти в Швеция се забрани.

Просто не мога да се накефя на тия пичове. Respect. Правят за смях всички големи компании-машини за пари. Слушах няколко interview-та на хора, които бачкат за TPB и просто ме убедиха, че от морална гледна точка са абсолютно прави. Way to go, Guys! Ето и един линк, където ще откриете писма и отговори от най-големите компании, които са правили опити да накарат TPB да махнат торенти с тяхно съдържание. Вземете си пуканки и кола, и се размажете от смях :)

От близо месец започнах работа в една нова ИТ компания у нас – Bulgarian Association for New Technologies (Българска Асоциация за Нови Технологии), която се занимава най-вече със IT trainings & education, а също така и със системна интеграция. Можете да видите малко повече инфо за компанията на www.bant-bg.org. За само няколко месеца успяхме да станем Premier Partner на Cisco и Registered Partner на Microsoft. Аз работя като Field Engineer и ще ставам даскал as well :) – Cisco Networking Academy Instructor.

Та днес ми беше първият изпит, откакто започнах работа в БАНТ – 642-382 Cisco Express Foundation for Field Engineers. Голям смях падна – 1000/1000 score. По едно време реших да си разцъкам SDM-а, защото ми стана супер забавно да чета глупости. Много секюрити и wireless, и много тъпи cisco-mind въпроси. Използвах Video training в Cisco PEC-а (aka Сиско ПЕЦ :)). Та отсега официално съм Field Engineer :) Сега се колебая дали да не взема composite-а за CCNP – най-вероятно ще ми се наложи, за да мога да преподавам CCNP courses някой хубав ден.

Отдавна се каня да напиша няколко думи за начина на мислене на българина. Напоследък се изумявам, че ми се правят забележки или ме гледат странно, все едно съм паднал от Марс, когато реша да си изкажа мнението по определен въпрос или попитам нещо, за което никой не се е замислял. Изключително много се дразня на хора, които мислят, че мнението им няма значение. Та нали държавата това сме ние – хората, ние избираме тези, които ни управляват, защо да не давам своето мнение и идеи? Това ми прилича на типичния по социалистическото време у нас начин на мислене – stay passive, мълчи си, не мисли за каквато и да е била промяна, оставяй останалите да ти промият мозъка. Аз наричам този начин на живот “живуркане”.

Единственият начин за improvement (или както искате го наречете, аз се стремя към това поне :)) е именно чрез даване на нови идеи, поставяне под въпрос и преразглеждане на остарялото. Пример. Защо съм бил питал “Добре турците са ни държали под робство 5 века, ами българите не са ли проявявали жестокост спрямо останалите народи?”. Искам да знам истината, а не да оставям да бъда манипулиран. Защо съм питал този и онзи “Това има ли някакво практическо приложение? Според вас това нужно ли ми е?” Колкото повече питам “Защо?” и/или “Защо не?, толкова по-лесно си изграждам обективно мнение. Така че вместо следващия да си малчиш, по-добре е да изкаваш мнението си без никакви задръжки и да знаеш, че то има някакво значение…

Just my 2 cents

I started writing notes at the beginning of my CCIE Lab preparation. I finished reading Internet Routing Architectures by Sam Halabi a couple of weeks ago and I did some thorough labs that explained some details about BGP that you cannot find in books or at least you will have to do a lot of searching on the net to find more information. Anyway, here are some notes that I made during my labs:

• The Metric of IGP/connected interface/static route is automatically mapped to MED, when sent to eBGP neighbors.
• Oldest BGP route is used for selection for only eBGP routes received from a different BGP router ID.
• The closest IGP neighbor step in the BGP selection algorithm is also valid for eBGP routes, not only for iBGP routes.
• Metric (the IGP metric to the neighbor) is not shown when the neighbor is directly connected.
• When comparing routes according to the closest IGP neighbor, the router does not care about which routing protocol is used to learn about the route, the metrics are compared anyway (for instance, RIP metric 2 is preferred over OSPF metric 3).
• It is not possible to set the local-preference for an eBGP peer (it is possible to apply such a route-map but that does not affect the routes that are sent).
• It is possible to set the local preference to incoming eBGP routes and influence the BGP selection process. The local preference is therefore shown in the BGP table (it is not shown if we have not explicitly set the local preference).
• In the AGGREGATOR attribute the RID (not an interface ip address used for peering) is included.
• When we use the AS_SET attribute, AS numbers are either put in the AS_SEQ or AS_SET, but not in both attributes (when aggregating routes).
• A null0 route is always put when we use the BGP aggregate-address command. We can replace this route with a static route (as with EIGRP, but cannot remove that route from the table unlike with EIGRP).
• The ATOMIC_AGGREGATE is not included in the path attributes when we use the AS_SET attribute. We put the AGGREGATOR attribute even if we use the AS_SET attribute.
• Private AS numbers can be removed only when sending updates from the next-to-the-private AS. If you have a private as between two public AS numbers (for instance, 1 65001 6), there’s no way you can remove the 65001 (at least with the remove-private-as command).
• There’s no problem reaching the BGP next-hop via another BGP route (unlike, for instance, with type 5 LSAs- external routes).
• You’re not allowed to use match interface route-map command for BGP updates (you’re given an error message).
• You cannot prepend AS numbers when sending updates to iBGP neighbors.
• Cisco IOS does not allow you to change the attributes of routes when it is route-reflecting updates.
• Dampened paths are removed from the RIB and are neither used nor advertised.
• Change in attributes as well as withdrawn/advertised routes are counted as flaps (change in attributes – 500 penalty, widthdrawn/advertised route – 1000 penalty).
• There’s no way not to include the aggregator attribute in aggregate routes.
• Beware when using ACLs for matching routes! You cannot have an exact match with standard ACLs, you have to use extended ACLs.
• When you use the network command without the mask keyword, ALWAYS use the classful network with 0s in the don’t care bits in the classful mask (for instance, network 99.1.1.1 won’t inject 90.0.0.0, actually it won’t inject anything).
• The ORIGINATOR_ID is set to the RID of the peer that advertised the route to us (we are a RR). The ORIGINATOR_ID is preserved and is not changed when sent to other RR clusters. The CLUSTER_LIST contains the CLUSTER_IDs of all RR cluster the route has already traversed.
• You don’t have to configure anything in order to match anything in a route-map statement.
• When you use the network command, the BGP route has next-hop set to the next-hop used to reach that route (not 0.0.0.0) and is not changed when sent to iBGP neighbors as usual.
• MED is also sent to iBGP peers when we originate a route using the redistribute or network command.
• BGP sends updates back to the originating AS via another router (for instance, R1 – > R2, R2 – > R3, R3 -> R4, where R1 and R4 are in AS 1, and R2 and R3 are in AS 2).
• There’s no way to override the AS_PATH or remove AS numbers from it (except for private AS numbers).
• You cannot configure the router not to include the AGGREGATOR attribute within Cisco IOS.
• There’s no problem to aggregate an already aggregated route that contains atomic_aggregate and/or aggregator attributes.
• When you use the as-set keyword in the aggregate-address command, the as-set is not used unless there are route from more than one AS received from the aggregator. The as-set keyword however makes the route inheret other path attributes.
• You have to explicitly configure send-community in order to send any community attributes for both locally originated routes and received routes that already have the community attribute set.
• If you don’t use the as-set keyword, path attributes from the routes that form the aggregate are not inherited by the aggregate route.
• 0.0.0.0/0 BGP route cannot be redistributed into OSPF.
• If a BGP route is not in the RIB (even if it is the best route), it cannot be redistributed.
• If you have suppressed some routes (summary-only or some other aggregate-address command) and then use the unsuppress-map for an individual peer, the route is still shown as suppressed in the BGP table (although it is shown that it is advertised to a specific peer if you use show ip bgp x.x.x.x).