[c-nsp] CLNS/IS-IS routes

Mon Jan 14 09:16:15 EST 2013

I'm sorry to confuse you I thought there are more ALG routers

On ORA you can see that ALG originated and advertised 3 LSPs

I see you mentioned some LSPs are not being propagated I'm thinking maybe
some area discrepancy in the net id

Please note the 49.xxxx or 47.xxxx should be the same on all routers in the
layer-1 domain

Also it might be some routers along the path are layer-1-2 some are only
layer-1 or only layer-2 and that's where some of the LSPs might get lost

adam

From: Vincent De Keyzer [mailto:lamusiqueduhasard at gmail.com] 
Sent: Monday, January 14, 2013 11:31 AM
To: Adam Vitkovsky
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] CLNS/IS-IS routes

Hi Adam,

thanks for the quick answer.

About the "ES" role of the server: Alcatel confirmed that their servers
indeed need to be configured as ISes (which I agree sounds strange).

By "each of the Algiers", you mean that I should see "rtrnal01" more than
once in the list below, like "rtrmar01" and "rtralg01" do?

ORA1-R26-01#sh isis database         

IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
rtrmar01.00-00        0x00050D9D   0xB621        839               0/0/0
rtrmar01.02-00        0x000482EA   0x1347        805               0/0/0
rtralg01.00-00        0x0002B099   0x232F        907               0/0/0
rtralg01.01-00        0x0002A7B6   0xD280        1086              0/0/0
rtralg01.02-00        0x0002A82C   0x252D        581               0/0/0
rtrann01.00-00        0x00032484   0x422E        424               0/0/0
rtrann01.02-00        0x0003231C   0x804B        467               0/0/0
rtrmpf01.00-00        0x0003FB69   0xFBFA        959               0/0/0
rtrnal01.00-00        0x0003213A   0x04E1        1073              0/0/0
rtrnoc01.00-00        0x0004EEA4   0xDB58        765               0/0/0
rtrora01.00-00      * 0x0003B10D   0x2230        1105              0/0/0
(...)

Verbose detail :

rtrnal01.00-00        0x0003213A   0x04E1        897               0/0/0
  Area Address: 39.250f.8000.0000.0000.0001.0001
  Metric: 10         IS rtrann01.00
  Metric: 10         IS rtrora01.00
  Metric: 0          ES rtrnal01

So this is my issue: rtrnal01 is not sending the pseudonode LSP for the LAN
behind Et0/1?

How do I fix this?

Vincent

On 14 January 2013 10:24, Adam Vitkovsky <adam.vitkovsky at swan.sk> wrote:

>But Oran does not seem receive from Algiers any of its 6 CLNS neighbors
(and that includes the server):
I'd check the ISIS database on Oran to see whether it received an LSP from
each of the Algiers.
Than you can check for the verbose output to see whether the particular LSP
contains all interfaces.

Also you mentioned servers -shouldn't those run ES-IS with the routers?

adam
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Vincent De Keyzer
Sent: Monday, January 14, 2013 9:32 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] CLNS/IS-IS routes

Hello all,

We are currently troubleshooting an old, badly-documented, non-supported,
CLNS/IS-IS network (for management of Alcatel NEs).

One of the issues we have identified is IS-IS routes not being announced by
one router to another (this might or might not explain the overall problem
of no connectivity, but let's go step by step).

The two routers are ALGiers and ORAn, directly connected with a serial E1
link.

The adjacency looks good to me. Algiers correctly sees Oran (and has a CLNS
neighborship with the server we are interested in):

     ALG2-R26-01#sh clns ne

     System Id      Interface   SNPA                State  Holdtime  Type
Protocol

     0007.729E.FFEE Et0/1       0007.729e.ffee      Up     92        L1
IS-IS

     0007.72A2.FEA6 Et0/1       0007.72a2.fea6      Up     91        L1
IS-IS

     0020.602B.CBB4 Et0/1       0020.602b.cbb4      Up     95        L1
IS-IS

     0020.6013.2DD2 Et0/1       0020.604a.972e      Up     92        L1
IS-IS

-->  0030.6E4B.455C Et0/1       0011.85c7.3ec0      Up     97        L1
IS-IS  <----- Server

     0030.6E4B.47DB Et0/1       0012.799d.51a6      Up     95        L1
IS-IS

     rtrnoc01       Et0/1       0014.1ce6.60fd      Up     9         L1L2
IS-IS

     rtrann01       Se0/2       *PPP*               Up     24        L1L2
IS-IS

-->  rtrora01       Se0/3       *PPP*               Up     26        L1L2
IS-IS  <----- Oran router

     1880.F524.8FF0 Et0/1       1880.f52d.958e      Init   48        L1
IS-IS

     ALG2-R26-01#

Oran sees Algiers:

     ORA1-R26-01#sh clns ne

     System Id      Interface   SNPA                State  Holdtime  Type
Protocol

     0020.6013.37F2 Fa0/1       0020.6013.37f2      Up     96        L1
IS-IS

-->  rtrnal01       Se0/1/1:0   *PPP*               Up     24        L1L2
IS-IS  <----- Algiers router

     rtralg01       Se0/1/0:0   *PPP*               Up     28        L1L2
IS-IS

     0020.602B.CF8A Fa0/1       0020.602b.cf8a      Up     46        L1
IS-IS

     0080.9F20.0931 Fa0/1       0080.9f20.03a3      Up     93        L1
IS-IS

     ORA1-R26-01#

But Oran does not seem receive from Algiers any of its 6 CLNS neighbors (and
that includes the server):

     ORA1-R26-01#sh isis route | i 455C

     ORA1-R26-01#

(You might have noticed that the CLNS names are not consistent with the
hostnames, but CDP does confirm the situation

     ALG2-R26-01#sh cdp ne

     Device ID        Local Intrfce     Holdtme    Capability  Platform
Port ID

     ORA1-R26-01         Ser 0/3        163         R S I      Cisco
2801Ser 0/1/1:0

     (...)

)

All seven routers in the network have already been rebooted.

Any idea why this inconsistency, or on how to troubleshoot further?

Thanks,

Vincent
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/