*NIX as a second language

Juniper was kind enough to post "JUNOS As A Second Language" e-learning course aimed at network administrators familiar with Cisco IOS. As somebody who works in production environment I could not help but notice how easy it is to revert changes in JUNOS with "commit confirmed" command.
Well, it turns out that IOS 12.4 has similar feature with "configure replace". From Cisco documentation:

Configuration Rollback Confirmed Change

The Configuration Rollback Confirmed Change feature enables an added criteria of a confirmation to configuration changes. This functionality enables a rollback to occur if a confirmation of the requested changes is not received in a configured time frame. Command failures can also be configured to trigger a configuration rollback.

The following steps outline how this process is achieved:

1. When entering configuration mode, this new option allows you to request confirmation (a confirmation time limit must be supplied) of the configuration changes.

2. After exiting configuration mode, you must enter the confirmation command. If no confirmation is entered within the requested time limit, the configuration will revert to its previous state.

configure replace target-url [nolock] [list] [force] [ignorecase] [revert trigger [error] [timer minutes] | time minutes]

It might come in handy next time when you change IP address on the wrong interface or make mistake in ACL.
Disclaimer: I strongly advise that you have console server with out-of-band access connected to all your critical production routers.

Labels: Network management

Ever since I passed "Implementing Cisco MPLS" (642-611) exam, I've been aching to try my hands at MPLS TE. So, here is the task:




Click on image to see bigger version.

Since R2-R4 link is T3, OSPF will pick R2-R3-R5 path from R1 to either R6 or R7 leaving R2-R4-R5 link underutilized. At the same time I know that traffic from R1 to 10.0.0.0/24 is going to low enough to fit comfortably into T3 link. I wanted to create explicit path tunnel R1-R2-R4-R5-R7 with backup dynamic tunnel. I am going to skip configuration part - there are more then enough examples on the 'Net.
Let's see if tunnel is up

R1#sho mpls traffic-eng tunnels

Name: 6503sw2_t0 (Tunnel0) Destination: 192.168.1.4
Status:
Admin: up Oper: down Path: not valid Signalling: Down path option 1, type explicit mypath

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled

History:
Tunnel:
Time since created: 20 hours, 1 minutes
Time since path change: 3 minutes, 24 seconds
Number of LSP IDs (Tun_Instances) used: 334
Prior LSP:
ID: path option 1 [309]
Removal Trigger: path option removed
Last Error: PCALC:: No addresses to connect 172.16.0.14 to 172.16.0.10

Not good. Searching for this type of error message gives one sage advise:

For cases involving an explicit path option, you can try to narrow down the problem by first checking every hop in the explicit hop list. You can also try to back down the tunnel: Move the tail one hop back each time to see if the tunnel comes up. If the tunnel comes up when you move the tail to a previous hop, you can conclude that there is a problem between that hop and the next hop, and you can start scrutinizing that hop carefully.

And so I did. Let's see how R2 and R5 see R4:

R2# show ip rsvp neighbor
Neighbor Encapsulation Time since msg rcvd/sent
172.16.0.18 Raw IP 00:02:12 00:02:10
172.16.0.21 Raw IP 00:02:10 00:02:23


R5#show ip rsvp neighbor
Neighbor Encapsulation Time since msg rcvd/sent
172.16.0.1 Raw IP 00:03:59 00:04:18
172.16.0.6 Raw IP 00:04:16 00:03:59

Hmm, they do not see R4 as RSVP neighbor at all. What's going on on R4?

R4# sho ip rsvp interface detail gi 0/0
Gi0/0:
Interface State: Up
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 30M bits/sec
Max. allowed (per flow): 30M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Number of missed refresh messages: 4
Refresh interval: 30
Authentication: disabled

How does it compare with R4-facing interface on R5?

R5#sho ip rsvp interface detail gi 0/2

Gi0/2:
RSVP: Enabled
Interface State: Up
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 40M bits/sec
Max. allowed (per flow): 40M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON via CEF callbacks
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled
Key chain:
Type: md5
Window size: 1
Challenge: disabled
Hello Extension:
State: Disabled

"RSVP: Enabled" string is missing in R4 command output. After some research I found that I need "T" type IOS to run RSVP-TE on R4 which is Cisco 3825.
Let's see what we have after the upgrade:

R4#sho ip rsvp interface detail gi 0/0

Gi0/0:
RSVP: Enabled
Interface State: Up
Bandwidth:
Curr allocated: 5M bits/sec
Max. allowed (total): 30M bits/sec
Max. allowed (per flow): 30M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled
Key chain:
Type: md5
Window size: 1
Challenge: disabled
Hello Extension:
State: Disabled

and tunnel:

R1#sho mpls traffic-eng tunnels bri
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3042 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 42 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
6503sw2_t0 192.168.1.4 - Gi2/1 up/up

Much better. Confirm routing

R1#sho ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via "ospf 100", distance 110, metric 14, type intra area
Last update from 192.168.1.4 on Tunnel0, 19:41:13 ago
Routing Descriptor Blocks:
* 192.168.1.4, from 192.168.1.4, 19:41:13 ago, via Tunnel0
Route metric is 14, traffic share count is 1

