
Advertising a link into multiple OSPF processes.
Hi all,
In a lab scenario i configured OSPF as a HUB and spoke network, similar to the below
|--------------R2
R1
|--------------R3
R1 is configured as below
Int loop0
ip address 1.1.1.1 255.255.255.0
int f0/0
ip address 12.1.1.1 255.255.255.0
int fa0/1
ip address 13.1.1.1 255.255.255.0
router ospf 2
network 12.1.1.0 0.0.0.0 area 0
network 1.1.1.0 0.0.0.0 area 0
router ospf 3
network 13.1.1.0 0.0.0.0 area 0
network 1.1.1.0 0.0.0.0 area 0
And a basic ospf config on R2 & R3. Neighbors are up (R1&R2) (R1&R3) but the loopback interface is only advertised to 1 neighbor, it is advertised to which ever process the link is configured under first. It is also only in 1 of the ospf database on R1.
It seems to be an order of operation issue but not sure the exact reason why the link can not be advertised into both processes.
Can anyone one shed some light on this?
Comments
In the labs, I have always needed to choose which process to use for the advertisement -- and then redistribute between the processes if necessary.
I did not find anything in the ciscoDocs, butI found an unofficial explanation about it.
https://supportforums.cisco.com/discussion/11146641/ospf-one-interface-multiple-processes
"In OSPF for IPv4, an interface can be a part of a single OSPF process
only. The OSPF packets do not have any identification into which process
they belong, and if an interface was active in several OSPF processes,
the OSPF packets sent out that interface could not be properly
distinguished and sorted among process instances. The OSPFv3 for IPv6
includes a support for running multiple instances over a single
interface but as of now, the OSPFv3 supports only IPv6 and so it would
not be helpful to you......."
Hi,
You can advertise the same interface into multiple EIGRP processes for example, because in EIGRP the AS number is present in all EIGRP packets, one reason being that AS number needs to match between neighbors. Thus when a router receives an EIGRP packet it knows to which AS number/process ID to attach it to. This is not the same for OSPFv2, where the process ID is locally significant and is NOT present in any OSPF packet. To fix this issue and allow multiple OSPF processes run over the same interface, in OSPFv3 the OSPF packet has a special field called the "instance ID".
While this is a whole big topic by itself, why would you want to run multiple OSPF/EIGRP processes over the same interface, other than for migration purposes?
Regards,
Cristian.
Thanks all,
Yes it is for a migration, the current environment runs
OSPF. The idea was to advertise link-states (servers) into 2 different OSPF process
on the LAN. The existing configuration remains the same, and the new routers
run a new OSPF process. Then there would be no need to filter between old and
new environment.