03-26-2020 08:02 AM
Hi All
If we have 3 routers, A, B ,C
A has an IBGP peering to C, B is just running ospf so each BGP speaker can learn its neighbours.
I hear that if a packet comes into A, it still has to go via B, when it hits B it will get dropped.
Why is this? as the next hop for the packet would be C, its ibgp neighbour?
Does is not just route it to the next hop in the bgp table which would be C? or would the next hop show as B?
Cheers
Solved! Go to Solution.
09-18-2024 07:18 AM
To summarize the key point is every router makes its routing decision based on that router's routing information.
I.e. in OP case, it matters not what routers A and C know, routing on router B depends on what router B knows.
What I believe confused OP, routers A and B know how to reach router C as a destination, which is half the equation why iBGP peering works (the other half of the equation is return path - both directions provided by OSPF), but router B doesn't directly obtain route prefixes known to iBGP, since it's not an iBGP peer. Unless an iBGP route prefix is provided to router B, in some other manner, it will drop unknown destination network packets.
Does router B need to know every route prefix that's in iBGP (to forward all iBGP transit traffic)? Possibly not, very much an "it depends" answer. But, again, any transit packet, for which a next hop is unknown for destination, will be dropped.
03-26-2020 08:43 AM
Hi,
The only default BGP loop prevention mechanism is the AS-path, being an AS-path distance vector protocol at its origin; when you get an BGP update and see your own AS in the AS path, you drop it. Now, with IBGP updates, as updates would travel within the same AS, there is no AS being added in the updates, so there would be impossible for BGP to detect loops, thus, by default, in order to prevent loops, if B sends an IBGP update to A, A cannot send it further to any other IBGP neighbors, unless A is a route-reflector. So the route-reflector allows you to reflect IBGP updates (get an IBGP update from X and reflect it, send it further to Y via IBGP as well), and because it open the chance for loops, it adds two more attribute to the reflected routes, which are used not only in best-path selection, but more importantly in loop prevention; these two attributes are the "Cluster List" and "Originator ID".
Regards,
Cristian Matei.
03-26-2020 11:26 AM
03-26-2020 11:37 AM
Hi,
I think you rear to the synchronzation feature, before having RR. If the physical path is A--->B--->C, and only B and C run BGP, even though the control-plane converges (routes get installed via BGP in the RIB of A and C for let's say a prefix of 10.10.10.0/24 learned by C from A), when C forwards a packet for 10.10.10.x towards B (cause the next-hop of the BGP route which is C is reachable via B), B will drop the data packet, as B does not run BGP and does not have the route in the RIB (unless you redistributed the eBGP learned routes into your IGP so that also B has a route).
Regards,
Cristian Matei.
03-26-2020 01:14 PM
would this not use recursive route lookups?
so are you saying that router B would need to know whatever are in the routing tables of A and C ?
what would the routing table look like on A for this route?
03-26-2020 01:32 PM
Hi,
Imagine that in the setup of A---->B----->C, you run some IGP on interconnects, your peer BGP between A and C on the interconnects, you advertise some loopback addresses over BGP. A will have a BGP route in its RIB for the Loopback of C, with a next-hop of C's IP on the interconnect with B, so C will route any packets for the Loopback of C via B, cause this is how it knows to route for the next-hop of the BGP route. When B receives the packet destined for C's Loopback, it will drop it as it has no route, those Loopbacks are advertised only by BGP.
BGP is an overlay protocol, usually peerings are multi-hop, and the transit network which means routers not running BGP (unless it's MPLS or any other tunnelling), needs to also have those routes known.
Regards,
Cristian Matei.
03-27-2020 07:37 AM
Thanks for that,
could you explain how the MPLS tunnelling works? why don't the core IGP routers need to know all the routes and allow them to peer direct? is that because of the first initial label imposed by the PE router will just get the label that matches the IP of the next hop router?
Also one last question, in the mpls scenario, do all the PE routers generally peer with each other in a full mesh, especially in an MPLS-VPN network?
cheers
03-30-2020 10:15 AM
Hi,
1. Not sure if i understood this clearly, but if you're asking how come the P routers don't need to know all routes, yes it is because of the outer/top MPLS label which identifies the Loopback address of the PE's for BGP peering, and these Loopbacks are advertised in IGP (IS-IS), so all P routers have labels for those Loopbacks and can perform MPLS label switching; the P routers don't see and care the inner/VPN/customer label.
2. Unless you're an ISP with 3 routers, your PE's will run as route-reflector clients and peer up iBGP not in between, but only with the Route Reflectors for for VPN routes.
Regards,
Cristian Matei.
09-18-2024 03:58 AM
In the article I read it doesn't need router B to know all the routes but in reality it will not work, router B has to know all the routes passing in order to forward traffic between router A and C. Why there are confusion what really the exact configuration for this scenario. In real world this will never work unless let router B also know learned routes.
09-18-2024 06:17 AM - edited 09-18-2024 06:26 AM
Hello @rcasinillo1976 ,
>> In real world this will never work unless let router B also know learned routes.
yes RB in the middle of the path if it is not speaking BGP at all requires to know how to route traffic because packets sent from RA to RC have RC as BGP next-hop , but BGP next-hop is reached via OSPF via RB and traffic is in clear text not tunneled inside an MPLS stack or a GRE or other type of tunneling ( think of VXLAN for example or L2TPv3).
The same happens for packets sent from RC to RA.
Actually it is really simple.
BGP next-hop recursion makes the BGP next-hop reachable and it allows to setup the iBGP session but user traffic travels in clear text. BGP provides only the control plane not the data plane.
This scenario helps to understand the concepts of control plane and data plane.
Hope to help
Giuseppe
09-18-2024 07:18 AM
To summarize the key point is every router makes its routing decision based on that router's routing information.
I.e. in OP case, it matters not what routers A and C know, routing on router B depends on what router B knows.
What I believe confused OP, routers A and B know how to reach router C as a destination, which is half the equation why iBGP peering works (the other half of the equation is return path - both directions provided by OSPF), but router B doesn't directly obtain route prefixes known to iBGP, since it's not an iBGP peer. Unless an iBGP route prefix is provided to router B, in some other manner, it will drop unknown destination network packets.
Does router B need to know every route prefix that's in iBGP (to forward all iBGP transit traffic)? Possibly not, very much an "it depends" answer. But, again, any transit packet, for which a next hop is unknown for destination, will be dropped.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide