Avaya 8800 Planning And Engineering, Network Design page 146

SPBM design guidelines
As illustrated in the figure above, the green VRF on 8600C is configured to advertise its local/direct
IP routes into IS-IS within I-SID 13990001; the VRF on node 8600D, which is also a member of the
same I-SID, installs these IP routes in its VRF IP routing table with a next-hop B-MAC address of
8600C. Therefore, when the VRF on node 8600D needs to IP route traffic to the IP subnet off
8600C, it performs a lookup in its IP routing table and applies a MAC-in-MAC encapsulation with B-
MAC DA of 8600C. The SPBM core ensures delivery to the egress BEB 8600C where the
encapsulation is removed and the packet is IP routed onwards.
Note:
Like the IP Shortcut service, there are only two IP routing hops (ingress BEB and egress BEB)
as the SPBM backbone acts as a virtualized switching backplane.
F—L3 VSN
The figure above shows two VRFs (green and red) to illustrate that the BEBs can associate I-SIDs
with multiple VRFs. The L3 VSN option provides IP connectivity over SPBM for all of your VRFs.
G—L2 VSN and L3 VSN
The figure above shows both an L2 VSN and an L3 VSN to show that you can configure both
options on the same BEBs. This topology is simply made up of a number of BEBs that terminate
VSNs of both types. What this example shows is the flexibility to extend one or more edge VLANs
(using one or more L2 VSNs) to use a default gateway that is deeper into the SPBM core. From
here, traffic can then be IP routed onwards as either non-virtualized with IP Shortcuts or, as shown
in this example, with a virtualized L3 VSN. Note that in this example the central node 8600G is now
also acting as BEB for both service types as it now maintains both a MAC table for the L2 VSN it
terminates and an ARP cache and IP routing table for the L3 VSN it also terminates.
H—IP VPN-Lite over SPBM
IP VPN-Lite over SPBM switches IP-in-IP packets in the SPBM core. This option is similar to the
traditional 2547 VPN with BGP running between the GRTs to exchange routes between the VRFs.
The VRFs themselves are identified by the BGP communities configured for the VRFs. However,
unlike the 2547 VPNs, the VPN-Lite model does not use MPLS labels to identify the edge node or
the VRF, nor does it use the MPLS transport. Instead it maps a service label, which is an IP
address, to each VRF and uses IP-in-IP encapsulation with the outer IP being the service label for
the VRF. SPBM switches the IP-in-IP packet in the core by looking up the service label and applying
the B-MAC header corresponding to the particular IP service label. IP VPN-Lite can work over any
IP routed backbone. In this case it is simply running above the native IP Shortcuts that SPBM
provides.
IP VPN-Lite over SPBM also enables you to use hub and spoke configurations by manipulating the
import and export Route Target (RT) values. For example, this allows a server frame in a central site
to have connectivity to all spokes but no connectivity between the spoke sites. You only have to
configure BGP on the BEBs. The BCBs have no knowledge of any Layer 3 VPN IP addresses or
routes.
Multiple tenants using different SPBM services
The following figure shows multiple tenants using different services within an SPBM metro network.
In this network, you can use some or all of the SPBM implementation options to meet the needs of
the community while maintaining the security of information within VLAN members.
June 2016 Planning and Engineering — Network Design
Comments on this document? infodev@avaya.com
146