I’m having a rather odd issue and wanted to see if anybody has done or tried anything similar.
I have a Cisco 7200 running 12.2SRE acting as PPPoE LAC/LNS and OSPF router. I also have 3 PPPoE clients: 1x Cisco 871, 1x RB493G and 1x RB433AH. The 871 is running 12.4(24)T3 and the RB units are running 5.5
I am then trying to get OSPF working over the PPPoE connection, I am able to get neighbors to come up between the LNS and each PPPoE client. While OSPF comes up I am having some issues with the routes being installed into the routing table on the MikroTik clients. The routes do appear in the OSPF database, however for some reason they do not appear in the regular routing table. The Cisco CPE works just fine and the Cisco LNS correctly installs routes from the MikroTik clients into its routing table also.
It looks as if the MikroTik clients are having issues installing the routes for some strange reason.
Both Cisco units correctly detect the interface type of the Virtual Access or Dialer interface as point-to-point, while MikroTik needs to be manually told about the interface type. Ironically enough when discussing this with support I have helped them to fix a MikroTik/MikroTik bug when using OSPF over PPPoE, though I seem to be having problems getting any traction with my Cisco/MikroTik problem.
Does the association come up as “Full”? Or is it just “I see you”, “Init”. Or “I see you, you see me”, “2-Way”?
Make sure you have the same MTU on both the cisco and the MikroTik. You may want to tell the cisco to allow MTU mismatch.
I have several DSL connections from MikroTik/ImageStream/pfSense/Cisco boxes to my Cisco 7204VXR DSL aggregation box. However, I am not running PPPoE on those links. I have them setup as RBE.
interface ATM2/0.4 point-to-point
description DSL to locationname PoP
mtu 1500
bandwidth 3000
ip address 192.168.1.1 255.255.255.252
ip nat inside
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 7 ******
ip ospf network point-to-point
ip ospf cost 121
ip ospf mtu-ignore
atm route-bridged ip
no atm enable-ilmi-trap
pvc locationname 1/205
ubr 6144
encapsulation aal5snap
!
end
Make sure you have the same MTU on both the cisco and the MikroTik. You may want to tell the cisco to allow MTU mismatch.
No. This would be bad. It might come up initially. After a while the LSAs and DBDs are too big for one side as the network grows, and get silently discarded, and you flap all over the place. If you’re lucky it happens within weeks or months and you remember. If you’re not it happens in years and whoever has to troubleshoot it has to figure out a minute detail that’s really, really hard to spot.
In my case I have “ip ospf mtu-ignore” on the point-to-point interfaces already because it is a lab environment. Regardless of whether this is enabled (and there is a matching MTU on each end of the point-to-point connection anyway) I have the same issue as the OP. If the MTU does not match, and “ip ospf mtu-ignore” is not configured then a neighbour relationship is not established.
The OSPF neighbour relationship is “FULL” and the LSAa are appearing in the OSPF database. They are not however being installed into the route table.
@ fewi - I agree with not enabling “ip ospf mtu-ignore” in a production environment.
@lambert - I believe the reason this works for you and you aren’t seeing the same behaviour is because you’re not using PPP encapsulation. It appears to be the only difference between our configurations (I am using a Cisco ASR 1000 series which is very similar to the 7200 series).
If the OP controls the access concentrator, the Cisco, my post was meant to suggest RBE as a work around. I appologize if I failed to make that clear. Ignoring MTU differences was meant as a diagnostic tool to prove MTU issues which someone might not have noticed / been able to “see”.
Another possible workaround might be to bring up a tunnel on top of the pppoe layer. Then run ospf on top of that. I have that type of setup running to a mikrotik on the other side of an access concentrator which I do not control.
