Two vendors, two OSPFs. Does this come as a surprise to you? No? Welcome to the club.

I was neglecting this blog for a while, more than 2 years actually. Well, things changed in my personal life, but this is out of scope for this whiteboard. Let me stick to networking stuff here.

I worked for an ISP as a network engineer for many years. I thought I knew so much about the protocols
— the networking fundamentals. Now I know I was just a network operator who was told how things should work. I was following the instructions, never doubting they were wrong or, at least, not the only way to go. Workshops, trainings, testing in LABs with a vendor equipment…, these thing make you a perfect engineer but they are not an eye opener. Yes, I now that MTU must match for OSPF, I know that nonzero OSPF area must be connected with a backbone…, I now many these things and for many I also know the reason behind it (yes, I have read the RFCs). But I’ve never questioned that, saying to myself, “it was designed that way.”

Moving to a design verification team of a vendor, where my daily job is to make sure that things work as designed, put me to another stand point. It is not about looking for bugs and bad implementation, it is about looking deeply into networking fundamentals and understanding the solutions. And there are many. People think their own ways and you can’t say they are wrong. Well, some solutions work better than others, some are more robust and less prone to errors and, yes, some are bad. But — there are many ways🙂.

I’m currently looking into OSPF implementations from a few vendors and I might report some findings here. You might be surprised that some details in OSPF can be understood in different ways by different vendors. Or not?

You might have been DoS-ed recently. And you can’t spend more money on special and expensive DoS detection and mitigation systems. Well, you have routers, don’t you? Some routing platforms support features which can be efficiently used to limit the impact of DoS attacks.

Let us take a brief look into one of these features on the Juniper MX gear. Read the rest of this entry »

Big sport events have great impact on Internet. Here is one of them…

When Slovenian skier Tina Maze is in action, routers at Slovenian Internet Exchange get hotter🙂. You can spot both of her runs in Sochi 2014 on the graphs below – mind the second spike, when Tina was soooo close to the bronze medal:





To make this post a little bit more technical: most of the traffic comes from Octoshape, UDP 8247.

Yes, it can be done by BGP. What was the question anyway?

Path hiding on a route server running BGP can happen if the route server has been configured to filter the chosen best path from reaching a particular route server client. Read the rest of this entry »

Disabling ICMP unreachable messages will break Path MTU discovery with legacy IP, that is IPv4.

Operators often disable generating ICMP unreachable messages in order to protect the router’s CPU. This technique to protect the router’s control plane is rather obsolete and dangerous. Namely, IPv4 router will use ICMP message type 3, code 4 (The datagram is too big. Packet fragmentation is required but the ‘don’t fragment’ (DF) flag is on.) to signal the sender that the packet he is sending is too big to forward and has to be fragmented. This is a crucial message in Path MTU discovery process for IPv4. By the way, in IPv6 this is not the case – the Packet too big ICMPv6 message is not of the “unreachable” kind. Read the rest of this entry »

Internet runs on BGP. Securing the BGP is the foundation for Internet routing security.

But it is not only the protocol we must take care of. BGP as an application is also vulnerable to various threats, like route manipulation and route hijacking. BGP will originate IP prefixes as it is being told to do. It is up to network administrators to mitigate the risk of BGP misusage or exploit attempts. Internet was ment to be a place for well-behaved, but, being enormous as it is today it can not be based on trust anymore. Internet resources, like autonomous system numbers (ASNs) and IP prefixes, must be given a validatable proof of holdership. This kind of proof can be given by Resource Certification systems. The resource certificates offers the basics for a secure Internet routing, particularly BGP route origin validation.
Read the rest of this entry »

Making long story about checking the IPv6 PMTU short, here is how you can check the Path MTU for a certain IPv6 destination in the cache:

ip -6 route get <address>


netstat -f inet6 -narlW | grep <address>

matjaz@macbook:~$ netstat -narWl -f inet6 | grep 2001:x:e813:
2001:x:e813:a00::d25      fe80::222:56ff:feba:21bf%en1    UGHW3Ii
         0        8   1400      en1   1378

sysctl -o net.inet.tcp.hostcache.list
(many thanks to Rui Paulo for this hint)

root@FreeBSD:~ # ping6 -m -s 5000 2001:xxxx:e813:a00::d25
PING6(5048=40+8+5000 bytes) 2001:xxxx:e811:b00:20c:29ff:fe78:31fb --> 2001:xxxx:e813:a00::d25
5008 bytes from 2001:xxxx:e813:a00::d25, icmp_seq=0 hlim=63 time=1.088 ms
5008 bytes from 2001:xxxx:e813:a00::d25, icmp_seq=1 hlim=63 time=0.903 ms
5008 bytes from 2001:xxxx:e813:a00::d25, icmp_seq=2 hlim=63 time=0.985 ms
--- 2001:xxxx:e813:a00::d25 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.903/0.992/1.088/0.076 ms

root@FreeBSD:~ # sysctl -o net.inet.tcp.hostcache.list
2001:xxxx:e813:a00::d25  1400        0      0ms      0ms         0        0        0        0   11    1 3600

netsh interface ipv6 show destinationcache


IPv6 ULAs have a global scope, so when it comes to a default address selection in IPv6, longest prefix match criteria is used to chose a proper source IPv6 address to speak with the remote site within the same (global) scope.

I’ve discussed scopes and zones in one of my recent posts. I’ve mentioned IPv6 ULA in that context which was somehow misleading and well spotted in a comment by Roger Wilco, saying “Strictly speaking, ULA have global scope, and so the scope and zone math shouldn’t be required to be able to explain why an IPv6 host can want to speak with a remote globally routed address from a local ULA.” Absolutely true! Read the rest of this entry »

To SLAAC or not to SLAAC – what will it be? I might vote for SLAAC, slightly modified and used with IPv6 First Hop Security (FHS) with built-in monitoring.

Looking for a perfect solution for local IPv6 addressing which is stable, secure and private enough as well as easy to monitor? Read the rest of this entry »

When it comes to ULA, IPv6 gurus get nervous. Some hear NAT, and NAT is the most disgusting word in IPv6 vocabulary.

Well, ULA is not to be NAT-ed (look for Ivan’s ipSpace posts about ULA for more know-how), it can be used in a much smarter way – it can provide an internal connectivity in case when a site gets isolated from its basic networking services like DHCPv6, for example. Yes, these things can happen. Read the rest of this entry »