Friday 16 December 2016

MD5 failed cisco 6509

22:31:44.950 UTC: %TCP-6-BADAUTH: No MD5 digest from 10.10.10.1(646) to 10.10.10.2 (29167) (RST) tableid - 0

sometimes we received this error in the log

After troubleshoot  we found the hash is the same in both sides,.so our other option
check if error is related to same interfaces this will point to the module .

sh int gi4/0/0 and sh int gi4/0/1 we found there is not traffic in that interfaces

so the next step if check if there was any fail in the ASIC or inidication of any fault in the module

we can do sh diag module  number (in this case 4)

so the action recomended is

procedure to reboot a module in cisco

#hw-module module number reset

other
config t
config)# no power enable module number

test>>> sh diag module number
sh module




Thursday 8 December 2016

upgrade your IOS in cisco, FTP, verify, and boot variable

Today we will comment about something simple that sometime we don't remember and we have to go back to the reference.

This is one small example we use a  CAT4506e, where I was unable to setup the ssh , because it was not available in the IOs originally.

So in this example we will upgrade the IOS using a ftp server that we have access using the inband connection, we will see , how to check the image that we just download , then how to tell the system to use that image. 
setup of the ftp in the CLI

cisco#configt
cisco(config)#ip ftp username lab
cisco(config)#ip ftp password 7 060D0E2F595AC
cisco(config )#end

then we use 
 #copy ftp:/IOS/filename bootflash: <cr>
the system will ask for ip of the server  copy ip of the server
ask for name of the destination file <the same propose

 see example
cisco(config)#   
cisco#
*Dec  8 14:09:55.873 UTC: %SYS-5-CONFIG_I: Configured from console by console
cisco#$OS/cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin bootflash:  
Address or name of remote host []? 172.19.249.117
Destination filename [cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin]?
Accessing ftp://172.19.249.117//IOS/cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin...
Loading /IOS/cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[OK - 126060564/4096 bytes]

126060564 bytes copied in 148.648 secs (848047 bytes/sec)
cisco#
cisco#verify /md5 bootflash: (filename )
cisco#$ bootflash:cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin   
........................................................................................................................................................................
...........................................................................................................................................................................
............................................................................................................................................................................
...........................................................................................................................................................................
............................................................................................................................................................................
..........................................................................................................................................................................
.........................................................................................................................................................................
Done!
verify /md5 (bootflash:cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin) = c5a3c8c690150799089aa1bd024c6ac8
this number can be obtained to compare from cisco, when you buy the license , sometime if you check in google will appear .

 then we will have to check what is the boot variable


before was 

BOOT variable = ;bootflash:cat4500e-universal.SPA.03.08.01.E.152-4.E1.bin,1;
CONFIG_FILE variable does not exist
BOOTLDR variable does not exist
Configuration register is 0x2102

cisco#
after we enter 
 cisco#(config )boot system flash bootflash:cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin
config # 

show bootvar 
 BOOT variable = bootflash:cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin,1;bootflash:cat4500e-universal.SPA.03.08.01.E.152-4.E1.bin,1;
CONFIG_FILE variable does not exist
BOOTLDR variable does not exist
Configuration register is 0x2102
we will see two image 

we have to tell the system what will be the first 
to be sure 

do sh run 
 we will see 
in the newer IOS when there is multiple option to boot 
we will see something like this 

boot-start-marker
boot system flash bootflash:cat4500e-universalk9.SPA.03.04.04.SG.151-2.SG4.bin
boot system flash bootflash:cat4500e-universal.SPA.03.08.01.E.152-4.E1.bin
boot-end-marker

also remember 
with sh version to check the register 
should be 0x2102

 for more information please check a good reference 
https://www.safaribooksonline.com/library/view/cisco-ios-cookbook/0596527225/ch01s08.html
and cisco  as usually 

regards
 

Reload in cisco at or in

Reload in cisco could be useful for testing when we enter a command and we are testing and to fix an issue.

Today we will see how to to schedule a reload

The reload command permits to schedule a reboot system; for instance, to plan a night router restart or during a critical configuration (AAA, vty, and so on…).
There are two ways to schedule a reload system:
  • at: at a specific time/date
  • in: after a time interval
The ‘at’ keyword permits to schedule a reload of the software to take place at the specified time (using a 24-hour clock). If you specify the month and day, the reload is scheduled to take place at the specified time and date.
The following example reloads the router on April 30 at 3:00 a.m.:
Cisco#reload at 03:00 30 apr
Reload scheduled for 03:00:00 UTC Sat Apr 30 2011 (in 42 hours and 10 minutes) by console
Reload reason: Reload Command
Proceed with reload? [confirm]
Cisco#
Cisco#show reload
Reload scheduled for 03:00:00 UTC Sat Apr 30 2011 (in 42 hours and 10 minutes) by console
Reload reason: Reload Command
Cisco#
The ‘in’ keyword permits to schedule a reload of the software to take effect in the specified minutes or hours and minutes.
The followind example reloads the router in 90 minutes:
Cisco#reload in 1:30
Reload scheduled for 10:20:49 UTC Thu Apr 28 2011 (in 1 hour and 30 minutes) by console
Reload reason: Reload Command
Proceed with reload? [confirm]
Cisco#
 
regards
 

Tuesday 22 March 2016

TLV packet EIGRP

The IP header of the EIGRP packet specifies IP protocol number 88 within it, and the maximum length of the packet will be the IP MTU of the interface on which it is transmitted, most of the time 1500 octets. Following the IP header is the various Type/Length/Value (TLV) triplets. These TLVs will not only carry the route entries but also provide fields for the management of the DUAL process, multicast sequencing, and IOS software versions from the router.

EIGRP sends updates and other information between routers using multicast packets to
224.0.0.10. For example in the topology below, R1 made a change in the topology and it
needs to send updates to R2 & R3. It sends multicast packets to EIGRP multicast address
224.0.0.10. Both R2 & R3 can receive the updates and acknowledge back to R1 using
unicast. Simple, right?
But what if R1 sends out updates, only R2 replies but R3 never does? In the case a router
sends out a multicast packet that must be reliable delivered (like in this case), an EIGRP
process will wait until the RTO (retransmission timeout) period has passed before
beginning a recovery action. This period is calculated from the SRTT (smooth round-trip
time). After R1 sends out updates it will wait for this period to expire. Then it makes a list of
all the neighbors from which it did not receive an Acknowledgement (ACK). Next it sends
out a packet telling these routers stop listening to multicast until they are been notified that
it is safe again. Finally the router will begin sending unicast packets with the information to
the routers that didn’t answer, continuing until they are caught up. In our example the
process will be like this:
1. R1 sends out updates to 224.0.0.10
2. R2 responds but R3 does not

3. R1 waits for the RTO period to expire
4. R1 then sends out an unreliable-multicast packet, called a sequence TLV (Type-Length-
Value) packet, which tells R3 not to listen to multicast packets any more
5. R1 continues sending any other muticast traffic it has and delivering all traffic, using
unicast to R3, until it acknowledges all the packets
6. Once R3 has caught up, R1 will send another sequence TLV, telling R3 to begin
listening to multicast again.
The sequence TLV packet contains a list of the nodes that should not listen to multicast
packets while the recovery takes place. But notice that the TLV packet in step 6 does not
contain any nodes in the list.
Note. In the case R3 still does not reply in step 4, R1 will attempt to retransmit the unicast
16 times or continue to retransmit until the hold time for the neighbor in question expires.
After this time, R1 will declare a retransmission limit exceeded error and will reset the
neighbor.

OSPF P bit

