Showing results for 
Search instead for 
Did you mean: 

Mixing Single- and Multi-Instance BGP speaker in a network

Cisco Employee
Multi-Instance BGP is a IOS-XR feature that allows running multiple BGP processes on a router to increase BGP scalability by each BGP process owning its own memory space. Each BGP process requires its own BGP router-id and Loopback interface for BGP peerings.
Customers are moving to using Multi-Instance BGP on XR-based RR's to increase overall scale. Often the PE routers remain with a single BGP instance (including single Loopback for BGP peering). For large SPs it would be very painful to provide multiple BGP Peering addresses, therefore multiple Next-hop addresses, to the same PE (increased IGP, reduced IP LFA performance, difficult traffic engineering).
The current BGP implementation did not allow Multi-Instance speaker (MI) peering to Single-Instance speaker (SI) with single Loopback on SI side. Such a scenario can work reliable, only when the MI side configures its BGP sessions towards the SI side with "session-open-mode active-only". This way the MI side will reject all BGP Session attempts initiated by the SI speaker. The BGP session will always be opened by the MI speaker.
BGP sessions between MI speaker can still be configured with the default BGP session settings, i.e. each peer operating in active/passive mode.
Configuration pitfalls:
A special check in the BGP code attempts to prevent a setup, where multiple BGP instances of the MI speaker peer to the same Peer address. This check can be bypassed, when the same peer is configured in all BGP instances with a single commit.
CSCur35196 relaxes this restriction by allowing such configuration with multiple commits, but printing a syslog message to notify the operator of the need to use "session-open-mode active-only".
CSCur45452 is tracking investigations to allow the default active/passive mode in a mixed MI/SI speaker setup (long-term).
Content for Community-Ad

This widget could not be displayed.