Kinshuk, Julio,
Please allow me to join.
To expand on Julio's spot-on response, Opaque LSAs are generated by additional features to OSPF. Basic OSPF does not use them; they have been invented later to allow OSPF to be extended with new features and new information types without modifying the existing LSA types. The three Opaque types differentiate the flooding scope - LSA9 will not be flooded past a directly connected neighbor (link-scoped), LSA10 will not be flooded past the area border (area-scoped), and LSA11 will be flooded across the whole OSPF domain (AS-scoped).
Exactly because they have been designed to provide future extensibility, Opaque LSAs do not have any particular meaning limited to just one purpose - they are containers to carry whatever data is necessary. The current list of applications for Opaque LSAs can be found here:
https://www.iana.org/assignments/ospf-opaque-types/ospf-opaque-types.xhtml#ospf-opaque-types-2
You have also asked about LSA8. OSPFv2 does not currently use LSA8. However, the initial idea was to use LSA8 as a container for BGP attributes for routes redistributed from BGP into OSPF. The idea was generally as follows:
- BGP speakers at the AS boundary would only have external BGP peerings with their neighbors in different ASes, not internal BGP peerings with each other. This would avoid the need for a fully meshed iBGP between AS boundary routers, or the need for a BGP route reflector.
- All BGP routes would be redistributed into OSPF inside the AS.
- To make sure the BGP attributes of individual routes don't get lost during the redistribution, they would be put into LSA8 and flooded.
- During the reverse redistribution from OSPF into BGP, the original BGP attributes would be reconstituted from the corresponding LSA8.
Nowadays, this approach is not even remotely reasonable - with the number of routes in BGP, OSPF simply would not scale. LSA8 therefore remained just a hypothetical idea without a practical implementation.
Best regards,
Peter
