Dear Folk,

I wish to clarity a confusion I have about the network command in OSPF as the implementation in
Quagga and MIkrotik seem to be very different.

There are two issues that need to be handled by OSPF,

1.) The network subnet that the two routers will communicate with each other over port 89 to communicate OSPF data back and forth.

2.) The subnets on various interfaces that will be advertised across the link created in 1.)

The miks seem very simple, you create a small subnet between the two routers, put it in the networks section of the OSPF setup, and the two miks start talking OSPF and start advertising ALL subnets on ALL interfaces to each other over that one link.

How does one tell mik ospf to not advertise a particular subnet?

Quagga on the other hand seems to use the network statement to do BOTH 1.) and 2.) above.

In Quagga one needs to create a network statement that has a subnet that is BIGGER than any subnet you wish
to advertise (2. above), and quagga will then advertise out any interface that has such a subnet on it, and further it
will advertise using EACH AND EVERY SUBNET on that interface that it is advertising. Thus mulitple streams
of OSPF data go out the same interface to anyone listening (multicast). If one wants only one subnet to actually be used to form the link, one needs to block the other streams with explicit fire wall statements.

Am I nuts?

Homer W. Smith
CEO Lightlink Internet

Hello Homer,

Could you post an network drawing to go with your question? Also an example Quagga and RouterOS config would help.

Best,
Chris

If I understand the question correctly - your Mikrotik is advertising all of its routes, even ones that you did not specify.

I just set up a quickie OSPF link between a Mikrotik and a Cisco router to test this.

My Mikrotik is a RB100AHx2 on v6.27

Starting with a blank OSPF configuration, it only advertises networks when I add them to the Networks tab.

My interfaces:
bridge1 = 10.10.10.1/32 ("loopback" interface)
ether1 = 10.0.1.1/24 (LAN 1)
ether2 = 10.0.2.1/24 (LAN 2)
ether6 = 10.0.255.1/30 (uplink 1 to Cisco router)
ether7 = 10.0.255.5/30 (uplink 2 to Cisco router)

The Cisco sees the two uplink networks as locally connected, so those two networks do not show up as OSPF routes on the Cisco.

On the Mikrotik....

If I create network 0.0.0.0/0 in OSPF:
Loopback, LAN1, and LAN2 all show up in Cisco's ospf routes.

If I just create 10.10.10.1/32 and 10.0.255.0/24:
Only Loopback shows up in the Cisco's ospf routes.

This is the behavior I would expect.
Do you have redistribute static or connected routes turned on in the Instance? (Routing > OSPF > Instances)

Thank you for your time and effort and clarity.

[quote]Re: OSPF MIKROTIK VS QUAGGA by ZeroByte » Fri Feb 20, 2015 11:31 am
If I understand the question correctly - your Mikrotik is advertising all of its routes, even ones that you did not specify.

YES THIS IS TRUE, IT IS IN FACT DOING WHAT I WANT IT TO BE DOING.

I HAVE REDISTRIBUTE STATIC, CONNECTED, KERNEL, AND OTHER OSPF ROUTES AS TYPE 1 TURNED ON.

THE ONLY SUBNETS IN THE NETWORK STATEMENT ARE THE SUBNETS CONNECTING THE ROUTER TO A PEER, IN THIS CASE 3 INTERFACES WITH 3 PEERS.

HERE NOW IS THE PROBLEM, I HAVE BGP PULLING IN 64.57.176.0/20 INTO OUR GENERAL AREA OF THE WOODS. I HAVE LOANED OUT 64.57.190/24 TO A FELLOW ISP, THE SMALLER SUBNET TAKES PRECEDENT AND SO HE GETS HIS CLASS C AND THEY NEVER COME TO ME.

HOWEVER FROM WITHIN MY NETWORK, MY *OSPFD* HAS A NETWORK STATEMENT THAT SAYS NETWORK 64.57.176.0/20 WHICH THEN COVERS EVERYTHING SMALLER THAN IT, INCLUDING THE 64.57.190.0/24, SO IT GETS LOST IN A LOOP INSIDE MY NETWORK.

HOMER


.


.

Try to set a filter in ospf, with discards the particular subnet

Gesendet von meinem HTC Flyer P510e mit Tapatalk 2

Thank you for your time and effort and clarity.

No problem. Glad to help.

HOWEVER FROM WITHIN MY NETWORK, MY *OSPFD* HAS A NETWORK STATEMENT THAT SAYS NETWORK 64.57.176.0/20 WHICH THEN COVERS EVERYTHING SMALLER THAN IT, INCLUDING THE 64.57.190.0/24, SO IT GETS LOST IN A LOOP INSIDE MY NETWORK.

HOMER

Network 64.57.176.0/20 should not cause any routes in OSPF from 64.57.190/24 unless the router has an interface inside that range. If it does have an interface inside that range, then it's correct for the router to announce that connection. If you want the network to route some other way to reach that same network, (suppose the router in question has a link into the /24 but it's an undesireable link) then just make the OSPF cost of this interface be very high. OSPF will go anyhwere else before it comes here.

Almost certainly, the loop is coming from a redistribute statement which is picking up a static route that should not be there.

Example: imagine 3 routers -> A -- B -- C -- (lanC)
Suppose A is configured to redistribute static, and has a static route to reach lanC via router B. Suppose now that Router C originates lanC by redistributing connected routes - if the link from B->A has a lower cost than the link from B->C, then B is going to try to reach lanC by forwarding traffic to router A! This is a routing loop.... In this case, router A should not have any static route for lanC, and this misconfiguration is causing the issue. This also holds true if redistributing from BGP, RIP, or any other protocol.

Do you have a BGP link to the other ISP?
If so, then you should probably redistribute the /24 into OSPF from eBGP on the router that's peering with the other ISP.
(be VERY careful to allow ONLY this /24 in your redistribute filters!!)

If the customer has BGP with other carriers as well, then you should just have the same redistribute filters into OSPF at your other BGP borders. Make sure the metric here is worse than the metric at the direct connection, and that it only redistributes when the next hop is the ISP, and not some internal next hop. You should have no static route to the /24 at all. If it's reachable via direct peering, your network will go that way. If it's reachable via the Internet, then your network will go that way. If the other ISP is completely down, then the /24 will disappear from your routing table and merge into your default black hole route for your /20.