CONFIGURATION GUIDE

CGNAT-BYPASS SUPPORT on MNA

December 2023
Copyright & Trademarks

© 2023 Meta Platforms, Inc. All rights reserved.

CGNAT-BYPASS SUPPORT | 2
Table of Contents
COPYRIGHT & TRADEMARKS........................................................................................................... 2

Table of Contents ............................................................................................................... 3

1. Introduction ..................................................................................................................... 4
HIGH-LEVEL DESCRIPTION .............................................................................................................. 4

A SIMPLE CGNAT-BYPASS EXAMPLE ............................................................................................ 5

2. Requirements.................................................................................................................. 6
PRIVATE IP SPACE .......................................................................................................................... 6

PREFIX GROUP CONFIGURATION .................................................................................................... 6

NETWORK CONNECTIVITY / ROUTING CONFIGURATION..................................................................7

3. Examples .......................................................................................................................... 8
EXAMPLES OF VALID IMPLEMENTATIONS ....................................................................................... 8

EXAMPLES WITH MULTIPLE NETWORKS.......................................................................................... 9

EXAMPLES OF INVALID IMPLEMENTATIONS .................................................................................. 10

EXAMPLE OF A FAILOVER IMPLEMENTATION ................................................................................. 12

4. Implementation ............................................................................................................ 15

5. How can you check if it’s working? ............................................................................ 18

6. How to make changes or remove configuration? ................................................... 20

7. Glossary.......................................................................................................................... 20

8. Useful links .....................................................................................................................21

9. FAQ ..................................................................................................................................21

CGNAT-BYPASS SUPPORT | 3
1. Introduction
There are multiple possible ways networks might implement Carrier-Grade Network
Address Translation (CGNAT or CGN). And there are different ways a CDN, such as Meta’s,
can interact with CGNAT. This document will explain in detail the requirements and
conditions under which you may successfully implement CGNAT bypass with Meta
Network Appliance (MNA) caches in your network.

To properly support CGNAT bypass when subscriber devices (phones, computers, etc)
connect with MNAs, Meta needs to know the private user IP prefixes as well as public
CGNAT IP prefixes used by the same set of users. In other words, MNAs need to know how
to translate private to public IP addresses in your network and at each location to enable
efficient traffic targeting.

We support a BGP community-based scheme for ISPs to inform Meta about such private
and public prefix grouping via route announcements.

High-level description

Prefix Group. A Prefix Group contains private user IP prefixes and public CGNAT IP
prefixes used by the same set of users in an ISP network. It is possible to have multiple
Prefix Groups configured in a network and at any location, subject to requirements listed
in the next section.

BGP Community Values. Each Prefix Group from an ISP network is associated with a
unique BGP community value within this network. The BGP community value is picked by
the ISP from the range from 32934:10200 - 32934:10299.

Route Announcements. For each prefix within a Prefix Group, when the route is
announced to MNAs, the BGP community value associated with the Prefix Group
needs to be tagged. As a result, via BGP, the Prefix Group membership is
communicated to Meta.

CGNAT-BYPASS SUPPORT | 4
A simple CGNAT-bypass example

The figure in the next page shows how a hypothetical CGNAT-bypass traffic flow may look
like in an ISP network. In this example, clients are assigned with the 100.64.1.0/24
private IP space, and the CGNAT device is assigned with 1.2.3.0/24 public IP space.

Diagram 1

The dashed line represents the traffic that goes through CGNAT, and the solid line
denotes traffic that bypasses CGNAT.

By applying proper routing changes in your network, it is possible to connect client

devices directly to MNAs, bypassing the need to translate private/public IPs.

The client devices still use CGNAT public IPs to connect to Meta if direct routing is not
configured, such as connecting with Meta Point of Presents (PoPs). We do not support
CGNAT bypass to PoPs (peering, transit, etc.), we only support this feature on MNA
devices.

In this example, the Prefix Group as well as the BGP routes observed on MNA would be:
100.64.1.0/24:[32934:10200] (private)
1.2.3.0/24:[32934:10200] (cgnat public ipv4)

Note that this requires the ISP to configure their BGP export policy to include the
community tag 32934:10200 with both routes.

CGNAT-BYPASS SUPPORT | 5
2. Requirements

Private IP Space

Private user IP prefixes are required to be within RFC1918 and RFC6598 exclusively. If
appropriate for your usage, we recommend using the dedicated '100.64.0.0/10' CGN
space allocated in RFC6598.

Prefix Group Configuration

1. Addresses & prefixes

a. Each Prefix Group contains only one public IP prefix used for CGNAT.
b. Each Prefix Group contains one or more private user IP prefix.

c. Public IP address overlapping/reuse is not allowed among different Prefix Groups.

d. Private user IP address overlapping/reuse is allowed among different Prefix

Groups only when they are announced to different MNA clusters.

e. If there are multiple clusters in one same location, we expect them to receive the
exact same routes, and the same prefix group definitions. Clusters in the same
location are typically named using the same first five characters, which denote the
location. e.g., fxxx5-1 , fxxx5-2, fxxx5-3 etc

f. IMPORTANT: Do not advertise a default route (IPv4 0/0 and IPv6 ::/0) to any
cluster, especially if you are implementing CGNAT bypass.

g. IMPORTANT: the 32934: community tags are exclusively for prefixes of your own
ASN. Do not apply 32934: community tags to prefixes of downstream ASNs
(typically, transit customers). While you may advertise those prefixes to an MNA
cluster, please do not apply 32934: community tags to them.

h. IMPORTANT: we do not support using public IPv4 address as if they were private.
We rely on RPKI BGP origin validation and will not support bypass on any RPKI-
invalid routes. Only advertise public IPv4 routes that your ASN is the origin of.

2. BGP Community

CGNAT-BYPASS SUPPORT | 6
 a. A Prefix Group is required to be assigned with a unique BGP community value
within a network, picked from 32934:10200 - 32934:10299.

b. Route announcements for prefixes within the same Prefix Group should all
have the same BGP community value tagged.

c. IMPORTANT: Non-related prefixes should not be tagged with any BGP

community value in the specified range above. Only use these community tags
for CGNAT prefixes.

d. Do not use more than one prefix group community tag (32934:10200 -
32934:10299)per prefix. If you use more than one, our system will not be able
to determine which prefix group the prefix belongs to.

e. To implement failover scenarios, you may add the corresponding route

preference tag (32934:10000 - 32934:10012). Check the “BGP community
signaling” document from the Network Partner Portal for details about how to
communicate route preference to Meta.
f. Remember to only include only one public prefix in each prefix group per
cluster. Do not apply the same community tag to multiple public prefixes in a
cluster, as this may lead to suboptimal traffic allocation and congestion.

Network Connectivity / Routing Configuration

All public prefixes within a Prefix Group are required to be announced to all MNAs in an
MNA Group, where an MNA Group is defined as a set of MNAs serving the same set of
users with the same failover policy.

CGNAT-BYPASS SUPPORT | 7
3. Examples

Examples of valid implementations

Below we share multiple examples of valid implementations of CGNAT bypass, with one or
multiple MNAs in a network, and with one or multiple prefix groups.

One Prefix Group: only one MNA, private and public prefixes.

One Prefix Group: same public IP prefixes, same or different private IP prefixes on
multiple MNAs.

Multiple Prefix Groups: different public IP prefixes, same private IP prefixes.

For 1 MNA cluster

Ex. Valid Prefix Group Configurations Notes

1 MNA1 (ISP1): Minimal configuration

100.64.0.0/10:[32934:10200] (private)
1.2.3.0/24:[32934:10200] (cgnat public ipv4)

2 MNA1 (ISP1): Two Prefix Groups in one

10.0.0.0/8:[32934:10200] (private) cluster
1.2.3.0/24:[32934:10200] (cgnat public ipv4) • Note the different
100.64.0.0/10:[32934:10201] (private) BGP community
4.5.6.0/24:[32934:10201] (cgnat public ipv4) values

CGNAT-BYPASS SUPPORT | 8
 Multiple MNA clusters

Ex. Valid Prefix Group Configurations Notes

3 MNA1-1 (ISP1): One Prefix Group, two

10.0.0.0/8:[32934:10200] (private) clusters in same location
100.64.0.0/10:[32934:10200] (private) • Multiple private
1.2.3.0/24:[32934:10200] (cgnat public ipv4) prefixes
• One public prefix
MNA1-2 (ISP1): • Same routes
received at all
10.0.0.0/8:[32934:10200] (private)
clusters in the same
100.64.0.0/10::[32934:10200] (private)
location
1.2.3.0/24:[32934:10200] (cgnat public ipv4)

4 MNA1-1 (ISP1): One Prefix Group

100.64.0.0/10:[32934:10200] (private) • Partial private
1.2.3.0/24:[32934:10200] (cgnat public ipv4) prefixes at different
MNAs
MNA2-1 (ISP1):
10.0.0.0/8:[32934:10201] (private)
1.2.3.0/24:[32934:10201] (cgnat public ipv4)

5 MNA1 (ISP1): One ISP, two Prefix

10.0.0.0/8:[32934:10200] (private) Groups
1.2.3.0/24:[32934:10200] (cgnat public ipv4) • Private space reuse
within the same ISP
MNA2 (ISP1) if they are not
10.0.0.0/8:[32934:10201] (private) announced to any
common MNA.
4.5.6.7/24:[32934:10201] (cgnat public ipv4)

Examples with multiple networks

Organizations that manage multiple networks and have independent CGNAT

