The CCR is a virtual router that delivers comprehensive WAN gateway and network services into virtual and cloud environments.
The CCR enables enterprises to extend their WANs into provider-hosted clouds. Two CCRs are required for Cisco Cloud Network
Controller solution.
The Cisco Catalyst 8000V on Cisco Cloud Network Controller supports the following licensing models:
Bring Your Own License (BYOL) Licensing Model
Pay As You Go (PAYG) Licensing Model
BYOL Licensing Model
The BYOL licensing model on Cisco Catalyst 8000V which requires you to purchase your Catalyst 8000V Cisco DNA license from
Cisco and deploy it in the cloud.
For more information on different throughputs based on the tiers, see Throughput.
Cisco Cloud Network Controller makes use of the “Cisco DNA Advantage” subscription. For features supported by the “Cisco DNA
Advantage” subscription, see Cisco DNA Software SD-WAN and Routing Matrices.
PAYG Licensing Model
Beginning with the 25.0(4) release, Cisco Cloud Network Controller supports Pay-As-You-Go (PAYG) Licensing Model on Cisco
Catalyst 8000V which allows users to deploy a Catalyst 8000V instance in the cloud based on the VM size and purchase the usage
on an hourly basis.
As you completely depend on the VM size to get the throughput, the PAYG licensing model can be enabled only by first un-deploying
the current Cisco Catalyst 8000V and then re-deploying it using the First Time Set Up with the new VM size. For more information,
see the chapter "Configuring Cisco Cloud Network Controller Using the Setup Wizard" in the Cisco Cloud Network Controller for AWS Installation Guide
Note
The procedure for switching between licenses can also be used if you would like to switch between the two licensing types
available.
Note
There are two PAYG options for consuming licenses in the AWS marketplace: Catalyst 8000V Cisco DNA Essentials and Catalyst 8000V Cisco DNA Advantage. Cisco Cloud Network Controller will make use of Catalyst 8000V Cisco DNA Advantage. For features supported by the “Cisco DNA Advantage” subscription, see Cisco DNA Software SD-WAN and Routing Matrices
Throughput
The Cisco Catalyst 8000V on Cisco Cloud Network Controller supports the following licensing models:
Bring Your Own License (BYOL) Licensing Model
Pay As You Go (PAYG) Licensing Model
1. Bring Your Own License (BYOL)
For this model, the Cisco Catalyst 8000V supports tier-based (T0/T1/T2/T3) throughput options. The following table lists what
AWS EC2 instance is used for different router throughput settings for the Cisco Catalyst 8000V:
CCR Throughput
AWS EC2 Instance
T0 (up to 15M throughput)
c5.xlarge
T1 (up to 100M throughput)
c5.xlarge
T2 (up to 1G throughput)
c5.xlarge
T3 (up to 10G throughput)
c5.9xlarge
Tier2 (T2) is the default throughput supported by Cisco Cloud Network Controller.
2. Pay-As-You-Go Licensing Model
For this model, Cisco Cloud Network Controller supports a range of AWS EC2 instances for cloud networking needs powered by
Cisco’s Catalyst 8000V virtual router.
The table below shows the cloud instance type supported by Cisco Cloud Network Controller on AWS.-
デフォルトで CCR インターフェイスはプライベート IP アドレスのみが割り当てられ、パブリック IP アドレスを CCR インターフェイスに割り当てることはオプションとなりました。プライベート IP アドレスは、常に CCR のすべてのインターフェイスに割り当てられます。CCR
の GigabitEthernet1 のプライベート IP アドレスは、BGP および OSPF ルーター ID として使用されます。
Communicating to External Sites From Regions Without a CCR
Support is available for communication with an external site from regions without a CCR. This is accomplished by making use
of the AWS Transit Gateway feature. When you enable the AWS Transit Gateway feature on Cisco Cloud Network Controller, you
also enable peering between all managed regions on AWS. In this way, the AWS Transit Gateway peering feature allows the Cisco
Cloud Network Controller to address the issue of communicating with external sites from regions without a CCR. It addresses
this issue by having traffic rerouted to a region with a CCR.
Using the AWS Transit Gateway feature, when traffic from a region without a CCR tries to egress out of a site, this traffic
will be routed to the infra VPC for the closest region with a CCR. After the traffic is rerouted to that region's infra VPC,
that CCR is used to egress out the packet. For ingress traffic, packets coming from an external site can reach any region's
CCR and then be routed to the destination region using the AWS Transit Gateway peering in the ingress data path.
In these situations, traffic is rerouted automatically when the system recognizes that external traffic is egressing or ingressing
through a region without a CCR. However, you must have the following components configured in order for the system to automatically
perform this rerouting task:
CCRs must be deployed in at least one region. Even though this enhancement allows you to communicate with an external site
from a region that does not contain a CCR, in order to do this, you must have another separate region that does contain a CCR so that traffic can be rerouted from the region without a CCR to the region with a CCR.
The following figure shows an example scenario where traffic is rerouted automatically when the system recognizes that external
traffic is egressing from a region without a CCR.
The following occurs when the Cisco Cloud Network Controller recognizes that Region 2 does not have a CCR, but traffic is
egressing out to an external site (shown with the green arrow and circles):
Traffic flow begins egressing out from the CIDR in App-1 in Region 2 to a remote site. Note that the endpoint is configured
with the appropriate outbound rule to allow the remote site CIDR.
The VPC 2 egress route table has the remote site CIDR, which then has the AWS Transit Gateway as the next hop. The AWS Transit
Gateway information is programmed automatically based on the configured contracts.
A 0.0.0.0/0 route is inserted in the AWS Transit Gateway route table, which essentially tells the system to take the AWS Transit
Gateway peering attachment if traffic is egressing out to an external site but there is no CCR in this region. In this situation,
the AWS Transit Gateway peering attachment goes to another region that does have a CCR (Region 1 in the example scenario).
The region with a CCR that will be used is chosen based on geographical proximity to the region that does not have a CCR.
The packet is first forwarded to the infra VPC in the region with the CCR (Region 1), and is then forwarded to the gigabit
ethernet network interface on the CCR that is associated with the appropriate VRF group.
The gigabit 2 inbound security group on the CCR in Region 1 is configured to allow traffic from the remote region VPC.
It's useful to note that in the egress example shown above:
For steps 1 and 2, there is no change from pre-release 5.2(1) behavior.
Step 3 is behavior that is new and unique to this feature in release 5.2(1), where the redirect occurs to the TGW peering
attachment from the region without a CCR to the region with a CCR. In addition, step 3 occurs on the AWS cloud.
Steps 4 and 5 would normally occur in Region 2 before release 5.2(1), but only if Region 2 had a CCR. However, because Region
2 does not have a CCR, with this feature in release 5.2(1), these steps are taking place in Region 1 where a CCR is present.
The following figure shows an example scenario where traffic is rerouted automatically when the system recognizes that external
traffic is ingressing to a region without a CCR.
The following occurs when the Cisco Cloud Network Controller recognizes that Region 2 does not have a CCR, but traffic is
ingressing in from an external site to a CIDR in App-1 in Region 2 (shown with the blue arrow and circles):
Normally, the CCR in Region 1 would only advertise the CIDRs that are local to that region. However, with this enhancement
that is part of release 5.2(1), all CCRs in all regions now advertise CIDRs from all remote regions. Therefore, in this example,
the CCR in Region 1 will also advertise the CIDRs that are in Region 2 (assuming AWS Transit Gateway peering is configured
between both regions and the contracts are configured correctly). In this situation, the traffic ingresses in from an external
site to the CCR in Region 1, where the CCR in Region 1 advertises the static route for the remote region VPC CIDRs.
The infra route table (the AWS Transit Gateway route table in Region 1) has the next hop to the AWS Transit Gateway peering
attachment to Region 2.
It's useful to note that in the ingress example shown above:
Both steps (steps 1 and 2) in the ingress example shown above are new and unique to this feature in release 5.2(1).
Step 1 in the ingress example shows configurations programmed on the CCR.
Step 2 in the ingress example occurs on the AWS cloud.