Val:~$ whoami

I am Val Glinskiy, network engineer specializing in data center networks. TIME magazine selected me as Person of the Year in 2006.

Search This Blog

Monday, June 22, 2009

JUNOS 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.

Friday, June 19, 2009

Last Error: PCALC:: No addresses to connect

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.