I have stumbled across a issue I have with an OSPF network.
As usual the communities comments would be appreciated.
The client comes from a traditional Enterasys background.
The Data Centers utilize S series chassis.
The client also still have a lot of the older Enterasys XSR routers deployed at remote sites that connects back to the network via wireless links.
The XSR routers form part of the bigger ospf network.
Recently we changed the data center config to form a VXLAN fabric within the DC. (Only between the S series switches)
We enabled "vxlan extentions" as part of the config.
This all works great, OSPF advertises the know VXLAN VNI's to all switches ect.
The issue we are seeing now is that the old XSR routers stays in an OSPF loading state.
I did some wireshark traces and found that when the XSR requests the LSA DB for the DC switches, the LSA-Type 11 updates is then sent to the XSR.
The XSR then complains that this is an unknown LSA Type and then requests the DB again for the DC switches.
This runs on forever.
Only when place the XSR in a stub area does it form a full adjacency.
Stub areas does not advertise LSA-Type 11.
Or is it just a case of older devices can not handle this type of updates....
- Type 11 - an AS "opaque" LSA defined by RFC 5250, which is flooded everywhere except stub areas. This is the opaque equivalent of the type 5 external LSA.
The opaque LSAs, types 9, 10, and 11, are designated for upgrades to OSPF for application-specific purposes. For example, OSPF-TE has traffic engineering extensions to be used by RSVP-TE
in Multiprotocol Label Switching
(MPLS). Opaque LSAs are used to flood link color and bandwidth information. Standard link-state database (LSDB) flooding mechanisms are used for distribution of opaque LSAs. Each of the three types has a different flooding scope.