Bgp Received-routes vs. Accepted-routes
Notes from work. And again about BGP.
Today, I'm thinking about the functionality of Route-Refresh. We need it in order not to break the connection with the neighbor, not to reset the routing table, not to interrupt services, but simply to re-request routes. And she is already seven years in vow.
For example, one of the most frequent situations where this functionality is required is policy update.
')
So, there is a policy for importing routes into the routing table - it filters, for example, all prefixes longer than 23 bits, that is, / 24 no longer passes and does not fall into the TM. Then we bang - and we change the rule - we decided to block only prefixes longer than 25. And / 24 then they should already be imported.
Then BGP quickly re-queries them and applies the updated policy.
Actually, in view of the unprecedented convenience of this possibility, an alternative way to apply the policy without interrupting the BGP session was abolished on the Huavea: keep all the routes received from the neighbor.
It is time to say that there are two BGP tables:
- received routes - stores everything.
- approved routes - stores only what is left after the application of policies (and meets other BGP requirements).
And there are even two commands that allow you to view these tables.
However, in connection with the abolition they show the same thing. To save memory, routes that did not pass checks are not stored in the table of received routes. And if necessary, re-requested through Route Refresh.
You can turn off this mode with the peer keep-all-routes command (for a specific, as you understand, neighbor - because you do not produce more than necessary - Occam). For example, if a neighbor does not support Route-Refresh (such troglodytes still exist?)
Well, if supported, it is not necessary to include keep-all-routes. Technically and vice versa, if you keep all the routes, then you can not re-request, but who will turn it off - it’s the basic BGP functionality (almost).
These two functions or, if you wish, call them behavioral features, are interrelated, but, strictly speaking, are not complete synonyms.
For example, having a Route-refresh, you might want to see the full list in the table of the routes received from a neighbor before filtering to see how the policies work.
Today, I'm thinking about the functionality of Route-Refresh. We need it in order not to break the connection with the neighbor, not to reset the routing table, not to interrupt services, but simply to re-request routes. And she is already seven years in vow.
For example, one of the most frequent situations where this functionality is required is policy update.
')
So, there is a policy for importing routes into the routing table - it filters, for example, all prefixes longer than 23 bits, that is, / 24 no longer passes and does not fall into the TM. Then we bang - and we change the rule - we decided to block only prefixes longer than 25. And / 24 then they should already be imported.
Then BGP quickly re-queries them and applies the updated policy.
Actually, in view of the unprecedented convenience of this possibility, an alternative way to apply the policy without interrupting the BGP session was abolished on the Huavea: keep all the routes received from the neighbor.
It is time to say that there are two BGP tables:
- received routes - stores everything.
- approved routes - stores only what is left after the application of policies (and meets other BGP requirements).
And there are even two commands that allow you to view these tables.
display bgp routing-table peer ipv4-address received-routes display bgp routing-table peer ipv4-address accepted-routes However, in connection with the abolition they show the same thing. To save memory, routes that did not pass checks are not stored in the table of received routes. And if necessary, re-requested through Route Refresh.
You can turn off this mode with the peer keep-all-routes command (for a specific, as you understand, neighbor - because you do not produce more than necessary - Occam). For example, if a neighbor does not support Route-Refresh (such troglodytes still exist?)
Well, if supported, it is not necessary to include keep-all-routes. Technically and vice versa, if you keep all the routes, then you can not re-request, but who will turn it off - it’s the basic BGP functionality (almost).
These two functions or, if you wish, call them behavioral features, are interrelated, but, strictly speaking, are not complete synonyms.
For example, having a Route-refresh, you might want to see the full list in the table of the routes received from a neighbor before filtering to see how the policies work.
Source: https://habr.com/ru/post/321180/
All Articles