When external routing information is imported into an NSSA, LSA Type 7 is generated by
the ASBR and it is flooded within that area only. To further distribute the external
information, type 7 LSA is translated into type 5 LSA at the NSSA border. The P-bit in LSA
Type 7 field indicates whether the type 7 LSA should be translated. This P-bit is
automatically set by the NSSA ABR (also the Forwarding Address (FA) is copied from Type
7 LSA). The P-bit is not set only when the NSSA ASBR and NSSA ABR are the same
router for the area. If bit P = 0, then the NSSA ABR must not translate this LSA into Type 5.
The nssa-only keyword instructs the device to instigate Type-7 LSA with cleared P-bit,
thereby, preventing LSA translation to Type 5 on NSSA ABR device.
Note. If a router is attached to another AS and is also an NSSA ABR, it may originate a
both a type-5 and a type-7 LSA for the same network. The type-5 LSA will be flooded to the
backbone and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be
reset (P=0) in the type-7 LSA so the type-7 LSA isn’t again translated into a type-5 LSA by
another NSSA ABR.

ISIS

reference thanks to  https://mellowd.co.uk/ccie/?p=5487

Basic LSPs

In OSPF we use the term LSA, Link-State Advertisement. In IS-IS we use the term LSP – Link-State PDUs. Further expanded into Link-State Protocol Data Units. Not to be confused with Label Switched Paths.
This is the topology we’ll start with:
IS-IS-1
Like OSPF, IS-IS will treat ethernet links as broadcast by default. In OSPF a DR and BDR will be elected. In IS-IS a single DIS (Designated Intermediate System) is elected with no backup DIS. This DIS election is also pre-emtptive, unlike OSPF. The DIS will originate an LSP representing the DIS. This means I should have three LSPs in the database currently:
RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 17:34:21.594 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x00000003   0x8577        736             0/0/0
XR1.01-00             0x00000002   0x1fba        931             0/0/0
XR2.00-00             0x00000005   0x856b        806             0/0/0

 Total Level-2 LSP count: 3     Local Level-2 LSP count: 1
XR2 has a single LSP with XR1 has two. The XR1.01 LSP is the DIS LSP. Dig deeper into the LSPs to see their current content:
RP/0/0/CPU0:XR1#show isis database XR1.00-00 detail
Tue Wed 12 17:38:23.307 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x00000003   0x8577        494             0/0/0
  Area Address: 49.0001
  NLPID:        0xcc
  Hostname:     XR1
  IP Address:   1.1.1.1
  Metric: 10         IS XR1.01
  Metric: 10         IP 1.1.1.1/32
  Metric: 10         IP 10.0.12.0/24
XR1 has originated an LSP stating what area it’s in and hostname. Notice the NLPID value. This means Network Layer Protocol IDentifier. The value of 0xcc translates to IPv4. Further down the LSP contains the IS of XR1 itself, plus two IP ranges. All these with metrics to those IS and IPs. I’ll get onto the ATT/P/OL bits later so ignore those for now.
It’s important to note that an LSP is made up of several TLVs. On the wire multiple TLVs can be grouped together in a single frame. If large enough, IS-IS will fragment these frames.
As XR1 is the DIS, there is a separate DIS LSP, let’s take a look at that:
RP/0/0/CPU0:XR1#show isis database XR1.01-00 detail
Tue Aug 12 17:43:00.448 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.01-00             0x00000003   0x1dbb        1161            0/0/0
  Metric: 0          IS XR1.00
  Metric: 0          IS XR2.00
The DIS LSP advertises all the IS’ that are on the segment in which the DIS sits.
If I change the segment to point-to-point, this removes the need of a DIS and as such there will be no DIS LSP.
router isis 1
!
 interface GigabitEthernet0/0/0/1
  point-to-point
RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 18:46:50.566 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x0000000b   0x7480        674             0/0/0
XR2.00-00             0x0000000d   0x5297        543             0/0/0

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1

Externals

I’m going to add another loopback interface on XR1 and redistribute that loopback into IS-IS. This will make the route external
interface Loopback100
 ipv4 address 100.100.100.100 255.255.255.255
!
prefix-set LOOPBACK100
  100.100.100.100/32
end-set
!
route-policy RP-100
  if destination in LOOPBACK100 then
    done
  else
    drop
  endif
end-policy
!
router isis 1
 address-family ipv4 unicast
  redistribute connected level-2 route-policy RP-100
