any Null interface?

Hi,

is there any Null interface / bit bucket concept in RouterOS?

Cheers!

Not exactly as such.

The best functional equivalent is to install routes of type unreachable, or type blackhole.

You can also create an empty bridge (like a BVI with no bridge-group members), and use it as a Null or Loopback interface.

–Eric

thanks for the reply Eric.

I was trying to get the same behavior as the Cisco Null interface but not a Loopback.

I think this might be what I’m looking for. i have to do a BGP implementation with Mikrotik. I don’t use the entire public /24 subnet on the edge router but I want to advertise the entire subnet to the ISPs. The static route to the Null interface for the entire IP block would allow me to do this fairly simple.

Have you used it this way by any chance?

To advertise whole subnet to remote BGP peer you simply need to add that subnet in “/routing bgp network”, route in routing table is not required.

so with RouterOS there’s no need for the networks added to the BGP process to match to what’s in the routing table?

For example if I have a /24 public subnet and use only 2 /28 sunets, can I advertise the entire /24 to the ISP only by adding the /24 to the BGP network command?

Thanks

Yes, just add /24 to networks and it will be advertised.

OK, cheers!

I have a question though: what happens with an incoming packet with a destination in /24 but outside the 2 /28 subnets that are used? If default routes to the ISPs are used then will it loop back to the ISP? With a static route to the Null interface it would have been sent to the bit bucket.

Reading a bit on the blackhole feature, I think the answer to my question is to use also a blackhole route for the entire /24 public block in conjunction with network=…/24 command for BGP.

My expected result would be that any packet with a destination IP on /28 subnets will be delivered and the ones with destination IP outside the used subnets (but in /24) will be sent to this blackhole.

Is this doable?

Yup, that would work.

The BGP network statement wouldn’t be necessary if you you redistribute the covering (/24) static/connected route into BGP. We don’t use network statements, instead relying on redistribution, since doing so allows for greater filtering flexibility (attaching communities and such).

We also use type=unreachable, so that an ICMP message is sent in response to packets that get droped; but type=blackhole works the same way, just silently.

This is pretty much exactly what we do for our PPPoE concentrators. A covering (usually /22) type=unreachable static route is announced to BGP, while the individual /32s for active tunnels are suppressed by filters. Traffic going to an active tunnel gets delivered to that tunnel, and traffic to other (inactive) addresses within the covering prefix is dropped (with an ICMP unreachable message generated).

–Eric

Thanks for the info Eric!