The War is On Between R4 and SW4!
Today my routers finally passed the point of no return. Negotiations between R4 and SW4 broke down, and the course of action we were all trying to avoid was now inevitable... all out war.
R4#
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 204.12.1.0 type-5 adv-rtr 223.255.255.255 in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 31.2.0.0 type-5 adv-rtr 223.255.255.255 in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 31.3.0.0 type-5 adv-rtr 223.255.255.255 in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 204.12.1.0 type-5 adv-rtr 223.255.255.255 in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 31.2.0.0 type-5 adv-rtr 223.255.255.255 in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 31.3.0.0 type-5 adv-rtr 223.255.255.255 in area 0
Who will be the winner? Only time will tell. What sent them over the edge though? Did the diplomat in charge of DTP negotiation fail?
Be the first person to tell me why R4 and SW4 declared all out WAR on each other and win a $50 amazon gift card! Post your comments now!
Update:
Congratulations to Patrik Berglund, winner of a $50 amazon gift card!
R4 and SW4 declared war on each other because they had duplicate OSPF Router-IDs. When R4 redistributed routes into OSPF, it generated LSA Type-5 routes tagged with its own Router-ID, 223.255.255.255. Per RFC 2328, OSPFv2:
13.4. Receiving self-originated LSAsIt is a common occurrence for a router to receive self-
originated LSAs via the flooding procedure. A self-originated
LSA is detected when either 1) the LSA's Advertising Router is
equal to the router's own Router ID or 2) the LSA is a network-
LSA and its Link State ID is equal to one of the router's own IP
interface addresses.However, if the received self-originated LSA is newer than the
last instance that the router actually originated, the router
must take special action. The reception of such an LSA
indicates that there are LSAs in the routing domain that were
originated by the router before the last time it was restarted.
In most cases, the router must then advance the LSA's LS
sequence number one past the received LS sequence number, and
originate a new instance of the LSA.It may be the case the router no longer wishes to originate the
received LSA. Possible examples include: 1) the LSA is a
summary-LSA or AS-external-LSA and the router no longer has an
(advertisable) route to the destination, 2) the LSA is a
network-LSA but the router is no longer Designated Router for
the network or 3) the LSA is a network-LSA whose Link State ID
is one of the router's own IP interface addresses but whose
Advertising Router is not equal to the router's own Router ID
(this latter case should be rare, and it indicates that the
router's Router ID has changed since originating the LSA). In
all these cases, instead of updating the LSA, the LSA should be
flushed from the routing domain by incrementing the received
LSA's LS age to MaxAge and reflooding (see Section 14.1).
In this case, SW4 received an external LSA with its own Router-ID (223.255.255.255) as the originator ID. Since SW4 didn't have a route to the destination that it was originating, it thought that it had previously originated the route, lost the route to the destination, and now received an old LSA which was aging out throughout the topology. In response to this SW4 incremented the age of the LSA to MaxAge, effectively poisoning it. When R4 received this back, it thought that its own LSA was somehow aged out, but since it had a route to the destination itself locally still it re-originated the LSA again. The fight between the legitimate route and the MaxAge route continues over and over, resulting in the FLOOD_WAR message on the command line.
For more detailed information and lab scenarios like this check out the new IEWB-RS Volume 1 Version 5.0!
