Hello @timakumar-dd5hw The AS path is typically used to manipulate inbound traffic by influencing how external networks choose the path to your AS. This is typically done by manipulating the AS path attribute in the prefixes you advertise to your peer networks on neighboring ASes. Remember, this influences, but does not conclusively change the behavior, because your neighboring ASes can always override your changes. LOCAL AS path manipulation cannot be used to influence outgoing traffic, because it's something you advertise to neithbgoring ASes and affects how other ASes reach your AS... I hope that helps!
Thank you so much for answering my question! I've got one more, if you don't mind. I have a following topology Cisco C3750X stack: advertises networks 10.5.0.0/24, 10.5.1.0/24, 10.5.4.0/23 and 10.5.6.0/23 to BGP. Mikrotik CCR2116 (ROS 7.14.3): is connected to Cisco C3750X via 10.5.0.0/24 network and has iBGP adjacency with it. Also, has a GRE tunnel to Mikrotik CCR1009 with internal tunnel addressing 172.31.1.0/30, where OSPF (area 0) is established. Mikrotik CCR1009 (mentioned above, with ROS6): tunnel to CCR2116 mentioned above with OSPF inside of it, and it learns a huge amount of OSPF routes from the rest of the network. CCR2116 (mentioned above) has redistribution from BGP to OSPF and backwards configured in the following way: it has an address list BGP_OUT which, for now, has only networks 10.5.0.0/24, 10.5.1.0/24, 10.5.4.0/23 and 10.5.6.0/23, redistributes addresses in this list from BGP to OSPF via out filter, and learns (and distributes to BGP backwards) everything NOT in this list via OSPF in filter. Everything seems to be working fine, except for one detail. The issue is that BGP redistributes to OSPF everything in the BGP_OUT list except 10.5.0.0/24 network, which is listed as BGP route in the CCR2116 route table but is labeled as inactive, because it is already listed there as connected route. If I enable "redistribute connected" to OSPF, it works. I wonder if it's a normal behavior for BGP and OSPF (not redistributing an inactive, yet existing BGP route) or a Mikrotik bug? Thanks in advance!
It was my pleasure to answer your question! As for your additional question, I hope that I have understood it. The behavior you are seeing is expected. The Mikrotik CCR2116 sees the network 10.5.0.0/24 as both a connected route and a BGP-advertised route. When a route is present as both connected and BGP-learned, the router gives preference to the connected route. In Mikrotik’s implementation, if a BGP-learned route is inactive (i.e., it’s present but overshadowed by a connected route), that route will not be redistributed into OSPF unless explicitly configured to redistribute connected routes. Does that make sense?
Thanks alot Lazarus for the explanation 👍
My pleasure!
Hi Can we use AS path for both inbound and outbound traffic manupulation
Hello @timakumar-dd5hw The AS path is typically used to manipulate inbound traffic by influencing how external networks choose the path to your AS. This is typically done by manipulating the AS path attribute in the prefixes you advertise to your peer networks on neighboring ASes. Remember, this influences, but does not conclusively change the behavior, because your neighboring ASes can always override your changes.
LOCAL AS path manipulation cannot be used to influence outgoing traffic, because it's something you advertise to neithbgoring ASes and affects how other ASes reach your AS... I hope that helps!
amazing video !!
Glad you liked it!!
Thank you so much for answering my question!
I've got one more, if you don't mind.
I have a following topology
Cisco C3750X stack: advertises networks 10.5.0.0/24, 10.5.1.0/24, 10.5.4.0/23 and 10.5.6.0/23 to BGP.
Mikrotik CCR2116 (ROS 7.14.3): is connected to Cisco C3750X via 10.5.0.0/24 network and has iBGP adjacency with it. Also, has a GRE tunnel to Mikrotik CCR1009 with internal tunnel addressing 172.31.1.0/30, where OSPF (area 0) is established.
Mikrotik CCR1009 (mentioned above, with ROS6): tunnel to CCR2116 mentioned above with OSPF inside of it, and it learns a huge amount of OSPF routes from the rest of the network.
CCR2116 (mentioned above) has redistribution from BGP to OSPF and backwards configured in the following way: it has an address list BGP_OUT which, for now, has only networks 10.5.0.0/24, 10.5.1.0/24, 10.5.4.0/23 and 10.5.6.0/23, redistributes addresses in this list from BGP to OSPF via out filter, and learns (and distributes to BGP backwards) everything NOT in this list via OSPF in filter.
Everything seems to be working fine, except for one detail. The issue is that BGP redistributes to OSPF everything in the BGP_OUT list except 10.5.0.0/24 network, which is listed as BGP route in the CCR2116 route table but is labeled as inactive, because it is already listed there as connected route. If I enable "redistribute connected" to OSPF, it works.
I wonder if it's a normal behavior for BGP and OSPF (not redistributing an inactive, yet existing BGP route) or a Mikrotik bug?
Thanks in advance!
It was my pleasure to answer your question! As for your additional question, I hope that I have understood it.
The behavior you are seeing is expected. The Mikrotik CCR2116 sees the network 10.5.0.0/24 as both a connected route and a BGP-advertised route. When a route is present as both connected and BGP-learned, the router gives preference to the connected route. In Mikrotik’s implementation, if a BGP-learned route is inactive (i.e., it’s present but overshadowed by a connected route), that route will not be redistributed into OSPF unless explicitly configured to redistribute connected routes. Does that make sense?
@@telecomTech.explained it absolutely does, just required an additional clarification. Thank you so much!