Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!

Why is RIP still kicking?

One of my readers called RIP “Rest in Piece” routing. Although it’s probably the routing protocol that dinosaurs used to find their way around, it’s still useful in modern networks. Imagine that you have to deploy hundreds (or thousands) of low-cost remote sites with dual uplink capability (for backup purposes). They could be automated kiosks, point-of-sale terminals or even ATM machines.
If you’re infinitely lucky (and have huge budget), you could afford an ISR router at each location and use different design options that Cisco IOS gives you. In most cases, you have to work with devices that barely know what routing is … but you still need dynamic routing protocol to give them the ability to detect primary route failure and switch over to the backup route.

Assuming your purchasing department didn’t buy boxes that don’t have enough memory to run OSPF, you could usually choose between RIP and OSPF as the routing protocol … and I would always select RIP in this scenario. Let’s start with the “management-level” arguments: RIP is simpler to design (there is almost nothing to design) and troubleshoot than OSPF. It uses less memory and CPU cycles and I would also expect low-end boxes to have fewer bugs in RIP than in OSPF. More in-depth arguments are coming in the follow-up post.
Add comment

Enhance the traceroute output

After working with MPLS Traffic Engineering lab for a few days and interpreting IP addresses from various traceroute outputs, I finally had enough and wrote a simple Perl script that parses router configurations and produces ip host configuration commands for every interface IP address it encounters. When you paste the ip host commands into the configuration of the edge router from which you do the tests, the meaningless numbers finally make sense.

Just compare the “traditional” output produced in the MPLS TE test lab

PE-A#traceroute PE-C

Type escape sequence to abort.
Tracing the route to PE-C (10.0.1.5)

  1 10.0.7.6 [MPLS: Label 1017 Exp 0] 16 msec 136 msec 52 msec
  2 10.0.7.26 [MPLS: Label 3018 Exp 0] 8 msec 20 msec 8 msec
  3 10.0.7.30 [MPLS: Label 4018 Exp 0] 16 msec 20 msec 56 msec
  4 10.0.7.33 [MPLS: Label 2017 Exp 0] 20 msec 44 msec 20 msec
  5 10.0.7.17 24 msec *  24 msec

… with this one:

PE-A#traceroute PE-C

Type escape sequence to abort.
Tracing the route to PE-C (10.0.1.5)

  1 Serial1-0.C1 (10.0.7.6) [MPLS: Label 1017 Exp 0] 56 msec
  2 Serial1-2.C3 (10.0.7.26) [MPLS: Label 3018 Exp 0] 12 msec
  3 Serial1-1.C4 (10.0.7.30) [MPLS: Label 4018 Exp 0] 48 msec
  4 Serial1-2.C2 (10.0.7.33) [MPLS: Label 2017 Exp 0] 52 msec
  5 Serial1-0.PE-C (10.0.7.17) 16 msec *  64 msec

see 3 comments

Multilink bundles have varying bandwidth

I have always intuitively assumed that the interface bandwidth on MLPPP bundles is the sum of interface bandwidths of individual interfaces that are part of the bundle. Recently I’ve tested my assumption and it works as expected.

For example, with the following interface setup …

interface Multilink1
 ip unnumbered Loopback0
 ppp multilink
 ppp multilink group 1
!
interface Serial1/4
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
!
interface Serial1/5
 bandwidth 4000
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
 serial restart-delay 0

… the bandwidth of the Multilink1 interface is 6000 kbps if both serial lines are up …

Rtr#show interface Multilink 1 | inc protocol|BW
Multilink1 is up, line protocol is up
  MTU 1500 bytes, BW 6000 Kbit, DLY 20000 usec,

… but drops to 4000 kbps when the Serial1/4 is disconnected:

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/4, →
changed state to down Rtr#show interface Multilink 1 | inc protocol|BW Multilink1 is up, line protocol is up MTU 1500 bytes, BW 4000 Kbit, DLY 20000 usec,
see 6 comments

Do you need LDP with MPLS TE?

