+
+.. _bgp-multiple-autonomous-systems:
+
+Multiple Autonomous Systems
+---------------------------
+
+FRR's BGP implementation is capable of running multiple autonomous systems at
+once. Each configured AS corresponds to a :ref:`zebra-vrf`. In the past, to get
+the same functionality the network administrator had to run a new *bgpd*
+process; using VRFs allows multiple autonomous systems to be handled in a
+single process.
+
+When using multiple autonomous systems, all router config blocks after the
+first one must specify a VRF to be the target of BGP's route selection. This
+VRF must be unique within respect to all other VRFs being used for the same
+purpose, i.e. two different autonomous systems cannot use the same VRF.
+However, the same AS can be used with different VRFs.
+
+.. note::
+
+ The separated nature of VRFs makes it possible to peer a single *bgpd*
+ process to itself, on one machine. Note that this can be done fully within
+ BGP without a corresponding VRF in the kernel or Zebra, which enables some
+ practical use cases such as :ref:`route reflectors <bgp-route-reflector>`
+ and route servers.
+
+Configuration of additional autonomous systems, or of a router that targets a
+specific VRF, is accomplished with the following command:
+
+.. index:: router bgp ASN vrf VRFNAME
+.. clicmd:: router bgp ASN vrf VRFNAME
+
+ ``VRFNAME`` is matched against VRFs configured in the kernel. When ``vrf
+ VRFNAME`` is not specified, the BGP protocol process belongs to the default
+ VRF.
+
+An example configuration with multiple autonomous systems might look like this:
+
+.. code-block:: frr
+
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 20
+ neighbor 10.0.0.2 remote-as 30
+ !
+ router bgp 2 vrf blue
+ neighbor 10.0.0.3 remote-as 40
+ neighbor 10.0.0.4 remote-as 50
+ !
+ router bgp 3 vrf red
+ neighbor 10.0.0.5 remote-as 60
+ neighbor 10.0.0.6 remote-as 70
+ ...
+
+In the past this feature done differently and the following commands were
+required to enable the functionality. They are now deprecated.
+
+.. deprecated:: 5.0
+ This command is deprecated and may be safely removed from the config.
+
+.. index:: bgp multiple-instance
+.. clicmd:: bgp multiple-instance
+
+ Enable BGP multiple instance feature. Because this is now the default
+ configuration this command will not be displayed in the running
+ configuration.
+
+.. deprecated:: 5.0
+ This command is deprecated and may be safely removed from the config.
+
+.. index:: no bgp multiple-instance
+.. clicmd:: no bgp multiple-instance
+
+ In previous versions of FRR, this command disabled the BGP multiple instance
+ feature. This functionality is automatically turned on when BGP multiple
+ instances or views exist so this command no longer does anything.
+
+.. seealso:: :ref:`bgp-vrf-route-leaking`
+.. seealso:: :ref:`zebra-vrf`
+
+
+.. _bgp-views:
+
+Views
+-----
+
+In addition to supporting multiple autonomous systems, FRR's BGP implementation
+also supports *views*.
+
+BGP views are almost the same as normal BGP processes, except that routes
+selected by BGP are not installed into the kernel routing table. Each BGP view
+provides an independent set of routing information which is only distributed
+via BGP. Multiple views can be supported, and BGP view information is always
+independent from other routing protocols and Zebra/kernel routes. BGP views use
+the core instance (i.e., default VRF) for communication with peers.
+
+.. index:: router bgp AS-NUMBER view NAME
+.. clicmd:: router bgp AS-NUMBER view NAME
+
+ Make a new BGP view. You can use an arbitrary word for the ``NAME``. Routes
+ selected by the view are not installed into the kernel routing table.
+
+ With this command, you can setup Route Server like below.
+
+ .. code-block:: frr
+
+ !
+ router bgp 1 view 1
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.2 remote-as 3
+ !
+ router bgp 2 view 2
+ neighbor 10.0.0.3 remote-as 4
+ neighbor 10.0.0.4 remote-as 5
+
+.. index:: show [ip] bgp view NAME
+.. clicmd:: show [ip] bgp view NAME
+
+ Display the routing table of BGP view ``NAME``.
+
+