Archives for category: cisco ios

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 »

Using Cisco ACLs to match routing prefixes or just to mystify the configuration?

A decade ago route classification or filtering in Cisco IOS was commonly done with the help of access control lists (ACLs). You will still find this method in some (very) old configurations and Cisco trainings (no matter how advanced they are ;-)). I’ve run into this legacy stuff recently and I was forced once again to understand how it works. It is confusing but rather simple.

An entry in the extended IPv4 ACL has the following meaning:

permit|deny ip <network> <wildcard mask of network> <subnet mask> <wildcard mask of subnet mask>

The “source” part of the rule selects the prefixes and the “destination” part selects prefix masks (prefix lengths). 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 »

Rarely used feature, but it might come in handy.

In the following scenario a service provider AS 1 has a customer which is using a private AS 65000 within his network. The customer has just received their own AS number and they are planning to migrate from the private one. Theirs intention is to introduce the new AS gradually and keep the old peerings with the private AS up and running during the migration.
What a customer needs is a feature that will allow a router to replace their own AS number with another one in the eBGP updates.
Read the rest of this entry »

Multiple OSPF processes with mixed network statements can really mess things up! Fortunately, there is a better way to assign an interface into an OSPF area.

I’ve discussed overlapping OSPF network statements in one of my earlier posts. In the a “pre-IPv6-era” we were taught to use network statements in the OSPF stanza to assign the interfaces to a certain OSPF area. This configuration

interface Vlan100
  ip address
router ospf 1
  passive-interface default
  no passive-interface Vlan100
  network area 1

…enables OSPF process on the interface Vlan100 and assigns that interface to OSPF area 1.
What happens if one uses multiple and overlapping networks statements in order to assign interfaces into different areas? 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 »

It is very common to isolate some special services into virtual private networks of some kind and provide only limited connectivity to these services from the outer world. Can this be done on a single box? Not without tricks 😉 .

Let’s face the following scenario. Autonomous systems A (blue on the right) and B (green on the left) decide to share services via a dedicated high-speed/low-latency/super-duper link (see green link on the picture below). They form a “servers VPN” which guarantees superb connectivity between servers A and B. But, what if the big green link fails? Read the rest of this entry »

Router software is facing a new era with IPv6. Some of the methods, which worked perfectly well for v4, were not updated for v6 and they silently ignore the new IP protocol. Ignorance might be a bliss, but not in routing software.

Apply this policy on your Cisco gear to all IPv4 prefixes present in the BGP routing table for IPv4 (show bgp ipv4 unicast route-map IgnoranceIsBliss):

ipv6 prefix-list MatchSomeV6 permit 2001:678:4::/48
route-map IgnoranceIsBliss permit 10
 match ipv6 address prefix-list MatchSomeV6
 set community 2107:12345
route-map IgnoranceIsBliss deny 20

… or this one on your Juniper router (test policy IgnoranceIsBliss 0/0 will do the job):

[edit policy-options]
prefix-list MatchSomeV6 {
community Test12345 members 2107:12345;
policy-statement IgnoranceIsBliss {
    term Match6 {
        from {
            prefix-list MatchSomeV6;
        then {
            community set Test12345;
    term DenyOther {
        then reject;

The policy is telling you: “set community for some IPv6 prefixes that match certain criteria and don’t mess with others”. One would expect that all IPv4 prefixes will be ignored by that policy, since they do not match the criteria in any of the terms. Not true on a Cisco router (I’ve verified this on 6500, 3560/3750 and 7200 running some decently up-to-date IOS) – match ipv6 address prefix-list catched all IPv4 prefixes and the community was set for them according to the route-map. JUNOS, however, passed the test – none of the IPv4 prefixes matched the IPv6 criteria.

As always, do not trust the damn machines!