An anonymous commenter to my implicit NULL/PHP post made a very valid point:

Most Cisco documentation states that you must enable LDP before doing MPLS-TE, which is a complete fallacy.

If you're using MPLS TE simply to shift IP traffic around your network, he's absolutely right: there is no need to run LDP if you have an IP-only network. If you're running MPLS VPN or BGP on edges/MPLS in the core, the answer becomes “it depends.” The detailed rules and undesired side effects if you ignore them are summarized in the MPLS Traffic Engineering in MPLS VPN environment article.

Read the article in CT3 wiki.

see 4 comments

Load balancing quirks

One of my readers has noted an interesting load-balancing behavior: when he was running traceroute tests from various routers in a topology similar to the one displayed below, the traceroute outputs indicated per-packet load balancing (both paths were used) when they were initiated from R2 or R3, but used a single path when initiated from R1 or R4.
 
The reason for this behavior is very simple: if you do traceroute from R1 to R4, R2 and R3 perform CEF switching, which usually does load balancing based on source-destination IP address pairs, so all probe packets from R1 to R4 travel along the same path. If you start traceroute from R2 or R3, the packets are process-switched on the first hop (from R2 to R3, for example) and thus alternate between the parallel links.

This article is part of You've asked for it series.

see 5 comments

MPLS TE: If you want standard compliance, you have to ask nicely

In a comment to my post describing the role of implicit NULL in LDP, an anonymous commenter complained about lack of Cisco’s standard compliance in MPLS TE tunnel setup process. Time for packet capture and Wireshark :). The tests were performed on the MPLS TE network I’ve used to illustrate MPLS troubleshooting with LSP ping; packets were captured on the link between C4 and C2 (the penultimate hop and the tunnel tail-end) at the time when the MPLS TE tunnel was established from C1 to C2. In all tests, an ICMP Echo Request packet was sent over the tunnel to verify whether C4 performed PHP or used an MPLS shim header on the last hop of the tunnel.

With the default settings, C2 signaled that C4 should use explicit NULL (label = 0), but C2 performed PHP (which is the usual action the penultimate hop of an MPLS TE tunnel should do). The wireshark decodes are shown below (note that C4 sends the ICMP packet traversing the tunnel without the MPLS shim header, indicating that it performed PHP):

