aviate, navigate, communicate

bgp w labie

dawno dawno temu, zabawa z BGP (samo nieco ironiczne tłumaczenie tego akronimu jako Bardzo Groźny Protokół zdaje się zdradzać w którą stronę podąża ten akapit) była zdecydowanie zarezerwowana dla wtajemniczonych tego świata, którzy nieco jak Lemowski Trurl i Klapaucjusz naśmiewali się z niewiedzy, ale z drugiej strony sami tą wiedzą się nie dzielili. potem zmieniło się wiele, opary w jaskiniach wiedzy nieco się rozrzedziły, pojawiły się kursy, certyfikacje, elitarne a potem masowe kursy - i nagle BGP ma w domu każda gospodyni domowa, gdyż bez niego nie wrzuci sobie via bluetooth nowego kontaktu do komórki. Read more →

gigabits per second thanks to GPU

i was writing about such ideas over two years ago. it seems the concept of offloading packet forwarding from CPU to GPU may have some merits, and if you’re interested in that - take a look at packetshader page. still however, hardware config needed to achieve that kind of performance feat is quite expensive. it demonstrates however that GPU, next to FPGA experiments, can also be viable way forward for PC based packet forwarding/routing. Read more →

1941w and its configuration…

…doesn’t have to be totally banal. it’s much more performant (300kpps, around the NPE300 performance from 7200!), so i upgraded my home 1803w to 1941w. as there are no readily available examples for complete config of the router (wired + WLAN), I decided to take the case in my hands and produce some examples. you may find them here. Read more →

after plnog #4

nie wypada mi komentować prezentacji kolegów z Cisco ani swojej :), ale wartą podkreślenia rzeczą jest uczestnictwo operatorów i integratorów, którzy opowiadali o swoich doświadczeniach - Piotra Strzyżewskiego(platformy open source vs rozwiązania komercyjne), Przemysława Frasunka(sieci CDN) czy Piotra Wojciechowskiego(o NAT-PT). biorąc pod uwagę zainteresowanie i komentarze, właśnie o takie sesje Wam chodziło. następny PLNOGjuż we wrześniu. zapraszamy! plnog, plnog and… after plnog. it looks like we have actually grown into the most serious and largest independent conference dedicated to people working on service provider networks in Poland - though I’m not going to fight anyone on the number of participants, this additional 100 people on each subsequent edition of PLNOG (in this we counted 395 participants! Read more →

ip sla and shell scripting

i had a problem yesterday - i needed to generate at least a dozen packets per second minimum between two connected devices (without ability to insert PC or traffic generator between them - that was Catalyst 3550 and 4900M). traffic needed to be exchanged over a time frame of several hours, so ping from console line wasn’t feasible either. the solution was pretty straightfoward - IP SLA. as Catalyst 4900M was to be under test, on Catalyst 3550 i created two VRFs: Read more →


during previous PLNOG we’ve had a broad discussion about apocalyptic vision of depleting IPv4 and 2-byte space. some time ago Cisco IOS 12.4(24)T was released, and it brings 4-byte ASN feature for ISR (1800/2800/3800) and 7200 routers. so if you’re using Cisco gear, you can request 4 byte ASN using RIPE form, and then advertising it properly (starting from 1st of January, 2009 RIPE will by default hand out 4 byte ASNs). Read more →

ccie service provider

i came back yesterday from Brussels and today at 5:30am the verdict is - definitely “PASS :) so… let me share some advice and tips for those of you preparing to take CCIE SP practical exam (without breaking NDA of course). first of all - if you have that luxury of training on any software version - please try to check with the current Cisco page and align. software is quite “specific”, and you may be hit with interesting behavior that may be a little bit different from the newer versions. Read more →

10Gbps… and so on

on the network throughput front, we’re fighting (albeit in distributed manner) for getting throughput on par with dedicated, hardware routing platforms - from commodity PC hardware, working on Linux and BSD. as for that, recent document published after last Linux Congress in Hamburg shows that while it’s important to select proper multi-core CPU and motherboard to do fast traffic forwarding, we’re still hitting bottleneck at around 1Mpps. curiously enough, on one of the slides you can spot information, that large FIB in Linux doesn’t impact performance too much. Read more →