As I mentioned above, IS-IS has separate TLVs that make up the LSP. Therefore there is still only a single LSP from XR1:
RP/0/0/CPU0:XR2#sh isis database
Tue Aug 12 19:03:31.569 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00             0x0000000d   0x6be5        1043            0/0/0
XR2.00-00           * 0x00000010   0x9c8f        1094            0/0/0

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1
The external route can be seen in the detailed output under that LSP:
RP/0/0/CPU0:XR2#sh isis database XR1.00-00 detail
Tue Aug 12 19:03:58.637 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00             0x0000000d   0x6be5        1016            0/0/0
  Area Address: 49.0001
  NLPID:        0xcc
  Hostname:     XR1
  IP Address:   1.1.1.1
  Metric: 10         IS XR2.00
  Metric: 10         IP 1.1.1.1/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 0          IP-External 100.100.100.100/32

Inter-Area

XR3 has now been added to the topology. I’ve had to move XR2 into the same area as XR3 otherwise they will not be able to form a L1 adjacency:
IS-IS-2
the R2-R3 link has not been changed to point-to-point, and as such I would expect to see three LSPs in XR3s database:
RP/0/0/CPU0:XR3#show isis database
Tue Aug 12 09:44:40.660 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000008   0xd230        1107            1/0/0
XR3.00-00           * 0x00000008   0xf1be        1105            0/0/0
XR3.07-00             0x00000003   0xfcd3        1105            0/0/0

 Total Level-1 LSP count: 3     Local Level-1 LSP count: 1
If you look at XR2’s L1 LSP in detail you now see the ATT bit set. Also note it’s advertising only it’s directly connected interfaces:
RP/0/0/CPU0:XR3#show isis database XR2.00-00 detail
Tue Aug 12 19:45:51.025 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000008   0xd230        1037            1/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  Hostname:     XR2
  IP Address:   2.2.2.2
  Metric: 10         IS XR3.07
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
XR2 has set the ATT bit which is the attached bit. An L1/L2 router will set this bit in the LSP inside the L1 area it’s connected to. This is to inform the L1 routers that it is attached to the L2 domain. No actual default route is advertised, but L1 routers can create their own defaults pointing towards the attached routers:
RP/0/0/CPU0:XR3#sh ip route 0.0.0.0
Tue Aug 12 19:47:07.839 UTC

Routing entry for 0.0.0.0/0
  Known via "isis 1", distance 115, metric 10, candidate default path, type level-1
  Installed Aug 12 19:43:09.476 for 00:03:58
  Routing Descriptor Blocks
    10.0.23.2, from 2.2.2.2, via GigabitEthernet0/0/0/0.23
      Route metric is 10
  No advertising protos.
Notice from XR1’s persepctive, that any routes coming from an L1 area is simple flooded from the L1/L2 router as normal routes:
RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail
Tue Aug 12 19:50:08.676 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x0000001b   0x5b3d        778             0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  Hostname:     XR2
  IP Address:   2.2.2.2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 20         IP 3.3.3.3/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
IS-IS gives you the ability to leak L2 prefixes into the L1 domain. This is handy when you have two L1/L2 border routers and want to engineer destiations to go on particular paths. From XR2 I’ll leak XR1’s loopback into the L1 domain. The database now shows:
RP/0/0/CPU0:XR3#show isis database XR2.00-00 detail
Tue Aug 12 21:53:13.981 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x0000002f   0x4e13        1193            1/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  Hostname:     XR2
  IP Address:   2.2.2.2
  Router Cap:   2.2.2.2, D:0, S:0
  Metric: 10         IS XR3.07
  Metric: 20         IP-Interarea 1.1.1.1/32
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.0.23.0/24
1.1.1.1/32 shows up in LSP as an IP-Interarea route. Again a TLV is used for this.

IPv6

