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
My Journey to CCIE
Friday 16 December 2016
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
[OK - 126060564/4096 bytes]
126060564 bytes copied in 148.648 secs (848047 bytes/sec)
cisco#
then we will have to check what is the boot variable
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 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
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
........................................................................................................................................................................
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
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#
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
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
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:
The following example reloads the router on April 30 at 3:00 a.m.:
The followind example reloads the router in 90 minutes:
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 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.
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.
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
This is the topology we’ll start with:
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:
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:
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.
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:
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:
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:
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: 1XR2 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/24XR1 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.00The 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 externalinterface 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-100As 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: 1The 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: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: 1If 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/24XR2 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/32IS-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/241.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: 1IPv6 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::/64When 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::/64MT 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::/64Notice 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-bitNote 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: 1I 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 msWe’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.
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:
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: 1IPv6 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::/64When 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::/64MT 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:
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:
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.
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:
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.
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.001cR4#
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#
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
(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 --
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
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.
Subscribe to:
Posts (Atom)