RSS

Blogroll

Category: CCIE

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:
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:

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:

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:

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:

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:

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.

This is an interesting draft which can ensure better paths are chosen in certain corner cases. Before this draft, BGP was able to redistribute the IGP metric as a MED value into BGP. The issue with MED is that it’s very low on the BGP best path algorithm. Note that Cisco/Brocade consider weight as primary, but I’ll ignore that for now

Highest Local-Preference

Shortest AS-Path

Lowest Origin Code

Lowest MED

ETC

MED is only number 4 in the pecking order. In a large network it might be difficult to get everything to match up to that point. Accumulated IGP Metric is a new non-transitive BGP path attribute that carries the IGP metric inside the BGP NLRI. Not only that, but the best-path algorithms are changed as follows:

Highest Local-Preference

Lowest AIGP Cost

Shortest AS-Path

Lowest Origin Code

Lowest MED

ETC

As long as your local-preference values match, the lowest AIGP cost is taken into account.

No AIGP

Take the following topology into consideration:
Assuming all link costs are the same, the shortest path for XR2 to get to IOS2 is via path XR1-XR4-IOS2. I’m going to ignore MED on XR2 for now.

IOS-XR is preferring the route with the AIGP metric set. You can see the metric value of 120 has been learned. It also sets the local route metric to 120. The update from IOS1 is not preffered so it seems like a non-aigp value is seen as worse than any aigp value that may be set.

I’m going to swap out IOS1 with another IOS-XR box. This new XR box will be advertising the route with the same metric as IOS1 currently is.

XR2 should now be seeing both AIGP values and choosing XR5 as the next-hop:

Currently IS-IS is the only protocol with support in XR. There are drafts to get this working in both OSPFv2 and OSPFv3

Segment Routing?

Segment routing is a huge topic. In the long run it’ll make it very easy for an SDN controller to force packets through the network in any way it wants. The draft says that it can use the existing MPLS data plane (aka labels) or the IPv6 data plane (header extensions). Right now support is for the MPLS data plane only. The nice thing here is that all devices that can currently switch based on labels should really only need a software upgrade to run segment routing in it’s current form.

Currently, in order to populate the MPLS data plane with labels you need a MPLS control plane protocol to distribute those labels. With segment routing, those labels are distributed with the IGP. Your core is now simplified as it’s only running the IGP with no LDP or RSVP. Your core no longer needs to keep LDP or RSVP state at all.

Traffic Engineering

Take the following simple diagram into consideration:
I’d like to use both paths to get from PE1 to PE2 for different taffic flows. This is possible with RSVP by creating multiple RSVP-TE tunnels:
The above works perfectly fine, but those P routers need to keep state for each and every RSVP tunnel going through them. In segment routing, there is a concept of a node segment and adjaceny segment. There are also other segment types but I won’t go into that yet. With the MPLS dataplane, each segment has a label. I can therefore force traffic to go over a certain segment by adding the segment label to the stack.
In the above diagram, if I want PE1 to send to PE2 via the shortest path, it simply imposes the node segment of PE2 onto the packet and sends it on. Every router in the core knows what PE2’s node segment is and as such the packet is pushed through using only that single label. Note that standard MPLS PHP behaviour is still used:

If I wanted to force traffic to PE2 to go over the P1-P2 link and then the P2-P3 link, I would stack the labels to ensure it went that way. It’s the ingress PE that decides this:
PE1 has stacked the labels in such a way that it forces the packet to go to particular segments. The core does not need to contain any of the LSP state. It simply installs the labels from the IGPs previously sent.

Configuration

Segment Routing in 5.2.0 has been enabled, but at a preliminary level only. IS-IS is the only IGP supported. MPLS dataplane is only supported. I can’t seem to find a way to advertise adjaceny segments yet, only node segments. All of the above is fine for an MPLS L3VPN lab. I’ll be using the following topology:
The CEs are running OSPFv2 and advertising their loopbacks into OSPF:

OSPF Multi-Area Adjacency is one of those things that can fix some odd corner case topologies. I would not recommend it. The issue is that now R3 has a full area 4 and area 0 database. It’s also messy. Rather redesign your network!

OSPFv3 has been extended so that IPv4 can now be routed using it. If running both IPv6 and IPV4 over OSPFv3, they are run as separate processes completely. If we go back to the topology we started with:
R1 and R2 have IPv6 OSPFv3 set to point-to-point. If I enable IPv4 OSPFv3, there is an entirely separate adjacency process. I won’t set the IPv4 to point-to-point to ensure the difference is seen:

Checking the detail the same link-local addresses are used. This is an important fact as if you wanted to run OSPFv3 in a pure IPv4 environment, you would still need IPV6 link-local addresses on each link:

The OSPFv3 database will have separate IPv4 and IPv6 databases. They do not share any of the LSAs, including Type1 and Type2s. All of the other LSAs are the same as their IPv6 counterparts in that the actual IP prefixes are carried in separate LSAs:

Here R2 is originating two Intra-Area LSAs for v4. The second is type 2002 which means that LSA is originated as the DR of that segment.

RFC 5329 has been created in order to carry TE extensions on OSPFv3, however I do not currently see support for it. I’ll have to leave those new LSAs to another day.

Conclusion

OSPFv3 is much more than just OSPF for IPv6. There are a number of enhancements that should make the IGP much more stable and efficient in larger topologies. The biggest change is the removal of IP prefix information from the Type1 LSA. A quick table look at OSPFv2 and OSPFv3 LSAs covered:

OSPF LSA Types

LSA

OSPFv2

OSPFv3

1

Router

Router

2

Network

Network

3

Summary

Inter-Area Prefix

4

ASBR-Summary

Inter-Area Router

5

External

External

7

NSSA-External

NSSA-Enteral

8

-

Link

9

-

Intra-Area Prefix

OSPFv3 is also a new protocol so there is not going to be 100% feature parity with OSPFv2 right now. I certainly would not rip out OSPFv2 and replace it with OSPFv3 anytime soon. The lack of workable TE makes it unusable as an IPv4 IGP for ISPs.

Type1 and Type2 are the big difference. In OSPFv3 they contain link-state only. Type3s and 4s are nearly identical, the only change is their name. Type5s and Type7s have the same bahaviour and even names. Type8s are the new link-local LSA unique to OSPFv3. Finally the Type9 carries the prefix information that was previously carried in the Type1 and Type2 LSAs.

Master these differences and you’re well on your way to understand this new database.