When running both IPv4 and IPv6 at the same time, IS-IS can be run in single-topology or multi-topolgy mode. In single topology, all your IS-IS links need to have both v4 and v6 addresses as the SPF tree is run indenpently of prefix information. If the SPF tree is calculated to use a link without a v6 address, IPv6 traffic will be blackholed over that link.
For now I’ve added an IPv6 loopback and interface address. I’ve got IS-IS running in multi topology mode. I should still only see two LSPs from XR1’s perspective:
RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 23:47:02.152 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x0000001e   0x9683        1115            0/0/0
XR2.00-00             0x0000002b   0x62fa        1117            0/0/0

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1
IPv6 information is carried inside another TLV. Note also that there is a new NLPID value of 0x8e in the LSP. As you would guess this value represents IPv6:
RP/0/0/CPU0:XR1#show isis database detail XR2.00-00
Tue Aug 12 23:47:50.899 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x0000002b   0x62fa        1068            0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  MT:           Standard (IPv4 Unicast)
  MT:           IPv6 Unicast                                     0/0/0
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 20         IP 3.3.3.3/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         MT (IPv6 Unicast) IS-Extended XR1.00
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:12::/64
When running multi-topology mode, you’ll see MT: plus the address families configured for multi-topology. If I change this to single topology:
RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail
Tue Aug 12 23:11:20.989 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000023   0xd22a        1196            0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         IPv6 2001:db8:2:2::2/128
  Metric: 10         IPv6 2001:db8:12::/64
MT no longer shows up, and all TLVs are added as-is to the LSP.

Traffic Engineering

To enable TE, wide-metrics need to be enabled. Up until this point I’ve been using narrow metrics. Once enabled You can see the TE information in the LSP by doing a verbose output:
RP/0/0/CPU0:XR1#show isis database verbose XR2.00-00
Tue Aug 12 23:42:09.932 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000026   0x2dd8        910             0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Router ID:    2.2.2.2
  Metric: 10         IS-Extended XR1.00
    Affinity: 0x00000000
    Interface IP Address: 10.0.12.2
    Neighbor IP Address: 10.0.12.1
    Physical BW: 1000000 kbits/sec
    Reservable Global pool BW: 0 kbits/sec
    Global Pool BW Unreserved:
      [0]: 0        kbits/sec          [1]: 0        kbits/sec
      [2]: 0        kbits/sec          [3]: 0        kbits/sec
      [4]: 0        kbits/sec          [5]: 0        kbits/sec
      [6]: 0        kbits/sec          [7]: 0        kbits/sec
    Admin. Weight: 167772160
    Ext Admin Group: Length: 32
      0x00000000   0x00000000
      0x00000000   0x00000000
      0x00000000   0x00000000
      0x00000000   0x00000000
  Metric: 10         IP-Extended 2.2.2.2/32
  Metric: 10         IP-Extended 10.0.12.0/24
  Metric: 10         IP-Extended 10.0.23.0/24
  Metric: 10         IP-Extended 200.200.200.200/32
  Metric: 10         IPv6 2001:db8:2:2::2/128
  Metric: 10         IPv6 2001:db8:12::/64
Notice there there is no new NLPID value for TE. TE extensions are enabled under address-family ipv4 and hence it uses the 0xcc id. If/when RSVP-TE can use IPv6 natively, I could expect to see only the IPv6 ID.

Overload

IS-IS has the ability to set the overload bit in an LSP. This could be originated by the router itself if it was overwhelmed, but it can also be hard set when doing planned works for example. If the overload bit is set, other routers will route around the router.
router isis 1
 set-overload-bit
Note that OL bit set in the LSP:
RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 23:32:58.107 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x0000001f   0x9484        947             0/0/0
XR2.00-00             0x0000002e   0x97a4        1151            0/0/1

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1
I no longer have access to R3 now as R2 is the only router connecting these two devices:
RP/0/0/CPU0:XR1#ping 3.3.3.3
Tue Aug 12 23:08:44.083 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
I am still able to ping XR2 itself though:
RP/0/0/CPU0:XR1#ping 2.2.2.2
Tue Aug 12 23:09:32.870 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
We’ve now seen the purpose of both the ATT and OL bits, so what is the P bit for? that bit is for the Partition Repair Bit which no vendor has implemented. i.e. it should always show 0.

Segment Routing