implementations in each, might be using the same private IP prefix with a different address
translation within each network.
This is supported, only if the translation to public prefixes is different in each case:

7 MNA1 (ISP1): Private IP reuse by

100.64.0.0/10:[32934:10200] (private) different ISPs; two
1.2.3.0/24:[32934:10200] (cgnat public ipv4) Prefix Groups
• Same private

CGNAT-BYPASS SUPPORT | 9
 MNA2 (ISP2): prefixes
100.64.0.0/10:[32934:10201] (private) • Different ISP
4.5.6.0/24:[32934:10201] (cgnat public ipv4) networks

Examples of invalid implementations

We share below a non-comprehensive list of misconfiguration examples. Please refer to

the validations on the Caching section on NPP to check if the configuration you have
applied has any misconfiguration.

Invalid Prefix Group Configurations Notes

MNA1 (ISP1): This refers to requirement 1a. The

10.0.0.0/8:[32934:10200] (private) error is having multiple public
100.64.0.0/10:[32934:10200] (private) prefixes in the same group. The
1.2.3.0/24:[32934:10200] (cgnat public ipv4) “many to many” configuration is
4.5.6.0/24:[32934:10200] (cgnat public ipv4) currently not supported.

MNA1 (ISP1): This refers to requirement 1a and

100.64.0.0/10:[32934:10201] (private) 1b and 2b.
1.2.3.0/24:[32934:10202] (cgnat public ipv4) The error here is having multiple
4.5.6.0/24:[32934:10203] (cgnat public ipv4) prefix groups with no translation
(only 1 prefix).
Each prefix group (same BGP
community tag) must have least 1
private and 1 public prefix.
MNA1 (ISP1): This refers to requirement 1d.
100.64.0.0/10:[32934:10201] (private) You can reuse private prefixes,
100.64.0.0/10:[32934:10202] (private) but not on same or common
1.2.3.0/24:[32934:10201] (cgnat public ipv4) MNAs. Do not include more than
4.5.6.0/24:[32934:10202] (cgnat public ipv4) one BGP community tag for the
same private prefix.
MNA1-1 (ISP1): This refers to requirement 1e.
10.0.0.0/8:[32934:10200] (private)
100.64.0.0/10:[32934:10200] (private) When applying the feature in
1.2.3.0/24:[32934:10200] (cgnat public ipv4) multiple clusters serving the
4.5.6.0/24:[32934:10200] (cgnat public ipv4) same location, Meta expects to
receive consistent

CGNAT-BYPASS SUPPORT | 10
 advertisements. Consider
MNA1-2 (ISP1): advertising the exact same set of
100.64.0.0/10::[32934:10200] (private) private and public prefixes with
1.2.3.0/24:[32934:10200] (cgnat public ipv4) the same BGP community tags
across all clusters.
MNA1 (ISP1): location A This refers to requirement 2a.
100.64.0.0/10:[32934:10200] (private)
1.2.3.0/24:[32934:10200] (cgnat public ipv4) We provide a range of BGP
communities that can be used, so
MNA2 (ISP1): location B you can assign a different BGP
100.64.0.0/10:[32934:10200] (private) community per location. Consider
using instead a different
4.5.6.0/24:[32934:10200] (cgnat public ipv4)
community value at each location

MNA3 (ISP1): location C

100.64.0.0/10:[32934:10200] (private)
7.8.9.0/24:[32934:10200] (cgnat public ipv4)

MNA1 (ISP1): This refers to requirement 2c.

