Our upgrade to v7.13 broke BGP. I'm including the BGP config for three routers at the end. Router #1 is the gateway router. Router #1 and Router #3 run fine with router #2 on v6.

Issue at Router #1:
Router #1 has a bad route to 10.2.14.0/24 advertised by the downstream router. In winbox it shows: Dst: 10.2.14.0/24 Gateway: 198.245.193.230 recursive via 198.245.193.241 sfp-sfpplus1. I would expect it to route to 198.245.193.230 for dst of 10.2.14.1, but it's routing to 198.245.193.241, which is the default gateway.

Issue at Router #3:
Router #3 is not receiving a default gateway address unless Router #2 is configured with default-originate=always. on v6, I had default-originate=if installed

I also had trouble with filters, but the work-around was to disable them. This is what they looked like after the upgrade to v7.
/routing filter rule
add chain=primary disabled=no rule="set distance 10; set bgp-local-pref 100;"
add chain=secondary disabled=no rule="set distance 20; set bgp-local-pref 70;"



#Router #1 (v6.49.10)
/routing bgp instance
set default out-filter=bgp-out redistribute-static=yes
add as=65001 name=ncresa redistribute-other-bgp=yes router-id=0.0.0.1
/routing bgp peer
add default-originate=always hold-time=10s instance=ncresa keepalive-time=3s \
name=ncresa remote-address=198.245.193.226 remote-as=65001 ttl=default


#Router #2 (v6.49.10) Working
/routing bgp instance
add as=65002 name=test redistribute-other-bgp=yes redistribute-static=yes \
router-id=0.0.0.2
add as=65001 name=ncresa redistribute-other-bgp=yes redistribute-static=yes \
router-id=0.0.1.1
/routing bgp peer
add hold-time=10s in-filter=primary instance=ncresa keepalive-time=3s name=\
ncresa remote-address=198.245.193.225 remote-as=65001 ttl=default
add default-originate=if-installed hold-time=10s in-filter=secondary \
instance=test keepalive-time=3s name=test remote-address=198.245.193.230 \
remote-as=65002 ttl=default

#Router #2 (v7.13) Not Working
/routing bgp template
add as=65001 disabled=no name=ncresa output.network=bgp-networks \
.redistribute=static,bgp,vpn,dhcp router-id=0.0.0.2
add as=65002 disabled=no name=ncresa-e output.network=bgp-networks \
.redistribute=static,vpn,dhcp router-id=0.0.1.1
/routing bgp connection
add as=65001 cisco-vpls-nlri-len-fmt=auto-bits connect=yes disabled=no \
hold-time=10s keepalive-time=3s listen=yes local.role=ibgp name=ncresa \
output.default-originate=if-installed .network=bgp-networks \
.redistribute=static,bgp remote.address=198.245.193.225/32 .as=65001 \
.port=179 router-id=0.0.0.2 routing-table=main templates=ncresa
add as=65002 cisco-vpls-nlri-len-fmt=auto-bits connect=yes disabled=no \
hold-time=10s keepalive-time=3s listen=yes local.role=ibgp name=test \
output.default-originate=always .network=bgp-networks .redistribute=\
static remote.address=198.245.193.230/32 .as=65002 .port=179 router-id=\
0.0.1.1 routing-table=main

Router #3 (v6.49.10)
/routing bgp instance
add as=65002 name=ncresa redistribute-other-bgp=yes redistribute-static=yes \
router-id=0.0.14.1
/routing bgp network
add network=10.2.14.0/24
add network=198.245.193.228/30
/routing bgp peer
add hold-time=10s instance=ncresa keepalive-time=3s name=ncresa \
remote-address=198.245.193.229 remote-as=65002 ttl=default

You need IGP running or static routes to resolve recursive gateways. And apart from that running two BGP instances does not make sense in that setup.

I found if I set "Nexthop Choice" to "force self", the routes will propagate and have the correct gateways.

My filter is blocking the propagation of routes through the network still. I've yet to dive into that one.

mrz: Can you alborate on "need IGP running"? I have the local role selected. This is simplified setup to test v7. There are actually many routers that form redundant loops between multiple buildings.

yes, you could use "force self" as a workaround if you for some reason do not want to set up IGP.

regarding filters, do you have at least one rule that accepts something? if not then everything is rejected by default.

I do not have a good understanding of IGP. Am I not using it when I specify local.role=iBGP?

As for the filters: here they are from v6, which work fine:
/routing filter
add chain=primary set-bgp-local-pref=100 set-distance=10
add chain=secondary set-bgp-local-pref=70 set-distance=20

A remote router would have the primary filter applied to the session with the edge router and the secondary applied to the session with a router that is more than a hope away from the edge router to ensure the shortest path to the edge router. You can image three routers in a ring. Maybe IGP would do this for me if I knew what I was doing.

Thanks!

IGP = Interior Gateway Protocol = OSPF, ISIS, ect

He's asking why you arent running a traditional IGP like OSPF to distribute your routes inside your AS?

Thank you JJT211, I've not considered using OSPF or ISIS, so I don't really have an answer for why I don't use them. I would welcome advice!

It does appear that I am all fixed up now. For clarification, this is a WAN that connects 6 K-12 school districts back to an Internet source. Each of the schools have their own firewalls and local networks. The WAN is setup with diverse fiber paths between schools to facilitate physical redundancy back to the Internet source. I believe this is what BGP is designed for.

mrz mentioned "do you have at least one rule that accepts something?". I didn't really know what this meant until I dug into it. After I added the accept command, my filters started working again:

What v7 converted my v6 configuration into:
add chain=primary disabled=no rule="set distance 10; set bgp-local-pref 100;"

The working command with accept added to the end:
add chain=primary disabled=no rule="set distance 10; set bgp-local-pref 100;accept"

Thank you mrz! Sorry for the confusion. the v7 configuration is a big change from v6 and it took me a while to put the pieces together.

If v6 rule had ation=passthrough, then v7 rule is converted without action since it is the same as the "passthrough".