IS-IS is easily extended using new TLVs. If I enable segment routing under my IS-IS process, I see it added as a new TLV in the LSP:
RP/0/0/CPU0:XR1#show isis database verbose XR2.00-00
Tue Aug 12 23:50:35.855 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000036   0x252b        954             0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  MT:           Standard (IPv4 Unicast)
  MT:           IPv6 Unicast                                     0/0/0
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Router Cap:   2.2.2.2, D:0, S:0
    Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 65535
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 20         IP 3.3.3.3/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         MT (IPv6 Unicast) IS-Extended XR1.00
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:12::/64

ISIS Multitopology and single Topology

When working with IPv6 prefixes in IS-IS, you can configure IS-IS to be in a single topology for both IPv4 and IPv6 or to run different topologies for IPv4 and IPv6.

IPv6

When running both IPv4 and IPv6 at the same time, IS-IS can be run in single-topology or multi-topolgy mode. In single topology, all your IS-IS links need to have both v4 and v6 addresses as the SPF tree is run indenpently of prefix information. If the SPF tree is calculated to use a link without a v6 address, IPv6 traffic will be blackholed over that link.
For now I’ve added an IPv6 loopback and interface address. I’ve got IS-IS running in multi topology mode. I should still only see two LSPs from XR1’s perspective:
RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 23:47:02.152 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x0000001e   0x9683        1115            0/0/0
XR2.00-00             0x0000002b   0x62fa        1117            0/0/0

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1
IPv6 information is carried inside another TLV. Note also that there is a new NLPID value of 0x8e in the LSP. As you would guess this value represents IPv6:
RP/0/0/CPU0:XR1#show isis database detail XR2.00-00
Tue Aug 12 23:47:50.899 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x0000002b   0x62fa        1068            0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  MT:           Standard (IPv4 Unicast)
  MT:           IPv6 Unicast                                     0/0/0
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 20         IP 3.3.3.3/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         MT (IPv6 Unicast) IS-Extended XR1.00
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:12::/64
When running multi-topology mode, you’ll see MT: plus the address families configured for multi-topology. If I change this to single topology:
RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail
Tue Aug 12 23:11:20.989 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000023   0xd22a        1196            0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         IPv6 2001:db8:2:2::2/128
  Metric: 10         IPv6 2001:db8:12::/64
MT no longer shows up, and all TLVs are added as-is to the LSP.



First of all, let’s see how IS-IS works by default when activating IPv6. The lab I’m going to use is as follows:
By default, IS-IS works in single-topology mode when activating IPv4 and IPv6. This means that the IS-IS topology will be built based on IS Reachability TLVs. When the base topology is built, then IPv4 prefixes (IP Reachability TLV) and IPv6 prefixes (IPv6 Reachability TLV) are added to each node as leaves, without checking if there is IPv6 connectivity between nodes.
Let’s imagine we have the above IPv4 and IPv6 address scheme. As we can see, adjacencies are formed regardless the IP scheme on the link:
R4# show isis neighbors
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R1             L1   Fa1/0       10.10.14.1      UP    24       R4.01
R1             L2   Fa1/0       10.10.14.1      UP    29       R4.01
R5             L1   Fa2/0       10.10.45.5      UP    9        R5.01
R5             L2   Fa2/0       10.10.45.5      UP    9        R5.01
R4# show isis ipv6 topology
R4#
R4# show isis topology
IS-IS TID 0 paths to level-1 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   10         R1                   Fa1/0       ca00.0f26.0038
R2                   20         R1                   Fa1/0       ca00.0f26.0038
R4                   --
R5                   10         R5                   Fa2/0       ca04.0f5d.001c 

IS-IS TID 0 paths to level-2 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   10         R1                   Fa1/0       ca00.0f26.0038
R2                   20         R1                   Fa1/0       ca00.0f26.0038
R4                   --
R5                   10         R5                   Fa2/0       ca04.0f5d.001c
R4#
R5# show isis neighbors
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R4             L1   Fa1/0       10.10.45.4      UP    24       R5.01
R4             L2   Fa1/0       10.10.45.4      UP    28       R5.01
R5# show isis ipv6 topology
R5#
R5# show isis topology
IS-IS TID 0 paths to level-1 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   20         R4                   Fa1/0       ca03.0f3b.0038
R2                   30         R4                   Fa1/0       ca03.0f3b.0038
R4                   10         R4                   Fa1/0       ca03.0f3b.0038
R5                   --

