Archives for category: testing

ping6 can be a useful tool in troubleshooting MTU-related issues. Being IPv6 network operators we must known how it actually works with IPv6 in relation to fragmentation. Take you time and inspect the ping behaviour on your system and find a way how to examine your IPv6 destination cache. The know-how you will gain might come handy sometimes.

Troubleshooting MTU-related issues is a common task in IP network operations, IPv6 being no exception. A simple tool like ping is often used to discover MTU on the path between two hosts. When it comes to IPv6, fragmentation no longer happens in the network but only at the hosts. Hence, host (a sender) must be informed about the MTU for a certain destination. This is, of course, done by the routers on the path, which use ICMPv6 packet-too-big messages to inform the sender that packet is too big to dispatch. Hopefully these messages, which include the reduced MTU value, are received by the sender. This allows the sender to store the reduced MTU values in its IPv6 destination cache for a certain period of time. Read the rest of this entry »

Advertisements

A very simple and lightweight ping/traceroute-capable host for your GNS3 LAB. Nice to have!

I’ve been using GN3/Dynamips occasionally to verify ideas in IP routing implemented with Cisco IOS. Whenever I needed to simulate a host within my setups I’ve used routers with IP routing disabled. However, this is a total waste of CPU which is rather valuable resource in a laptop-based GNS3 environment like mine. A simple and very lightweight PC simulator called VPCS comes very handy in situations where ping and traceroute are all you basically need to test your design and network behaviour. Read the rest of this entry »

NAT is dead, long live NAT64! Well, just not for too long, OK?

It seems that implementation of some kind of IPv6 Transition Mechanisms is inevitable. IPv4 address space shortage will force many to use the networking evil – NAT. Stateful NAT64, accompanied by DNS64, looks very promising for well-behaved TCP/UDP services. The beauty of the beast comes from the fact that this type of transition technology is designed to fade away as native IPv6 is being fully deployed. Finally, it can be simply shutdown and decommissioned when most of the old IPv4-only servers are gone. Read the rest of this entry »

Once again it is obvious that there is no free lunch. Not even in networking technology. Saving money on routers and interfaces is often accompanied by reduced performance.

Here I was discussing a solution of a simple problem – how to forward traffic between a global router (GRT) and a VRF within a single box with some constraints:

  • systems in the VRF must also reach directly connected networks in the GRT
  • there is no BGP information about directly connected networks in the GRT, therefore VRF route leaking with BGP is not an option
  • no extra routers can be used
  • no additional ports can be used

GRE tunnels came to the rescue :-). Read the rest of this entry »

“Penny wise, pound foolish”, you might say about the proposal to use internal GRE tunnel to forward traffic between global router (GRT) and a virtual one within the same physical device. Well, it works well to a certain extent – performance is being halved but money for interface ports well saved.

We want to achieve the following:

  • traffic between servers A and servers B will use the green direct path between AS A and AS B
  • no other traffic must follow this green path
  • servers A and servers B will communicate via dashed backup path via internet in case the green path fails
  • servers A communicate with all other clients via blue paths and internet
  • servers A can only use router A for the gateway
  • no additional physical interfaces on router A can be used

Read the rest of this entry »


Vem, da sem pametnejši od usmerjevalnega protokola.

 

Če se ukvarjate z IP-omrežji, ste zagotovo že naleteli na nekaj takega:

router2>show ip route 10.0.0.255
% Subnet not in table

Zakaj “Subnet not in table?“, saj ste prepričani, da mora usmerjevalnik (router2) poznati pot do IP-naslova (v našem primeru 10.0.0.255).
Na nekaj podobnega sem naletel pred kratkim.

V omrežju treh zaporedno povezanih usmerjevalnikov želim obremeniti povezavo med usmerjevalnikoma router2 in router3. Prvi (router1) bo izvor prometa.


Read the rest of this entry »