bgp-origin incomplete not being set in v7?

RouterOS Forwarding Protocols
1

I’m trying to filter certain redistributed routes, but the filter does not match if I check for bgp-origin incomplete. looking at the routes being received from a router it peers with, it appears these routes are being marked as origin igp, rather than incomplete, even though they come from redistribute connected,static

I don’t want to filter them if they come from Output Network (bgp-networks), and I’ve noticed they still get marked as connected or static depending on what the active route is that matches the bgp-networks list.

This is on a device currently on v7.9.2

2

hello

from the wiki
https://help.mikrotik.com/docs/display/ROS/Moving+from+ROSv6+to+v7+with+examples

In v7 it is not possible to turn off synchronization with IGP routes (the network will be advertised only if the corresponding IGP route is present in the routing table).

and this

I don’t want to filter them if they come from Output Network (bgp-networks), and I’ve noticed they still get marked as connected or static depending on what the active route is that matches the bgp-networks list.

I’m sorry I don’t get your question,
can you be more specific?

output.network is locally generated to be advertise to peers, not those routes received from peers.

3

You mean that before you have attempted filtering, but when you view the routing table, you already see origin igp instead of incomplete?
That is not right… it works OK here.

4

I mean: routes that are being advertised by BGP because “redistribute connected” and “redistribute static” options have been enabled, are not being marked “incomplete”, instead they are being marked as “IGP”.

Routes redistributed because they appear in “output-networks” should be marked as “IGP”, routes redistributed because of “redistribute connected,static” should be marked “incomplete”. Since there is no synchronization off option in v7, this complicates matters, as the routes will get redistributed via both mechanisms. I would suggest marking them as ibgp should take priority in that case, otherwise its not possible to reliably detect in a route filter where the route came from.

Contrived example:
I want to redistribute connected routes if they are public IPs, but not private IPs, unless that private IP also appears in bgp-networks.

if (protocol connected,static && bgp-origin incomplete && chain match-private){reject} # don’t redistribute private routes, unless in a “network” statement

/ip/firewall/address-list
add address-172.16.0.0/20 list=bgp-networks
/ip/address
add address-172.16.0.1/24 interface=ether1 network=172.16.0.0
add address-172.17.20.1/24 interface=ether1 network=172.17.20.0
add address-100.64.200.1/24 interface=ether1 network=100.64.200.0
/ip/route
add blackhole dst-address-172.16.0.0/20

doesn’t work because none of the redistributed routes are marked as incomplete.
172.16.0.0/24 gets advertised because of redistribute connected, and marked as igp (should be incomplete)
172.16.0.0/20 gets advertised because of redistribute static and bgp-networks, and should be marked igp (because its from a “network” statement, the static route only existing to support that network statement), but might get marked incomplete because of the static blackhole (if incomplete were working that is)
172.17.20.0/24 gets advertised because of redistribute connected, but is marked as igp instead of incomplete.
100.64.200.0/24 gets advertised because of redistribute connected, but is marked as igp instead of incomplete.

in this example, I only want 172.16.0.0/20 advertised because it appears in bgp-networks, and 100.64.200.0/24 advertised because connected is redistributed and its not private. 172.16.0.0/24 and 172.17.20.0/24 I want to filter out, but the filter doesn’t work because they’re igp instead of incomplete so the filter has no way to tell the difference between a route being advertised because its redistributed, and a route being advertised because its in bgp-networks.

