Soon you'll begin to think I have something against OSPF, after the previous 3-part series on how to break transit areas (start with The dark side of OSPF transit capability (1) if you haven't read it). This post looks at another OSPF problem, one that started from trying to understand the following log message: %OSPF-4-CONFLICTING_LSAID: LSA origination prevented by existing LSA with same LSID but a different mask.
A bit of background info on LSIDs
First of all, what is an LSID? Also known as the Link State ID, a field in an LSA identifying which part of the routing domain that LSA is describing (mind you I didn't say network here). Depending on the LSA type, it can have the following values:
- Type1 = the originating router's RID
- Type2 = the interface address of the DR for that segment
- Type3 = the network's IP address
- Type4 = the RID of the ASBR
- Type5 = the network's IP address
- Type7 = the network's IP address
Given that router IDs and interface addresses MUST be unique, we can ignore types 1,2 and 4. That leaves us with summary and external LSAs. For the most part, I'll stick to external LSAs, but the concepts apply to types 3 and 7 in the exact same way.
Here's the tricky part: the LSID does not have to be unique in the OSPF domain, but among the LSAs coming from the same advertising router, it has to be. This happens because it is part of a trio of values (LS Type, LSID and Advertising RID) that uniquely identify an LSA.
And it makes sense, as the same router can't send two LSAs for the same network. Well... apart from those times when you try really really hard, as you'll see below.
Keeping the LSID different
It can very well happen in today's very fragmented IPv4 space that you get (via redistribution) two subnets with different masks where one is the supernet of the other. Like this:
B 192.168.18.0/23 [200/0] via 1.2.3.4, 1w2d
B 192.168.18.0/22 [200/0] via 1.2.3.4, 1w3d
We shall start by reading Appendix E from the Bible of OSPF, RFC 2328, called "An algorithm for assigning Link State IDs".
When originating an AS-external-LSA [or a summary-LSA], try to use the network number as the Link State ID. If that produces a conflict, examine the two networks in conflict. One will be a subset of the other. For the less specific network, use the network number as the Link State ID and for the more specific use the network's broadcast address instead (i.e., flip all the "host" bits to 1).
Using the example above, the LSIDs for those two redistributed prefixes will be:
- 192.168.18.0/22 gets an LSID of 192.168.18.0
- 192.168.18.0/23 gets an LSID of 192.168.19.255 being the more specific of the two
Where it all goes wrong
The algorithm above makes one very important assumption though: it works only if there is no LSA with an LSID equal to that networks broadcast address already in the OSPF domain.
Therefore, in the example above, it is hoped that network 192.168.18.255/32 is not in the OSPF LSDB. If it was there, then you'd get an unsolvable LSID conflict, for which the RFC has no provision (perhaps considering it unlikely to happen and that if you get in that situation, you deserve it).
OK, using broadcast addresses as /32s (for loopbacks) might not be so common (although I've seen an x.y.z.0/32 as a loopback - I mean IPv4 might be scarce, but not THAT scarce!), but I have another example for you which results in a conflict without such devious /32s.
Let's say you are redistributing from BGP the following routes:
B 192.168.16.0/23 [200/0] via 1.2.3.4, 1w2d
B 192.168.16.0/22 [200/0] via 1.2.3.4, 1w3d
B 192.168.16.0/21 [200/0] via 1.2.3.4, 1w2d
B 192.168.18.0/23 [200/0] via 1.2.3.4, 1w2d
B 192.168.18.0/22 [200/0] via 1.2.3.4, 1w3d
They're very conveniently grouped, so you can tell there's some fun to be had there with conflicts. Applying the algorithm above:
- 192.168.18.0/22 gets an LSID of 192.168.18.0
- 192.168.18.0/23 gets an LSID of 192.168.19.255 being the more specific of the two
- 192.168.16.0/21 gets an LSID of 192.168.16.0
- 192.168.16.0/22 gets an LSID of 192.168.19.255 being more specific
- 192.168.16.0/23 gets an LSID of 192.168.17.255 being more specific
Uh-oh.
The result is two LSAs with the same LSID of 192.168.19.255 (but different masks, although it doesn't make a difference) being generated by the same redistributing router.
So what happens is that you get the nice log message that started this whole thing (OSPF-4-CONFLICTING_LSAID) and you have to decide which prefix of the two you can do without, because there's no way you get to keep both.
And if you don't trust me, here's what Cisco has to say about the message:
%OSPF-4-CONFLICTING_LSAID : Process [dec] area [chars]: LSA origination prevented by LSA with same LSID but a different mask Existing Type [dec] LSA: LSID [IP_address][IP_netmask] New Destination: [IP_address][IP_netmask]
Explanation: An LSA origination was prevented by a conflicit with an existing LSA with the same LSID but a different mask. The algorithm in RFC 2328, Appendix E is used to resolve conflicts when multiple LSAs with the same prefix and differing masks are advertised. When using this algorithm and host routes are advertised there are situations where conflict resolution is impossible and either the host route or the conflicting prefix is not advertised. Recommended Action: Locate the prefix that is not advertised and the conflicting prefix by entering the show ip route and show ip ospf database commands. Decide which route or prefix is more important to advertise and take steps to prevent advertising the conflicting route or prefix.
The bottom line
If you want to avoid picking favorites between prefixes, be careful when redistributing from BGP into OSPF (it's a lot harder to get the same situation with Type3 LSAs), there's always a chance that some of them will not make it into OSPF due to conflicts.
Redistribution should always be a planned exercise, done in a tightly controlled manner and with 100% predictable results. All protocols have safe-guards to try and protect themselves (and the network), but they are not perfect.
And, as always, thanks for reading.