Cisco Live 2016 – Las Vegas

So I’m finally off to Cisco Live! This will be my first time there, and I’m hoping to meet and speak to a lot of people I speak to online.

So far my timetable looks like so:

Monday 11th July

  • Troubleshooting BGP [BRKRST­3320]
  • ASR­9000/IOS­XR Understanding forwarding, troubleshooting the system and XR operations [BRKSPG­2904]
  • Introduction to Segment Routing [BRKRST­2124]
  • A Practical Introduction to DevOps Practices and Tools [BRKCLD­1003]

Tuesday 12th July

  • IP LFA (Loop­Free­Alternate): Architecture and Troubleshooting [BRKRST­3020]
  • How to write an IPv6 Addressing Plan [BRKRST­2667]
  • Addressing Networking challenges with latest Innovations in IPv6 [BRKRST­2616]

Wednesday 13th July

  • Troubleshooting End­to­End MPLS [BRKMPL­3124]
  • Hitchhiker’s Guide to Troubleshooting IPv6 ­ Advanced [BRKRST­3304]
  • High Availability in the Access [BRKCRS­3438]

Thursday 14th July

  • Building a Software Defined Service Provider [BRKSPG­2001]
  • The Future of SP and Your Role in It [INTGEN­1007]
  • Advanced ­ Scaling BGP [BRKRST­3321]

That’s it so far. I may change things around, but should be a lot of fun!
logo

One Million Views

It’s hard to believe that my blog has just surpassed 1000000 views!

Screenshot from 2015-12-04 15:52:03I started this blog out just on the side to go over things I was learning. I’ve learned a lot in the process, and managed to bag myself two CCIEs, a JNCIE-SP, a job at Google, and the opportunity to write a book for Juniper.

There were times I almost completely lost my blog in the past, but I’ve learned how to make good backups. My site has been reachable over native IPv6 for many years, and I moved it all to HTTPS over a year ago.