(and because synchronization off is not an option anymore, I also have to have a static route for 172.16.0.0/20, so unless bgp-networks takes precedence over redistribution, or blackhole routes are ignored by redistribution, this would be marked incomplete instead of igp (except, as I’ve said repeatedly, everything is getting marked as igp, no matter what).

To address the second comment, I’m looking at the routing table of the peer router, and it shows all routes coming from the subject router are marked as IGP, none are marked incomplete. On the subject router, /routing/bgp/advertisements/print shows all routes as “origin=0”, which corresponds to IGP.

Typically (other routers and RouterOS V6) the ORIGIN code is interpreted as:
IGP: “network statement” (“Output Network” (bgp-networks) in RouterOS v7 case)
incomplete: “redistributed from connected, static, or another protocol”

It would be nice if redistribution and output network could each have their own separate filters apart from the “Output Filter” and/or a way to directly check if an NLRI appears in “Output Network”. (maybe “protocol network” or something like that) (and either multiple output networks each with its own filter, or a way to attach a separate filter to individual networks, as its currently difficult if you need some networks to have different communities than other networks).

5

Oh I thought you meant “I am receiving routes from others that have been fed by redistribute and I want to filter them”.
That seems to be possible, because I see those routes as “origin: incomplete” in my v7 routing table.

But it appears you are using redistribute from v7 itself.
Aside from the fact that you should probably avoid that as much as possible (and instead announce the specific local routes that you want), the filtering part of what you want can likely be achieved by other filter criteria. And you can modify the origin in a filter as well, when you want your peer to see “incomplete” there.

But indeed, it probably is a bug that these redistributed routes are not marked as “origin: incomplete”. You should report that in a ticket.

6

hello @xxiii

very long description you have there, and interesting thought as well :+1:t2:

from the fact that incomplete origin is the least preferred route 1. igp 2. egp - actually doesn’t mean much.

that MT wiki about not having synchronize off option does really help to minimize this ? routes.

Routes redistributed because they appear in “output-networks” should be marked as “IGP”, [broutes redistributed because of “redistribute connected,static” should be marked "incomplete[/b]

where did you get that?
see the MT wiki point above.

i think you being confused about redistributed routes received and locally generated redistribution?

for this part,

want to redistribute connected routes if they are public IPs, but not private IPs, unless that private IP also appears in bgp-networks.

i don’t think that has any correlation with origin incomplete ? it was only filters. not on the speaker but on the receiver. you can not filter routes from your own self. how???

you do only advertise routes from your own self (not received one. locally generated only) by nail it on the routing table using ip firewall filter and advertise it through output.network.

  • otherwise you will have that incomplete route complain from your neighbor (just like what you have now).

if (protocol connected,static && bgp-origin incomplete && chain match-private){reject} # don’t redistribute private routes, unless in a “network” statement

if those were valid network inside your network - which you need to advertise it throughout your internal network - no problem, do advertise.

except on ebgp routers which will do the filters.

and those public or private filters the answer is obvious.

hope this helps.

7

RouterOS v7 has a "bgp-network" attribute that can be checked, so between that and "protocol connected,static", hopefully I can get rid of checking incomplete, which was actually the workaround (along with "Locally Originated BGP") I was using from RouterOS v6, since v6 had no way to directly check (that I'm aware of) if a route came from a "network" entry vs redistribution. In this case, I was dealing with converted-from-v6 filters, and forgot about "bgp-network" the attribute (not to be confused with "bgp-networks" the address list). I was reminded of it when I looked at one of my hand-crafted v7 filters from another project, so I apologize for the parts of this thread that are moot due to that.

However, v7 still appears to not be setting incomplete correctly (which was noticed when these converted filters which worked fine in v6 didn't work in v7). As the RFC says:

INCOMPLETE - Network Layer Reachability
Information learned by some other means

and redistribution is "some other means"

response to prior posts:
I got that from what other routers typically do, as well as what one would want to happen, and the BGP RFCs (which aren't as clear as they should be on the origin attribute). to quote from another vendor:

Indicates the origin of the entry. It can be one of the following values:
•IGP—Entry originated from Interior Gateway Protocol (IGP) and was advertised with a network router configuration command.

•incomplete—Entry originated from other than an IGP or Exterior Gateway Protocol (EGP) and was advertised with the redistribute router configuration command.

•EGP—Entry originated from an EGP.

This has nothing to do with receiving routes. I'm talking about filtering locally generated routes on output to another peer, I always want to send "bgp-networks" routes, but I only want to send some redistributed routes. (If I could associate a filter directly with redistribution, I would just use that to control what gets redistributed, which is what I do on the other platforms we use). RouterOS doesn't have this capability, so the main output filter has to do all the work, and figure out where the route actually came from.

I won't go into the details of why we want to use redistribution as opposed to explicit network statements, but they're valid reasons as far as we're concerned with our use cases.

I'm not particularly concerned with what origin code the peer sees, I was just demonstrating that v7 was advertising "IGP" instead of "incomplete" for routes that came from redistribution. I probably could have been a bit clearer and less verbose, I've been a bit rushed lately.