Nikolay Abromov blog

Source: http://www.stevesouders.com/blog/2012/10/11/cache-is-king/ It’s important to understand where the benefits from each technique come into play. Using Ajax, for example, doesn’t make the initial page load time much faster (and often makes it slower if you’re not careful), but subsequent “pages” (user actions) are snappier. Optimizing JavaScript, on the other hand, makes both the first page view and subsequent pages faster. Better caching sits in the middle: The  very  first visit to a site isn’t faster, but subsequent page views are faster. Also, even after closing their browser the user gets a faster initial page when she returns to your site – so the performance benefit transcends browser sessions. These web performance optimizations aren’t mutually exclusive –  you should do them all!  But I (and perhaps you) wonder which has the biggest impact. So I decided to run a test to measure these different factors. I wanted to see the benefits on real we...

This will be a short post. Today is my last day in the company I was working for last one year and It's a bit sad leaving some great guys behind but at the same time I am really excited about the new opportunity I have.

source:    Petr Lapukhov Abstract This publication briefly covers the use of 3rd party next-hops in OSPF, RIP, EIGRP and BGP routing protocols. Common concepts are introduced and protocol-specific implementations are discussed. Basic understanding of the routing protocol function is required before reading this blog post. Overview Third-party next-hop concept appears only to distance vector protocol, or in the parts of the link-state protocols that exhibit distance-vector behavior. The idea is that a distance-vector update carries explicit next-hop value, which is used by receiving side, as opposed to the “implicit” next-hop calculated as the sending router’s address – the source address in the IP header carrying the routing update. Such “explicit” next-hop is called “third-party” next-hop IP address, allowing for pointing to a different next-hop, other than advertising router. Intitively, this is only possible if the advertising and receiving router are on a shared ...

http://www.mellanox.com/

reminder to read this article: http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/mcast-pim-rpt-spt-cutover.html

I got this strange behaviour where the IPv6 doesn't work correctly or not working at all on LT interfaces. http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/logical-systems-restrictions.html Logical systems have the following operations and restrictions: * You can configure only Frame Relay interface encapsulation on a logical tunnel interface ( lt- ) when it is configured with an IPv6 address. So if you are using Logical Systems on Juniper and you have to do IPv6 labs avoid encapsulation ethernet. Example root@jnlab# show interfaces {     lt-2/2/0 {         unit 46 {             encapsulation frame-relay;             dlci 100;             peer-unit 45;             family inet {                 address 172.27.0.58/30;             } ...

Configuring Node-Link Protection for OSPF You can configure node-link protection on any interface for which OSPF is enabled. Node-link protection establishes an alternate path through a different routing device altogether for all destination routes that traverse a protected interface. Node-link protection assumes that the entire routing device, or node, has failed. The Junos OS therefore calculates a backup path that avoids the primary next-hop routing device. Node-link protection is supported on: OSPFv2 and OSPFv3 interfaces OSPFv3 unicast realms OSPFv2 unicast topologies All routing instances supported by OSPFv2 and OSPFv3 Logical systems To configure node-link protection for an OSPF interface: Include the  node-link-protection  statement at the  [edit protocols (ospf | ospf3) area  area-id interface  interface-name ]  hierarchy level. Best Practice:  You must also configure a per-packet load-balancing routing policy to ensure t...