IS-IS TID 0 paths to level-2 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   20         R4                   Fa1/0       ca03.0f3b.0038
R2                   30         R4                   Fa1/0       ca03.0f3b.0038
R4                   10         R4                   Fa1/0       ca03.0f3b.0038
R5                   --
R5#
As we can see, the IS-IS IPv4 topology is built (IS Reachability TLV), and IPv4 and IPv6 prefixes are added to each node based on the information announced by each router (IP Reachability TLV and IPv6 Reachability TLV). IS-IS doesn’t check the IPv6 consistency in the actual topology, so we may come to the scenario where R5 thinks there is IPv6 connectivity to reach R1 IPv6 address, when indeed, there isn’t:
R5# sh ipv6 route
....
I1  2001:CC1E:1:1::1/128 [115/20]
     via FE80::C803:FFF:FE3B:38, FastEthernet1/0
I1  2001:CC1E:2:2::2/128 [115/30]
     via FE80::C803:FFF:FE3B:38, FastEthernet1/0
I1  2001:CC1E:4:4::4/128 [115/10]
     via FE80::C803:FFF:FE3B:38, FastEthernet1/0
LC  2001:CC1E:5:5::5/128 [0/0]
     via Loopback0, receive
...
R5# ping ipv6 2001:CC1E:1:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:1::1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5#
R5# ping ipv6 2001:cc1e:4:4::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:4:4::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/32 ms
What can we do to avoid this behaviour? We can activate IS-IS Multitopology. Doing so, IS-IS creates two different topologies: one built based on IS Reachability TLVs and dedicated to IPv4 routing info, and a second one built based on Multitopology IS Reachability TLVs and dedicated to IPv6 routing info.
(in each router)
router isis
 net 49.0001.0050.0500.5005.00
 metric-style wide
 passive-interface Loopback0
 !
 address-family ipv6
  multi-topology
 exit-address-family
R5# show isis topology
IS-IS TID 0 paths to level-1 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   20         R4                   Fa1/0       ca03.0f3b.0038
R2                   30         R4                   Fa1/0       ca03.0f3b.0038
R4                   10         R4                   Fa1/0       ca03.0f3b.0038
R5                   --

IS-IS TID 0 paths to level-2 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   20         R4                   Fa1/0       ca03.0f3b.0038
R2                   30         R4                   Fa1/0       ca03.0f3b.0038
R4                   10         R4                   Fa1/0       ca03.0f3b.0038
R5                   --

R5# show isis ipv6 topology
IS-IS TID 2 paths to level-1 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   **
R2                   **
R4                   10         R4                   Fa1/0       ca03.0f3b.0038
R5                   --

IS-IS TID 2 paths to level-2 routers
System Id            Metric     Next-Hop             Interface   SNPA
R1                   **
R2                   **
R4                   10         R4                   Fa1/0       ca03.0f3b.0038
R5                   --
Having two different topologies, now IS-IS can add IPv4 prefixes and IPv6 prefixes to the correspondent node depending on the topology. Because in the IPv6 topology there is no connectivity between R1 and R4, the IPv6 info is consistent, and we can see that R4 and R5 doesn’t see R1 and R2 IPv6 prefixes as reachable:
R5# show ipv6 route
...
I1  2001:CC1E:4:4::4/128 [115/10]
     via FE80::C803:FFF:FE3B:38, FastEthernet1/0
LC  2001:CC1E:5:5::5/128 [0/0]
     via Loopback0, receive
...
R5# ping 2001:cc1e:4:4::4 sour lo0
Packet sent with a source address of 2001:CC1E:5:5::5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/20 ms
Of course, having two topologies increases the resources needed by each router, and also the runs twice the spf algorithm, since you need to keep two topology bases.
So all these make me think that a single-topology architecture is thought for dual-stack networks, where there is IPv4 and IPv6 connectivity end to end. While multitopology is for those scenarios where there may be some segments where IPv6 connectivity is not granted.