Frame 1 (212 bytes on wire, 212 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
Resource ReserVation Protocol (RSVP): PATH Message.
    RSVP Header. PATH Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.34
    TIME VALUES: 30000 ms
    EXPLICIT ROUTE: IPv4 10.0.7.33, IPv4 10.0.1.7
    LABEL REQUEST: Basic: L3PID: IP (0x0800)
    SESSION ATTRIBUTE: SetupPrio 7, HoldPrio 7, SE Style,  [C1_t0]
    SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 13. 
    SENDER TSPEC: IntServ: Token Bucket, 62500 bytes/sec. 
    ADSPEC

Frame 2 (132 bytes on wire, 132 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.7.33 (10.0.7.33), Dst: 10.0.7.34 (10.0.7.34)
Resource ReserVation Protocol (RSVP): RESV Message. 
    RSVP Header. RESV Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.33
    TIME VALUES: 30000 ms
    STYLE: Shared-Explicit (18)
    FLOWSPEC: Controlled Load: Token Bucket, 62500 bytes/sec. 
    FILTERSPEC: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 13. 
    LABEL: 0

Frame 3 (104 bytes on wire, 104 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 100
    Identification: 0x0000 (0)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 253
    Protocol: ICMP (0x01)
    Header checksum: 0xa78f [correct]
    Source: 10.0.1.3 (10.0.1.3)
    Destination: 10.0.1.7 (10.0.1.7)
Internet Control Message Protocol

When the penultimate hop is a more compliant router, it uses the explicit NULL in the MPLS header to encapsulate the ICMP packet, resulting in potential problems on C2 (according to RFC 3032, the whole label stack should be discarded when an explicit NULL is encountered).

If you want C2 to behave in a more standard-compliant way, you have to ask nicely with the mpls traffic-eng signalling advertise implicit-null global configuration command. You can use an access list with this command to indicate which neighbors need standard-compliant signaling. The access list should be used if you have a mix of neighbors that interpret the explicit NULL the way it should be interpreted and older IOS devices that could be confused by the implicit NULL label in the RSVP RESV message.

Anyhow, after mpls traffic-eng signalling advertise implicit-null has been configured on C2, the RSVP RESV message used implicit NULL label (Label = 3):

Frame 1 (212 bytes on wire, 212 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
Resource ReserVation Protocol (RSVP): PATH Message. 
    RSVP Header. PATH Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.34
    TIME VALUES: 30000 ms
    EXPLICIT ROUTE: IPv4 10.0.7.33, IPv4 10.0.1.7
    LABEL REQUEST: Basic: L3PID: IP (0x0800)
    SESSION ATTRIBUTE: SetupPrio 7, HoldPrio 7, SE Style,  [C1_t0]
    SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 16. 
    SENDER TSPEC: IntServ: Token Bucket, 62500 bytes/sec. 
    ADSPEC

Frame 2 (132 bytes on wire, 132 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.7.33 (10.0.7.33), Dst: 10.0.7.34 (10.0.7.34)
Resource ReserVation Protocol (RSVP): RESV Message.
    RSVP Header. RESV Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.33
    TIME VALUES: 30000 ms
    STYLE: Shared-Explicit (18)
    FLOWSPEC: Controlled Load: Token Bucket, 62500 bytes/sec. 
    FILTERSPEC: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 16. 
    LABEL: 3

Frame 3 (104 bytes on wire, 104 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 100
    Identification: 0x000a (10)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 253
    Protocol: ICMP (0x01)
    Header checksum: 0xa785 [correct]
    Source: 10.0.1.3 (10.0.1.3)
    Destination: 10.0.1.7 (10.0.1.7)
Internet Control Message Protocol

This article is part of You've asked for it series.

see 3 comments

Knowledge or recipes?

I've always believed that you need to teach your students (more so if they are engineers) how things work, so they'll be able to understand why they do things they way they do them. It seems to me, though, that the training courses I'm seeing veer ever more toward overviews and recipes ... but there are a few things you can do on your own.

read more see 3 comments

Interesting links | 2008-09-21

The blogosphere is amazing: I was complaining about lack of posts a week ago, but the last days were a real bonanza:
see 1 comments

Implementing IOS Network Security remote labs

The Implementing IOS Network Security (IINS) is a pretty new entry-level (it's part of CCNA Security) course that covers several IOS security features (including SDM, AAA, zone-based firewall, site-to-site VPN, IPS). If you need extra hands-on practice while preparing for the exam, the newly released IINS remote labs are a perfect solution.
Add comment

Quick tip: display interface bandwidth

To display bandwidths of all interfaces configured on the router use show interface | include protocol|BW command.

Here is a sample printout:

Rtr#show interface | include protocol|BW
FastEthernet0/0 is administratively down, line protocol is down
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
Serial1/0 is up, line protocol is up
  MTU 1500 bytes, BW 2000 Kbit, DLY 20000 usec,
Serial1/1 is up, line protocol is up
  MTU 1500 bytes, BW 2000 Kbit, DLY 20000 usec,
Serial1/2 is up, line protocol is up
  MTU 1500 bytes, BW 2000 Kbit, DLY 20000 usec,
Serial1/3 is administratively down, line protocol is down
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
Loopback0 is up, line protocol is up
  MTU 1514 bytes, BW 8000000 Kbit, DLY 5000 usec,

You could define an alias to create a new IOS command generating this printout (for example, alias exec bw show interface | include protocol|BW). You could also write a simple Tcl script that would accept an interface name and display the bandwidth of that interface.

see 7 comments

PE-to-PE troubleshooting in MPLS VPN networks

End-to-end troubleshooting of MPLS VPN solutions is one of the more complex network troubleshooting tasks, as the MPLS VPN solutions involve several sophisticated technologies and protocols, as well as customer-to-provider interaction, which makes the troubleshooting efforts even more convoluted (did I just write this ... maybe I could survive in corporate marketing world after all :). To segment the overall MPLS VPN solution into troubleshooting domains, you might start with PE-to-PE troubleshooting to remove the potential impact of customer errors, intra-site customer routing, PE-CE interactions and route redistribution issues.
Add comment

External default route in an OSPF NSSA area

We all know that you have to use the default-information originate router configuration command if you want to advertise an external default route into an OSPF domain ... unless the router from which you want to advertise the default route resides in an NSSA area. The default-information originate command does not work within an NSSA area.

Read the full article in the CT3 wiki.

Add comment

Interesting links | 2008-09-14

It looks like everyone has better things to do after the summer holidays than providing free content to the blogosphere. The only really interesting post I found was Colin McNamara's response to my DMZ VLAN post, in which he looks at the much bigger picture: it's not only the switching infrastructure we're sharing; in the virtualization rush, we're sharing memory, disks, interfaces and even firewalls.
see 2 comments

Quick tip: display interface IP addresses

To display IP addresses assigned to router’s interfaces (excluding interfaces with no IP address) use show ip interface brief | exclude unassigned command.

Here is a sample printout:

C1#show ip int brief | excl unassigned  
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.16.0.1      YES NVRAM  up                    up      
Serial1/0                  10.0.7.17       YES NVRAM  up                    up      
Loopback0                  10.0.1.1        YES NVRAM  up                    up      
Tunnel0                    192.168.0.1     YES manual up                    up      

You could define an alias to create a new IOS command generating this printout, for example, alias exec ipconfig show ip interface brief | exclude unassigned.

Add comment

Default routing in NSSA area

The RFC 3101 (OSPF NSSA Option) states:
In addition, an NSSA border router should originate a default LSA (IP network is 0.0.0.0/0) into the NSSA. Default routes are necessary because NSSAs do not receive full routing information and must have a default route in order to route to AS-external destinations.
I am pretty sure that IOS inserted the type-7 default route into an NSSA area when the NSSA feature was introduced. Today (at least in IOS release 12.4, 12.4T and 12.2S) you have to configure the type-7 default route origination explicitly with the area nssa default-information-originate router configuration command, in which you can also specify the route metric and metric type (N1 or N2). Entering the area xx nssa without the default-information-originate keyword will result in an NSSA area with no connectivity to external destinations redistributed into OSPF in other areas.

You can find more information on OSPF default route behavior in the IP Corner article The OSPF Default Mysteries.

Add comment

Are VLANs safe in DMZ environment?

The Thinking problem management! blog had an interesting article on The Leaky VLANs myth, quoting a test report from SANS Institute that documents how you can inject frames into other VLANs even if you're not connected to a trunk port. The report is eight years old (so one would hope this issue has been fixed in the meantime), but there's another question you should ask yourself is: what happens when you lose the configuration of the switch (and I've seen devices losing configuration after a power glitch). If you're using a router to perform L3 switching, no harm is done; a router with empty configuration forwards no packets. But if you're using a low-end switch, you're in deep trouble; by default, a switch forwards packets between all ports ... and if you use static IP addresses on all subnets, you won't even notice they're connected. If you want to be very safe, you're better off having a different set of switches for the inside and the outside zones of your firewall.
see 7 comments

Disable the wireless interface during the night

A friend has recently asked me for a solution that would disable the wireless interface on his SOHO router during the night. Two simple EEM applets later we had it working; I've also added a third applet to ensure the interface does not remain disabled after a router reload.
see 13 comments

Secure Time Management

The April IP Corner article It’s good to be on time described how you can use Network Time Protocol (NTP) to synchronize the real-time clock of your network devices with external time references. As soon as you start relying on your routers having pretty exact time, NTP becomes part of your mission-critical network infrastructure and has to be protected protected against intruders or impostors.

Default NTP settings on Cisco IOS allow intruders to change the router’s time or even current year as soon as the router is not synchronized directly with a primary (stratum 1) NTP server. In the Secure Time Management article, I'm describing a very simple NTP attack on an unprotected network and the safeguards you can put in place to prevent similar attacks.
Add comment

Using network 0.0.0.0 with RIP

According to Cisco IOS documentation, the network RIP router configuration command accepts a major network number (without subnets) as its parameter. The common wisdom says that you have to list all major networks attached to your router if you want to run RIP on all interfaces. You could get the same results by using network 0.0.0.0 router configuration command.
see 3 comments

Some DHCP clients do not use Client identifier option

A while ago I've documented how you can cope with DHCP clients that do not send Client identifier (DHCP option 61) in their DHCP Discover/Request messages, but some people are still trying to persuade me that the client-identifier pool configuration command should work. I really wanted to be sure I hadn't missed something, so I started Wireshark and captured the actual DHCP Discover packet generated by a Linux host:
 
As you can see, the DHCP packet does not contain the Client identifier option, so the DHCP server (the router) has nothing to compare the value of the client-identifier parameter with. The only parameter the DHCP server can use is the Client MAC address field in the DHCP Discover message, which is matched with the mac-address pool configuration command.
In contrast to the default Linux behavior, DHCP Discover messages generated by other platforms (for example, Windows or a Cisco router) include the Client identifier option:
 
see 1 comments

BGP route aggregation: followup

A week ago I've asked whether anyone has a good use for BGP aggregation. Out of 1300 daily visitors of my blog and 2200 subscribers to the RSS feed,  four (4) people found the time and energy to reply. Thank you for your thoughts!

Let me conclude that BGP aggregation is not widely used (so I will spend much energy covering it in my future posts) ... all the other potential conclusions are too pessimistic.
Add comment

Practical BGP-based hijack/man-in-the-middle attack

One of the presentations at the recent Defcon 16 event demonstrated how you can use the very common laziness of the Internet Service Providers to hijack any prefix you want (just ask YouTube). Nothing new so far, but the part where they fake the AS path in the hijacked announcement to create a safe (hijack-free) conduit back to the destination is brilliant ... and the TTL manipulation is the icing on the cake.

Of course this is a well-known BGP vulnerability (actually, implementation sloppiness on the part of ISPs) that we've been writing about for a long time, but the Defcon presentation is probably the first documented step-by-step recipe for a realistic MITM attack.

Hat tip to Jeremy Stretch; I found the link to the Defcon presentation on his blog.

Add comment

Send e-mail after a router reload

In previous posts, I’ve explained how you can use the SYS-5-RESTART syslog message to detect router reloads and execute commands (for example, fix router configuration or enable debugging) right after the reload. If you want to perform actions that require network connectivity (for example, send an e-mail when a router is reloaded), you cannot execute them right away, as the routing protocols might not have converged yet (in our example, the e-mail server might not be reachable).

You can use the timer countdown event to execute an EEM applet within a fixed delay after the reload. When the router is reloaded, all EEM applets stored in the startup configuration are registered and the one-time countdown timer will fire after the specified time.

For example, to execute an EEM applet that will send an e-mail twenty seconds after the router reload, you could use this configuration:

hostname test
!
service timestamps debug uptime
service timestamps log uptime
!
event manager applet ReloadNotify 
 event timer countdown name Delay time 20
 action 1.0 info type routername
 action 1.1 mail server "mail.example.com" →
   to "[email protected]" from "[email protected]" →
   subject "Router reload: $_info_routername"
 action 1.01.2 syslog msg "E-mail was sent"

After the router is reloaded, the following syslog messages are generated (the exact timing might vary):

00:00:20: %SYS-5-CONFIG_I: Configured from memory by console 00:00:21: %SYS-5-RESTART: System restarted -- 00:00:21: %SNMP-5-COLDSTART: SNMP agent on host c7200 is undergoing a cold start 00:00:40: %HA_EM-6-LOG: ReloadNotify: E-mail was sent
see 16 comments
Sidebar