Recently there has been a lack of updates. Google keeps me very busy in an enjoyable job, and this is the main reason I struggle to find the time to do updates. I currently have 128 drafts sitting waiting, and I doubt the majority will ever get published :(

Numbers

  • Views – 1,000,115
  • Most on a single day – 1,592
  • Published posts – 322
  • Drafts – 128

What’s poular

All time top post – Access-lists vs Prefix-lists
Second all time top post – BGP Confederations – How, What and Why.

2015 top posts:
ESXi whitebox server
MPLS L3VPN – Route Distinguisher vs Route Target vs VPN label
Moving routes between a VRF and the global (default) RIB – Part 1 – Cisco IOS

It seems to me that my top posts are usually explaining something simple that a lot of people get wrong. I also tend to get high hits on lab building posts. Oddly, some of my own favourite posts barely get any views at all :(

I want to thank everyone who has ever visited the site. It’s really weird when people meet me for the first time and know me through my blog. Long may it continue!

Darren

Debian/Ubuntu PMTUD & uRPF

I originally started my PMTUD posts using Ubuntu 14.04. Halfway through the post I simply could not get Ubuntu to change it’s MTU on receipt of ICMP fragmentation needed messages. I then tried Debian and it worked. Windows also had no issues changing it’s MTU.

Wanting to finish off the post I switched to Debian and then would investigate the fault later.

Let’s remind ourselves of the original topology:
pmtu-1
Swap out Debian for Ubuntu in the above image.

When I initially started to test, I dropped the MTU between R1 and R2 to 1400. The link between R2 and R4 was kept at 1500. If the user requested a file from the server at this point, Ubuntu would attempt to send at 1500 and get it’s packet dropped at R1. R1 would send a Fragmentation Needed packet back to the Ubuntu server, which would adjust it’s MTU and then send at 1400.

When I changed the MTU between R1 and R2 back up to 1500 and dropped R2-R4 down to 1400, it no longer worked. Debian and Windows did work. I ran tcpdump on Ubuntu and confirmed that it was definitely getting Fragmentation Needed packets. Ubuntu was only acting on Fragmentation Needed packets if it came from it’s default gateway, R1. Any router further along in the path was getting it’s ICMP packets ignored.

In order to understand what the problem is I need to show more about the topology. While the above diagram shows how thins are connected for the most part, it is missing a couple of things. All the devices are running inside virtualbox linked to GNS3. eth1 of all the servers are connected to the above topology, while eth0 was connected via NAT to my host PC so I could install software:
PMTUD-uRPF
Each device had a static route to 192.168.0.0/16 to go out eth1 while their default route was out eth0. Some of you may be sensing what the issue is already…

The point to point links between the virtual routers are using the 10.0.0.0/8 space.

If Ubuntu received an ICMP packet from 192.168.4.1, it’s local default gateway on R1, there were no issues. If it received a packet from R2 or R4’s local interfaces, the packet was dropped. Debian and Windows both didn’t have problems, even though they are configured the same way.

sysctl.conf

I’ve touched on sysctl.conf before the the PMTUD posts, but there is an important difference in the defaults of Ubuntu and Debian. Take a look at this.
Debian:
Screen Shot 2014-09-02 at 9.11.50 am
Ubuntu:
Screen Shot 2014-09-02 at 9.12.01 am

uRPF

Ubuntu has Unicast Reverse Path Forwarding on by default. Debian has it off by default. In sysctl.conf on both machines, the required configuration setting is commented out:
Screen Shot 2014-09-02 at 9.15.44 am
R2 was originating it’s ICMP packets from it’s local interface, 10.0.12.2 in my example. Ubuntu did receive that packet, but it failed the RPF check and so was ignored. To confirm I tested this in two different ways:

  • Add a static route to 10.0.0.0/8 out eth1
  • Disable uRPF check on Ubuntu

Each test individually allowed the original PMTUD to work. What’s odd is that the sysctl.conf file in Ubuntu says that you need to uncomment the lines to turn on uRPF, but it’s on by default. Uncommenting the lines and setting the value to 1 is the same as leaving them commented. In Debian the default is to disable uRPF. In that distro you would need to uncomment the uRPF lines and set the value to 1 to turn the feature on.

Conclusions

  • If a server is multi-homed, PMTUD could break if the ICMP message arrives on an interface that the server is not expecting.
  • If you do have a server multi-homed, it would probably be best to turn off uRPF

Fundamentals – PMTUD – IPv4 vs IPv6 – Part 2 of 2

This is a continuation of a post I started back here. Please read it first before starting below.

RFC 4821

Another workaround we can use is Packetization Layer Path MTU Discovery – RFC 4821. The RFC enables a host to mainly acts in one of two ways:

  • Use regular PMTUD. If no acknowledgments are received and no ICMP messages are received, start to probe.
  • Ignore regular PMTUD and always probe.

Probing is where the host will send a packet with the min MTU configured and then attempt to increase that size. If acknowledgements are received on the larger size, then try increase it again. Option 1 will wait for a timeout so on broken PMTUD paths it starts a bit slow. It will however use regular PMTUD whenever it can so it’s a lot more efficient. Option 2 simple probes all the time. It starts a bit quicker on smaller MTU paths, but the server is also sending smaller packets to ALL paths in the beginning. Much less efficient.

I’ll configure this in Debian and then go through Wireshark to show what’s going on. Add the commands net.ipv4.tcp_mtu_probing = 1 to /etc/sysctl.conf then reload sysctl:

[email protected]:~# sysctl -p
net.ipv4.tcp_mtu_probing = 1

Start the transfer and what does Wireshark show us:
Screen Shot 2014-08-29 at 3.43.59 pm
After the standard 3-way handshake, the server sends a number of 1514 byte packets. ICMP has been blocked and as such there are no ICMP fragmentation needed messages coming from R2. After 5.3 seconds the server sends a number of 578 byte packets.
Screen Shot 2014-08-29 at 3.43.24 pm
These get ACK’d correctly:
Screen Shot 2014-08-29 at 3.44.59 pm
0.5 seconds later the server sends a single 1090 byte packets and fill the rest of the window with 578 byte packets. As soon as the ACK for that big packet comes back, the server sends all of its packets at 1090:
Screen Shot 2014-08-29 at 3.47.31 pm
Screen Shot 2014-08-29 at 3.48.01 pm

A couple of things to note about this setting in Ubuntu 14.04 and Debian 7.6.0:

  1. The system does not cache the MTU of the path found through PLPMTUD. This does mean that if you have a host making multiple TCP connections to your server over a small MTU path, each one of those are going to need to wait for the timeout.
  2. There is no net.ipv6.tcp_mtu_probing setting in sysctl.conf. However if you enable this setting for IPv4 then IPv6 has the same behavior as IPv4:

Screen Shot 2014-08-29 at 3.54.50 pm

Windows can also be configured for PLPMTUD but I’ll leave it up to the reader to figure out how to do that.

PMTUD Cache

I showed in part 1 that the server will cache an entry if the MTU is lower than the local link. By default, Debian will cache this entry for 10 minutes. This time is adjustable via sysctl.conf:

[email protected]:~# sysctl -a | grep mtu_expires
net.ipv4.route.mtu_expires = 600
net.ipv6.route.mtu_expires = 600

As soon as a value is cached, the timer starts. This timer counts down even if there is an existing file transfer. The reason is because paths can change. While the transfer is going on it could move to a path which has no MTU issues. We would want the server to then increase it’s MTU. Doing this too quickly can cause more traffic to drop and so the suggestion is to cache the MTU for 10 whole minutes and then try to increase. I’ve started a file transfer which is ongoing and then checked the cache entry on the server. You can see the timer going down:
Screen Shot 2014-09-01 at 1.22.23 pm
The client has then finished downloading and disconnected from the server. At this point the server still keeps that cache entry. This ensures that if the client connects again shortly it will start with an MTU of 1400:
Screen Shot 2014-09-01 at 1.30.12 pm
I’ve started a new download within the cache time above and we can see the server immediately starts sending packets with the correct MTU:
Screen Shot 2014-09-01 at 1.37.23 pm

What should happen when the cache times out is that the server should try to send a larger MTU packet, up to the local MTU. I don’t see that with Debian though. I started the test with the lower MTU cached on my server. When the cache was about to expire above I started the test again and as expected the session starts with the lower cached MTU. I then changed the MTU between R2 and R5 back up to the regular MTU:

R2(config)#int fa0/1
R2(config-if)#no ip mtu 1400
R2(config-if)#end

The odd thing is, when the cache entry timed out, Debian carried on sending packets with an MTU of 1400 and cached the entry again. That’s not supposed to happen.

I then tried the same test again, this time manually clearing the cache on Debian:

[email protected]:~#ip route flush cache

This time the server immediately started to send larger packets:
Screen Shot 2014-09-01 at 2.16.48 pm

IPv6 has roughly the same broken behavior. At first the cache is created and starts to count down. I started a transfer when it was about to expire. This time it again stayed at 1400, but the timer jumped into a huge number:
Screen Shot 2014-09-01 at 3.59.22 pm
8590471 seconds is roughly 99 days. Not sure if this is a bug or what exactly.

Clearing the IPv6 cache on the other hand had the required effect:
Screen Shot 2014-09-01 at 4.04.20 pm
If the MTU matches the outgoing interface, there is no need for the system to cache that entry taking up more resources on the server. Wireshark shows the jump in MTU:
Screen Shot 2014-09-01 at 4.05.32 pm

Conclusions

  • Blocking the required ICMP packets breaks PMTUD completely.
  • There are alternatives to PMTUD, but they are slower initially.
  • Test your OS’s behavior. I mainly tested with Debian and I ran into a number of ‘odd’ scenarios. Mainly to do with the cache.

Demystifying the IS-IS database

I’ve gone over the OSPFv2 and OSPFv3 databases in depth before. Now is the time for IS-IS. As always, I’ll start from a basic two router set up and add devices to the topology.

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