100.64.0.0/10:[32934:10200] (private)
4.5.6.0/24:[32934:10200] (non cgnat publicDo not tag non-CGNAT public
ipv4 prefixes with bypass community
2a03:2880:0::/48:[32934:10200] (non cgnat public tags. If this public prefix has no
ipv6 relation with CGNAT, do not
apply prefix group tags to it.

Prefix group tags on IPv6 prefixes

are ignored
MNA1 (ISP1): location A Please check that private IP
100.60.0.0/18:[32934:10200] (not private!!) addresses are correctly private
1.2.3.0/24:[32934:10200] (cgnat public ipv4 prefixes.
The valid RFC 6598 private range
is 100.64.0.0/10 (100.64.0.0 to
100.127.255.255)
MNA1 (ISP1): Do not apply 32934: community
100.64.0.0/18:[32934:10200] (private) tags to default routes.
0/0: [32934:10200] (default route)

CGNAT-BYPASS SUPPORT | 11
Example of a failover implementation

This is an example of an ISP network with their IP topology and CGNAT distributed by
subregions, supported by multiple MNA clusters. The example illustrates how the ISP could
implement both CGNAT bypass support and failover scenarios with MNA.

For the failover scenarios, the example uses preference signalling with communities in the
range 32934:10008 to 32934:10012. There is nothing special about implementing
communities for location preference along with CGNAT bypass, and the example below
follows the guidelines stated in the Community Signalling document. Please check that
guide for a detailed explanation of location preference communities.

In this example, the ISP has their user prefixes distributed across 4 geographical regions:
NW, NE, SW, SE, with two MNA clusters support this network. The ISP has an IP
addressing plan aligned with their topology, where they have assigned a different /20
private network and a /24 public IPv4 network to each subregion.

By advertising the private/public prefix to each MNA cluster using different prefix group
community tags for each subregion, the ISP is enabling Meta to better target these users.

Diagram 2

CGNAT-BYPASS SUPPORT | 12
Let’s suppose this ISP wants to have the MNA2-1 (south) be a failover for traffic to users
in the north, in a scenario where MNA1-1 (north) went offline.

To support this, the ISP would have to advertise the north prefixes also to MNA2-1
(south). They could tag the north prefixes in the south cache with the low-preference
community tag 32934:10009 to signal that this is a less desired location, while also
adding the 32934:10012 (highest preference) to those that they prefer to keep locally.
And vice versa for the other cluster. Normally, this wouldn’t affect normal flow of traffic,
see example in diagram 3

Diagram 3: CGNAT bypass with location preference

In a situation where MNA1-1 went offline, then MNA2-1 could be able to support the
failover, see a possible result in Diagram 4. Of course, for this to work successfully other
conditions should be met: enough capacity (servers and uplinks) in the cluster to support
the increased demand, IP connectivity in the ISP backbone between the south-north
subregions with routing policies to support it, and enough capacity in this internal
connection of the ISP network to support the south>north traffic flow.

CGNAT-BYPASS SUPPORT | 13
Diagram 4: How failover could work

CGNAT-BYPASS SUPPORT | 14
4. Implementation

IMPORTANT:
This document provides a guideline on how to configure the advertisements to the
MNA. We do not provide guidance on internal routing configuration for the ISP. The
ISP is responsible for their internal routing policy and for the implementation of the
CGNAT bypass in their routers.

There are two essential things for the ISP to do:

- Update eBGP policies in the routers connected to MNA clusters, adding BGP
community tags only to the private & public prefixes in the CGNAT bypass. As
explained here, this allows Meta to learn about your CGNAT plan and better target
user prefixes.

- Apply the bypass in your routing to allow direct traffic from the MNA public IP
address to private IP user space.

Both things are necessary:

- If an ISP applies the bypass but doesn’t use prefix group community tags with the
MNA clusters, Meta may not target prefixes correctly. This could result in sub-
optimal allocation of prefixes to clusters (such as allocating traffic to a cluster
further away from the users).

- If an ISP advertises prefix group community tags to MNA clusters but doesn’t
update the routing to bypass the CGNAT for MNA traffic, then as a result the traffic
will remain in the public prefixes. Remember that Meta doesn’t do the bypass, only
the ISP can bypass CGNAT devices.

Step by step implementation:

1. Plan:
o Consider doing a small test with a small sample of your IP space. You can
check on NPP portal if Meta detects any invalid use of BGP communities.
o Choose the cluster(s) where you plan to implement the feature.

CGNAT-BYPASS SUPPORT | 15
 o IMPORTANT: if you have multiple clusters in one same location, all clusters
need to receive the exact same prefix routes, including the prefix group tags.
This is the case for clusters with identical names except for the dash number,
such as fxxx5-1 and fxxx5-2, -3 etc.
o Plan your prefix group(s): collect the list of private and public prefixes based
on your NAT plan. The more granularity, the better: different group numbers
for different locations. If your CGNAT implementation is regionalized (users in
one territory get different prefixes and translations), signal this to the cluster
by using separate prefix groups for each subset of private/public prefixes. If
Meta learns about this regionalization, it facilitates optimal targeting.
2. Update BGP:
o Update your BGP export policy with the selected MNA cluster(s), using the
prefix group community tags as indicated in the document.
o After a few hours, check NPP. As mentioned in section 5, the portal will show
the configuration status (it’s not real time, it takes an hour or so for Meta to
collect metrics and show them on NPP). Make sure the NPP CGNAT bypass
config validation passes a green checkmark. If there are any invalid config
alerts, make sure to fix the configuration errors found by the portal. You may
look at the cluster view page to check all the received tags per prefix in detail.
You can also download these as a CSV file, that might help you debug.
o Don't rush to execute the routing bypass in your CGNAT platform yet.
Experiment with the export policy until you see the desired result in NPP.
3. Update your routing to bypass CGNAT:
o It’s not enough to just advertise private IP space to the MNA. The essential
step to bypass is enabling it in your network to/from the IP prefixes of the
MNA clusters (you may find the IP addresses assigned to each cluster in the
cluster view page of NPP).
o Private IP traffic should no longer be sent to your CGNAT platform if the
origin or destination is the /26 IPv4 MNA prefix, so please apply a routing
policy based on this. This step is critical, only the ISP can implement the

CGNAT-BYPASS SUPPORT | 16
 bypass, by updating their routing policies. This update may be different for
each ISP and is highly dependent on routing and CGNAT are configured in
your network.
4. Verify:
o Come back to NPP to check if egress traffic for the selected cluster(s) has
shifted from public to private IP space. You can check this in the cluster view
page of each cluster, the top left widget shows the traffic egress time series
with a split of public/private IPs. You may reach the cluster view from
Caching section, clicking on the name of the cluster in the MNA Status table.

If you need support, open a ticket in the Support section of NPP. Our 24x7x365 support
team will assist you.

IMPORTANT:
You are always in control of when and how the bypass is implemented.
If you need to disable the bypass on MNA, simply update your routing policy and
remove the bypass, and stop advertising private prefixes to the cache.

CGNAT-BYPASS SUPPORT | 17
5. How can you check if it’s working?
Users that have access to the Meta Network Partner Portal (NPP) at
https://partners.facebook.com/network may check the status of the implementation in
each cluster. If you don’t have access, the administrator from your organization can grant
you user access to the NPP. It’s the same platform that was used to request the cluster.

CGNAT Bypass status

In the NPP Caching section at https://partners.facebook.com/network/app/MNA, the

MNA Status table has a column that shows the CGNAT Bypass status per cache, and also
the amount of public and private prefixes received in the BGP session.

Diagram 5: Caching table with flags for CGNAT bypass configuration

The column will show three possible values (green, yellow, red) depending on whether the
BGP prefix tagging is valid, not configured, or invalid. Hovering the mouse pointer over each
checkmark will show a tooltip with a summary of the status, and a list of violations if any.

Diagram 6: Tool tip showing details of configuration issues

CGNAT-BYPASS SUPPORT | 18
From the MNA Status table you may click on the name of any cluster to investigate more.
This will open a page with information for a specific cluster, where two are relevant to the
CGNAT bypass implementation: Traffic Overview and Prefix Announcements.

Traffic Overview

Use the settings cogwheel icon in this widget to select the “Egress” view. It will show the
egress traffic (MNA to users) time series split between private and public IP space traffic.

Here you may check if a recent configuration change, such as the bypass, has been
implemented successfully. Adding the bypass should result in an increase of private IP
egress and removing the bypass result in a decrease of private IP egress. Adding or
removing some prefixes will have a similar impact.

Diagram 7: Egress traffic split between Private and Public

Prefix Announcements

This table shows all the prefixes received in the BGP sessions as well as the communities
associated with them. Here you can verify how we are seeing the prefix grouping from the
point of view of that specific MNA cache.

Using the filter and sort features of the table might prove useful.

filter

sort

Diagram 8: Prefix table detail showing prefix group tags for a cluster

CGNAT-BYPASS SUPPORT | 19
6. How to make changes or remove configuration?
Simply update or remove the BGP communities from your prefix advertisement, stop
advertising private prefixes to the MNA and enable traffic through your CGNAT. Meta
doesn’t need to update configuration on the MNA. Any changes you make to routing or
BGP advertisement will be effective immediately.

Note: The graphs and tables in NPP portal may take an hour or more to show the result.

7. Glossary
CGNAT: (wikipedia:) Carrier-grade NAT (CGN or CGNAT), also known as large-scale NAT
(LSN), is an approach to IPv4 network design in which end sites, in particular residential
networks, are configured with private network addresses that are translated to public IPv4
addresses by middlebox network address translator devices embedded in the network
operator's network, permitting the sharing of small pools of public addresses among many
end sites. This shifts the NAT function and configuration thereof from the customer
premises to the Internet service provider network.

ISP: Internet Service Provider, is an organization that has an IP network and

provides services to people or companies (the subscribers) for accessing, using, or
participating in the Internet.

POP: also, Edge PoP. Edge PoPs are points of presence (PoP) at the edge of Meta's
production network where we interconnect with other networks/carriers/telcos to route
traffic and cache content. Edge PoPs extend our network’s reach, enable us to route traffic
efficiently, and help us decrease latency to our end users.

MNA: MNA is Meta’s caching platform. It caches static content such as images, videos, and
live streaming from our entire family of apps (Facebook, Messenger, Instagram, WhatsApp,
Workplace, etc). Static content usually represents ~95% of the total traffic to users.
Dynamic content, such as text and reactions (likes, etc), is only delivered from Edge POPs.

CGNAT-BYPASS SUPPORT | 20
8. Useful links
IETF RFC 1918, Address Allocation for Private Internets https://tools.ietf.org/html/rfc1918

IETF RFC 6598, Reserved IPv4 Prefix for Shared Address Space
https://tools.ietf.org/html/rfc6598

IETF RFC 7021, Assessing the Impact of Carrier-Grade NAT on

Network Applications https://tools.ietf.org/html/rfc7021

9. FAQ
Q1. Is Meta’s implementation of CGNAT bypass like those of other CDN(s)?

Here’s a comparison:

Item Meta Others

Private IP Space RFC1918 and RFC6598, exclusively. RFC1918, RFC6598, or

usurped globally unique
address space.

BGP community A range of community values. Two community values, one

values for private, one for public.

Prefix Private and public prefixes are grouped to ISPs specify which prefixes
Announcements Prefix Groups, and each Prefix Group has a are private and which ones
unique BGP community value. are public.

“many2many” not supported (having multiple “many2many” supported

public prefixes in one group)
Different community values
Same community value for both private and for private and public
public prefixes within the same Prefix Group. prefixes.
Example: Example:
private:[32934:10200] private:[asn:bgpvalue1]
public:[32934:10200] Public:[asn:bgpvalue2]

No private IP address reuse among Prefix No private IP address reuse

Groups if announced to any common MNA among CGNAT devices if they
clusters. are announced to the same
set of CDN clusters.

CGNAT-BYPASS SUPPORT | 21
 To sum up, the main differences are:

- Meta doesn’t support the use of public IP space as if it were private. Only
RFC1918 and RFC6598 addresses are supported for CGNAT bypass.

- Meta allows for more granularity in the translation signal, by enabling multiple
prefix groups to be defined in any cluster. This could be useful for ISPs that have
separate regions or topologies in their CGNAT rules.

- Meta does not support “many2many” translations, such as associating multiple

public prefixes to multiple private prefixes in one group. Meta expects that each
prefix group will have only one public prefix.

Q2. How do I know if MNAs will work with my CGNAT implementation?

Glad you asked! Check section 2 of this document, that includes a detailed list of
requirements. Keep in mind that depending on how you have implemented
CGNAT in your network, it might be or not be compatible with our solution for
CGNAT bypass.

Q3. If the configuration of the bypass creates an unexpected issue, what will Meta do
to fix it?

The responsibility of the bypass configuration is with the ISP, not with Meta. The
ISP always has control of when and how the bypass works. If you notice any
issue affecting users or think that the bypass is not working as expected, you
can remove the private prefix advertisements and/or any communities from the
BGP session with the MNA. This would mitigate any issue related to the bypass
in that cluster immediately. You can always open a Support ticket through NPP
and ask for assistance.

Issues affecting performance and user experience, when detected by

automation, will trigger a proactive reach out from our Operations team.

Q4. Is it possible to announce the entire 100.64.0.0/10? If so, how will the MNAs
avoid any IPs that are not part of the bypass, say, 100.101.240.0.0/24 for
example?

We suggest not to advertise such a big prefix, and instead advertise the private
specific prefixes for the location that the MNA is serving. This will make load
balancing easier to achieve and targeting more efficient. If you advertise a very
large prefix to any cluster, all the traffic destined to that prefix may be allocated
to that cluster. MNA will only learn the prefixes you advertise. If you want the

CGNAT-BYPASS SUPPORT | 22
 MNA to “avoid” any IP space, don’t advertise it.

Q5. Which mechanisms does Meta use to avoid sending all traffic to the MNAs where
private prefixes are advertised?

The Meta CDN only targets the public CGNAT prefixes and uses the same
targeting system to allocate traffic as with any other public prefix. In other
words, Meta is allocating public prefix traffic to the cluster, and the ISP is routing
that traffic to the private IP through the bypass. The ISP controls which clusters
may by allocated with the prefixes they advertise.

Q6. To keep it simple, can I just advertise everything with one community, e.g.,
32934:10200?

Using a single prefix group would only make sense if there is only one cluster in
your network.

But if there are multiple clusters, then advertising all public and private prefixes
with one prefix group community is not ideal, as the whole point of the CGNAT
bypass support on MNA is to optimize mapping between public and private
addresses to allow for localized targeting. If you advertise every prefix tagged as
one single group, then all those prefixes may end up being targeted as one big
block and could be allocated to a single cluster.

Our recommendation is to split the advertisements into smaller, more specific

prefix groups. This will enable our system to collect more granular metrics and
optimize cluster allocation for targeting.

IMPORTANT REMINDERS:

- Do not apply prefix group community tags to public prefixes that are not part
of the CGNAT implementation. This will only make targeting decisions less
accurate and is likely to have a negative impact to overall user performance.

- Do not apply the community tag to default routes (0/0).

- Do not apply the community tag to prefixes that don’t belong to your ASN.

Q7. How will traffic be balanced if ISP enables CGNAT bypass in multiple clusters?

Traffic will be balanced using the current mechanism to allocate traffic by our
targeting system. That is, based on BGP routing info (prefix specificity, AS-path
length, etc.) and performance metrics (such as latency), to determine the
optimal location for traffic egress for each single public prefix. As mentioned
before, we target only the public prefixes.
CGNAT-BYPASS SUPPORT | 23
Q8. Now that we have applied CGNAT bypass on MNA, could we also apply bypass on
the PNI (peering) sessions?

No. We do not support CGNAT bypass nor private IP space in peering sessions
with Edge POPs. Private prefixes and prefix group community tags, if received in
a PNI, will be ignored.

Q9. May I advertise other public prefixes from other locations and the public CGNAT
and private prefixes on same MNA?

You can advertise public prefixes of other locations in addition to the CGNAT
public prefixes and private prefixes. There is no restriction to having full CGNAT
or full public advertisements on a cluster. Just be mindful to apply CGNAT
community tags only to the prefixes related to CGNAT.

Q10. I am advertising a prefix with the 32934:10200 tag to the MNA cluster, but when
I check on NPP portal for that cluster page, the tag is not shown for this prefix.
Can Meta fix this?

If the tag is not shown on NPP, it means we are not receiving it. The NPP portal
is showing the BGP routes received by the cluster, and there is no filtering nor
configuration preventing a cluster from receiving communities. In other words, if
the tag is missing on NPP, this means that you need to review the BGP export
policy on your side. You may have a BGP export policy that removes community
tags on export. Also keep in mind that the information shown on NPP is not
updated instantly, it can take around one hour or so for the BGP update to be
reflected on NPP.

Q11. Do you support NAT44 and or NAT46?

In general, Meta’s routing system only uses public IP address, and does not
support private IP addresses.

If you are using NAT44 to translate from IPv4 subscriber private addresses to
IPv4 Internet public addresses or NAT46 to translate to IPv6 address, Meta’s
routing system will only be able to target public prefixes. If public prefixes
aggregate users in several remote locations, routing may not be optimal. CGNAT
bypass on MNA may improve latency for the public prefixes, but this support
only applies to MNA; support is not applicable for traffic served from POPs.

Q12. Do you support NAT64?

In general, all Meta’s applications support IPv6. If a user is a v6 only user, DNS
resolver together with DNS64/NAT64 ISP solution should return to user a v6
native address and should not translate v6 to v4 and use NAT64 because is not
CGNAT-BYPASS SUPPORT | 24
 optimal since it is not taking advantage on the better performance, flexibility,
and scalability that IPv6 provides.

Q13. If I advertise a /24 to one cluster in a prefix group, can I advertise the covering /23
to another cluster in another prefix group as a failover scenario?

Yes. That said, we recommend reviewing the failover methodology with MNA
before implementing CGNAT bypass with prefix group community tags. Instead
of using prefix size / prefix coverage to define failover, we recommend using
route preference community tags (between 32934:10000 - 32934:10012).
Check the “BGP community signalling” document from the Network Partner
Portal for details about how to communicate route preference to Meta.

Q14. Is there any min or max limit in the number prefixes for CGNAT bypass?

A prefix group must have at least 1 private and only 1 public prefix. In terms of
maximum, you many include multiple private prefixes in the group, but no more
than 1 public. Keep in mind to only apply the 32934:10200 - 32934:10299
community tags to the prefixes in your CGNAT implementation.

Q15. What is the smallest prefix size accepted?

MNA accepts prefixes as small as /31 for IPv4 and /64 for IPv6, regardless of
whether it is private/public/bypass etc.

Q16. Should I advertise the same prefixes as to the PNI (peering) I have with Meta?

We do not support CGNAT bypass nor private IP space in our PNI/peering ports
with Meta Edge PoPs. You may advertise the same public IP routes, if that
makes sense to your network topology.

Q17. What happens if there are multiple hops in the BGP session?

Check the Quick Start Guide about general details of BGP configuration. Keep in
mind that multiple hops could add latency. Meta’s routing system is based on
latency and having multiple hops to reach a user prefix from an edge location
(MNA or POP) could make this edge location less optimal to serve traffic.

Q18. If I advertise to a cluster all my CGNAT public address pools with a prefix group
community tag such as 32934:10200 but include only one private prefix in the
same group, what will happen to all the other private space? Will all the other
private prefixes not included in the group continue to function as before? Will
there be any impact to the traffic sent to these users from the Meta CDN?

This policy will only modify the CDN decisions for traffic to the private networks

CGNAT-BYPASS SUPPORT | 25
 that are advertised to the cluster. The Meta CDN will not learn any other private
network routes and therefore will not send traffic to those private IP addresses.
For those users, traffic will continue to be sent from the CDN to the public
prefixes, with no changes.

Note that if you associate a single private prefix with 100% of the public CGNAT
pools, then our latency measurement system will average the latency of all the
public pools for that private prefix. This makes the latency estimation less
accurate and therefore targeting may be suboptimal. That said, it should still be
more accurate than by not using CGNAT bypass prefix groups at all. Ideally, the
ISP should have private and public NAT prefixes segmented by region (e.g.,
North, South, East, West, each advertised using a different prefix group tag) and
this would facilitate better latency estimations and egress location decisions.

Q19. I use some public IPv4 space as if it were “private” and translate it with my
CGNAT to other public IPv4 blocks. Is this supported by Meta?

This is NOT supported and will not be supported in the future either. It will not
work if you advertise it to Meta. We check the status of RPKI-based BGP Origin
Validation. If a public prefix is RPKI-invalid, it will be ignored for CGNAT bypass.

Q20. After I update the prefixes advertised in the BGP session with the cluster, how
long does it take for Meta to apply the bypass?

Meta does not need to “enable” nor “apply” anything. Support for CGNAT
bypass communities is enabled globally.

Keep in mind that Meta does not apply the bypass: the ISP is doing the bypass.
To do it successfully, the ISP must do two things: advertise the prefix groups to
the MNA BGP as described here AND update their routing configuration to
bypass their CGNAT. Meta has no visibility of the second part.

Once a cluster receives new private prefixes or receives updates to communities

with any prefixes, the reaction is immediate – this is just BGP at play. When you
check for updates on NPP, it might take a few minutes for the data collected and
shown on NPP to catch up with the changes done in the BGP configuration.

When a cluster receives a NEW public prefix, it might take some time until traffic
is allocated to this cluster. When we already see this public prefix somewhere
else, it could take up to a few days for our system to collect latency samples and
decide to reallocate traffic to this new location for that prefix. Note that this is
how our targeting has always worked and is not specific to CGNAT bypass.

CGNAT-BYPASS SUPPORT | 26
Q21. I followed all the steps, but traffic is not going to the private IPs. What can be
happening?

There are a few things to consider:

§ Make sure NPP shows green valid checks for the configuration.

§ Make sure you have implemented the bypass in your routing (Meta can’t
know this, and NPP won’t show any info about it).
§ It could be the case that the cluster where you are implementing the bypass
is not regarded as the optimal location, and traffic may be allocated to a
different cluster.

o if our CDN measures better latency to the public prefix from a different
cluster

o if you are advertising a better route to some other cluster, such as a

more specific public prefix.

If you need help, open a support case on NPP and explain the issue. Provide as
much detail as possible: which cluster, which prefixes, what the issue is, etc.

Q22. What happens if I have multiple ASNs in my network?

It will depend on how you implement CGNAT bypass, and what the connection is
like to MNA clusters.

For example, you may have independent CGNAT translations for each ASN, re-
using the same private space. Follow the guidelines in the document, we
recommend using different prefix group numbers for each ASN and for each
cluster.

If your organization owns and operates multiple ASNs, make sure they have
been added to NPP. This can be managed through the Settings section of the
portal. This will be relevant for reporting and configuration validations.

IMPORTANT REMINDER: Do not apply the community tag to prefixes that don’t
belong to your own ASNs. Keep in mind that the 32934: community tags
defined by Meta are expected to be used exclusively for prefixes of your own
ASNs. Do not apply 32934: community tags to prefixes of downstream ASNs
(typically, transit customers). While you may advertise those prefixes to an MNA
cluster, please do not apply 32934: community tags to them.
CGNAT-BYPASS SUPPORT | 27
Q23. Why do you not support having multiple public prefixes grouped in the same
translation?

Our system associates the latency samples from the private IPs to the public
prefix defined in the group. If multiple public prefixes are included in the group,
our system won’t be able to discern which samples to attribute to each public
prefix. In other words, latency attribution to CGNAT public prefixes won’t be
measured correctly. In these scenarios, our system will attribute the latency
measurements to only one public prefix from the list and ignore the rest.
Typically, this leads to suboptimal traffic allocation and may also induce
congestion or suboptimal capacity management.

Q24. May I include IPv6 prefixes in the Prefix Group?

We currently don’t support IPv6 in the CGNAT bypass implementation. Any

prefix group tags on IPv6 routes will be ignored.

Q25. How does RPKI relate to Meta’s support of CGNAT bypass on MNA?

For public prefix in the prefix groups, we check the status of RPKI-based BGP
Origin Validation. If they are RPKI-invalid, they will be ignored for CGNAT
bypass. Why? This would signal a potential BGP hijack – you may be advertising
a public IPv4 route that belongs to a different ASN. This could be due to a typo in
the BGP configuration, a misuse of public prefixes as if they were private in
CGNAT, or other reasons. Please check the RPKI status of your routes, and if
possible, keep your ROAs up to date.

Q26. Why is my tag on a public route being ignored?

Could be for different reasons, but the most common are mentioned in Q23 and
Q25. Also, check the validation status information on NPP portal.

CGNAT-BYPASS SUPPORT | 28