![]() "lo0.0" was set "passive" on both ospf and ospf3 protocols. So thats it, it allowed Mikrotik to receive the routes /128 and all I did was to remove the flag "passive" from interface ospf3 at Junos side. Today I was going to do that and in the middle of the proccess Ive commited a Junos config which successfully exported all the /128s. I got that, closed the case and was going to change all those /128s to /127s which was working well between Junos and ROS. So they said "different vendors may not work smoothly". Ive opened a case at Juniper networks and we concluded that Juniper was indeed exporting the /128s without really solving the problem. Surprisingly, /128s at loopback interface from Juniper was NOT being exported to other router Mikrotik. Just in case, there was /128s configured on ROS 5.25 so we just copied the same configuration on Junos (at least, expecting the same results). The task was quite simple: Switch a 1100AHx2 for a MX5. So let me share my experience so it may help you too. We are starting to implement Juniper on our backbone and it seems we jumped in kinda the same issue reported here. Unsure if related- these are logged constantly on the Mikrotik: ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 ![]() O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ![]() I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary Here's its OSPF neighbor, which is a Cisco:Ĭodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP Code: Select all /ipv6 route print where ospfįlags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |