3.22 routing test bgp prepending

I am having a problem figuring out as-path prepending using the 3.22 routing test now that it’s in there.

I actually made a filter that worked with the local-pref option, and added the set bgp prepend path, and as soon as I did that, both bgp peers went down, even though the filter is only applied to one peer. They then stayed in idle state. When I disabled the filter in filters, they both stayed idle. I then rebooted and the two peers were able to be reestablished. Just disabling/enabling them didn’t do the trick.

The as path prepending feature is something I’ve used for years with cisco for basic BGP routing manipulation. Perhaps I need a little education or documentation on how to implement this new feature on MT. I would like to be able to use it to add an AS hop to advertisements sent via one peer.

/routing bgp network
add disabled=no network=10.2.19.0/24 synchronize=no
add disabled=no network=10.2.20.0/24 synchronize=no
add disabled=no network=69.39.116.64/27 synchronize=no
/routing bgp peer
add address-families=ip comment="" default-originate=never disabled=no \
    hold-time=1m in-filter="" instance=default multihop=no name=hatchet \
    nexthop-choice=default out-filter="" remote-address=69.39.98.97 \
    remote-as=65525 route-reflect=no tcp-md5-key="" ttl=255
add address-families=ip comment="" default-originate=never disabled=yes \
    hold-time=3m in-filter="" instance=default multihop=no name=longpond \
    nexthop-choice=default out-filter="" remote-address=69.39.116.73 \
    remote-as=65532 route-reflect=no tcp-md5-key="" ttl=255
add address-families=ip comment="" default-originate=never disabled=no \
    hold-time=1m in-filter="" instance=default multihop=no name=crummet \
    nexthop-choice=default out-filter=bgp-out remote-address=69.39.118.105 \
    remote-as=65531 route-reflect=no tcp-md5-key="" ttl=255

/routing filter
add action=passthrough chain=bgp-out comment="" disabled=yes invert-match=no \
    set-bgp-local-pref=122 set-bgp-prepend-path=1

/routing bgp instance
set default as=65524 client-to-client-reflection=yes comment="" disabled=no \
    ignore-as-path-len=no name=default out-filter="" redistribute-connected=\
    no redistribute-ospf=no redistribute-other-bgp=no redistribute-rip=no \
    redistribute-static=no router-id=0.0.0.0

at first glance that looks right. my opinion is that no matter what routing filters you have in place, even if you completely muck thinks up, shouldn’t cause a peer to go idle or down. Your bgp session should stay in place and you might not exchange routes properly but it shouldn’t tear down the session. I would followup with mt support, maybe grab a snapshot / capture of the bgp logging topic for when it happens so they can see all the details.

My experience with RouterOS and BGP so far has not been the best. If you apply filters to live peers the peers tend to go idle and the routing module usually crashed. When you have a big database of prefixes if you open the ip routes from winbox the router crashes and needs reboot. And I’ve noticed that on 3.20 the routing module drops all the peers and starts from scratch again at least once every few days. I send an email to support but they said wait for 3.22 not much has change I guess.

Most probably for BGP I will drop back to 3.13.

Sotiris

wait for 3.23, maybe this issue will be fixed.
Version 3.23 is running on demo.mt.lv already.