Now, since MPLS TE tunnel is unidirectional, I need to create R7-R5-R4-R2-R1 tunnel as well.

Labels: Cisco, Troubleshooting

Yesterday I passed "Implementing Cisco MPLS" (642-611) exam. That was last one for me to complete CCIP certification process. I want to share my "CCIP reading list":

Routing TCP/IP, Volume 1 (2nd Edition)(CCIE Professional Development)






Routing TCP/IP, Volume II (CCIE Professional Development)








BGP Design and Implementation






Cisco QOS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition)






MPLS Fundamentals







The list is not exclusive. In addition to that I used Cisco's command reference guide and IOS documentation on Cisco's website and built small lab to practice. I also tried using exam simulators like RealExams, a.k.a. Pass4Sure, a.k.a. TestKing. Actually, I am not sure if it is the same company or they steal from each other, but simulators' content is almost identical and I found all of them to be waste of money - ridden with errors and outdated. For 642-611 exam, I tried Bosons Software simulator. This one was of much better quality, but turned out to be too easy to be a good help for MPLS exam preparation. Even if you manage to achieve 80-90% accuracy in this simulator, your real exam score won't be high enough to pass.

Labels: Certification

1.3.6.1.4.1.3224.4.1.1.1.27.X shows what Netscreen thinks latency (in ms) is through IPSec tunnel number X. See my old post on how to find tunnel number.

Here is another one. How much data was transferred via policy number Y.

1.3.6.1.4.1.3224.10.2.1.6.Y.0
Beware, it reports in Bytes/sec. In order to make it work, you'll have to configure policy with "count" option.

Labels: Monitoring, Netscreen, Network management

Yesterday I passed "Implementing Cisco QoS" exam 642-642. I need to pass 642-611 "Implementing Cisco MPLS" to complete CCIP certification.

I have Cisco7604 with SUP720 running c7600rsp72043-ipservicesk9-mz.122-33.SRD.bin. Cisco's SNMP object navigator claims that this image supports RFC1213-MIB which has ipRouteTable. In reality here is what I got

~$ snmpwalk -v2c -c public [myrouter] ipRouteDest
RFC1213-MIB::ipRouteDest = No Such Object available on this agent at this OID

After "Asking" around, I found RFC2096, that states:

The ipForwardTable updates the RFC 1213 ipRouteTable to display multipath IP Routes. This is in turn obsoleted by the ipCidrRouteTable.

The ipCidrRouteTable updates the RFC 1213 ipRouteTable to display multipath IP Routes having the same network number but differing network masks.


ipCidrRouteTable is actually supported by my IOS image, even though Cisco's SNMP object navigator declares it "depricated" and recommends using inetCidrRouteTable (1.3.6.1.2.1.4.24.7)

~$ snmpwalk -v2c -c public [myrouter] inetCidrRouteTable
IP-FORWARD-MIB::inetCidrRouteTable = No Such Object available on this agent at this OID


No luck again, but ipCidrRouteTable (numeric 1.3.6.1.2.1.4.24.4) works just fine.

Here is the list of the objects in ipCidrRouteTable
ipCidrRouteTable 1.3.6.1.2.1.4.24.4
ipCidrRouteEntry 1.3.6.1.2.1.4.24.4.1
ipCidrRouteDest 1.3.6.1.2.1.4.24.4.1.1
ipCidrRouteNextHopAS 1.3.6.1.2.1.4.24.4.1.10
ipCidrRouteMetric1 1.3.6.1.2.1.4.24.4.1.11
ipCidrRouteMetric2 1.3.6.1.2.1.4.24.4.1.12
ipCidrRouteMetric3 1.3.6.1.2.1.4.24.4.1.13
ipCidrRouteMetric4 1.3.6.1.2.1.4.24.4.1.14
ipCidrRouteMetric5 1.3.6.1.2.1.4.24.4.1.15
ipCidrRouteStatus 1.3.6.1.2.1.4.24.4.1.16
ipCidrRouteMask 1.3.6.1.2.1.4.24.4.1.2
ipCidrRouteTos 1.3.6.1.2.1.4.24.4.1.3
ipCidrRouteNextHop 1.3.6.1.2.1.4.24.4.1.4
ipCidrRouteIfIndex 1.3.6.1.2.1.4.24.4.1.5
ipCidrRouteType 1.3.6.1.2.1.4.24.4.1.6
ipCidrRouteProto 1.3.6.1.2.1.4.24.4.1.7
ipCidrRouteAge 1.3.6.1.2.1.4.24.4.1.8
ipCidrRouteInfo 1.3.6.1.2.1.4.24.4.1.9

If you run BGP and accept all routes from the internet, it might be useful to watch the size of your routing table. ipCidrRouteNumber (1.3.6.1.2.1.4.24.3)does just that. If you want to graph it in Cacti use 1.3.6.1.2.1.4.24.3.0 For some reason Cacti needs .0 in the end

Labels: Network management

This is what I call really bad cabling.



©AP Photo/Bela Szandelszky