PacketFabric Frequently Asked Questions


What does the “PF-XX” stand for in interface and circuit names?

PF-AE: LAG interface

PF-AP: Port and dedicated cloud connections

PF-BC: Backbone virtual circuit

PF-DC: Third-party virtual circuit

PF-IX: IX virtual circuit

PF-CC: Hosted cloud connection

PF-PD: Point-to-point connection

PF-TC: Test virtual circuit (no longer used)

Where can I find your Service Level Agreement (SLA)?

There is a link to the SLA in the PacketFabric website footer.

Where can I find your Privacy Policy?

There is a link to the Privacy Policy in the PacketFabric website footer.

Account administration and support

How do I receive maintenance notifications?

An administrator needs to add you as a company contact with the Technical role.

For more information, see Maintenance Notifications.

What is the difference between users and contacts?

Users can log in and access the portal. Contacts cannot.

You can create a contact representing someone who is also a user, but this is a manual step and does not happen automatically.

Because contacts do not need credentials, you can use an email distribution list in the contact details. This might be useful when handling maintenance notifications.

For more information, see the following:

What is my support level?

All PacketFabric customers have access to 24x7 support.

To open a ticket, email or call 1-844-475-8322 ext. #2.

For more information, see the following:


Why can’t I see my old invoices?

In June, we migrated to an in-house billing system (see the June 30, 2020 release notes).

Currently, invoices that were generated with our previous billing platform are not available to download through the portal. This is temporary and we are working on a way to import all legacy billing data. Until then, you can contact to get copies of old invoices.

I sent a payment. Why is my invoice still showing overdue?

This likely means that we have received your payment but have not had a chance to apply it.

What does “Finalized” mean for an invoice?

“Finalized” means the invoice is ready to be paid. It has been reviewed (if necessary) and includes all monthly charges.

How do I dispute charges?

To file a dispute, gather all relevant details and email


What is the underlying technology used in your service offerings?

For our point-to-point EPL (Ethernet Private Line) product, we use L2VPN/pseudowire:

All other services are EVPL (Ethernet Virtual Private Line) and we use EVPN-VXLAN:

Can I get my service delivered via copper handoff? What about multimode fiber?

All PacketFabric services are delivered via single-mode fiber.

Do you offer wavelength-based services?


Are your services redundant?


Our Ethernet-based services (EPL and EVPL) are delivered via a layer 2 overlay and are inherently protected.

We guarantee packet delivery from point A to point B within a given latency SLA, however we do not guarantee it will take any particular layer 1 path.

Should there be a disruption at the physical transport layer, the PacketFabric network will automatically adjust and re-route traffic over other paths.

How quickly can I expect my service to be rerouted in the event of a Layer 1 fault?

Services are typically rerouted within 50ms to 100ms, depending on the distance between endpoints.

Why am I seeing increased latency on a service?

A 15ms to 25ms increase in latency is considered normal when we have to fail over to a less preferred path in the fabric. We don’t typically shift traffic around these core fabric links, but fiber cuts do happen from time to time and are outside of our control.

Running your ports at line rate can also increase latency as we do not inspect your Ethernet frames to provide any type of Quality or Class of service for any particular IP packet type.

However, for any kind of unusual or suspect latency, you should email or call 1-844-475-8322 ext. #2.


Can I get a copy of your KMZ?

Due to the nature of our network, we cannot offer this.

While PacketFabric operates its own optical transport network, we did not build our own fiber. Instead, we have chosen to partner with numerous national and regional line system providers.

We have used an assortment of technologies to piece together this network: from dark fiber in metro areas, to leased spectrum frequencies over longer paths, and even wave services in more difficult to reach locations. This design allows us to maintain as much control over fiber link operation as possible, leverage other carriers’ long-haul DWDM systems, and control costs in locations that have fewer options and less available bandwidth.

Our approach to building our network backbone allows our network architects and capacity planners to add new backbone routes into the network without having to rely on any one line system operator. In other words, we stitch together the best of multiple line-systems to give us the paths we desire.

As a result, we do not provide a client-facing master KMZ document that details all of our pathways, because some providers require a non-disclosure agreement on specific routes.

We understand that you need to ensure redundancy with your existing services. We are more than happy to work with you on an individual basis to address any concerns or answer any questions you might have about any specific paths on our network.

Can you restrict my service to a specific fiber route?

Not at this time.

If your preference is that a service goes down instead of being rerouted, we recommend a BFD configuration between your endpoints.

Cross connects and LOAs

What is an LOA?

LOA stands for Letter of Authorization or Letter of Authority. They are also sometimes called LOA-CFAs (Connecting Facility Assignment).

The LOA is required to install a cross connect between your equipment and ours.

The LOA tells the data center three things:

1.) You have permission to connect your equipment with ours.

2.) The exact location of the port at which they should install the physical cross connect.

3.) The media they should use for the connection.

Click here to download a template.

For more information, see Cross Connects.

The data center cannot install my cross connect because the port is occupied. What does this mean?

We pre-cable the rear side of all our panels. Sometimes data center technicians will mistake this to mean that the port is already occupied. However, the front side of the panel should be open for new cross connects.

If they are still reporting that the port is occupied after checking the front panel, it is possible that the previous cross connect was never removed. To have us verify this for you, open a ticket by emailing

Why do some of my ports allow me to order a cross connect while others don’t?

The ability to order a cross connect through the PacketFabric portal depends on the data center. If you do not see the Cross Connect action in the port’s overflow menu, you will need to generate an LOA and contact the data center directly with your request.

For more information, see Cross Connects.


Do you support jumbo frames? What MTU do you support?

Yes, we support jumbo frames.

All our interfaces support an MTU of 9096 at layer 2. However, there might be additional overhead for VLAN tagging used on EVPL circuits.

Why is the interface MTU fixed at 9096 bytes?

An MTU of 9096 bytes is the largest Layer 2 frame that PacketFabric will ever send to or receive from your interface.

This value is derived from: 9192 (minimum internal MTU) - 96 (PacketFabric overhead) = 9096

How many bytes should I set for my MTU?

Your MTU should be 9000 or 8192 bytes for optimal performance.

PacketFabric automatically configures your interfaces at a Layer 2 MTU of 9096 bytes. The suggested size of 9000 bytes covers most variances in multiple platforms and vendor inconsistencies in regards to the system and port level MTUs on devices.

Depending on the release date and the platform, a system MTU of 1500 actually translates to a Layer 2 MTU of 1514 or 1522 (depending on feature set). Some platforms only configure the Layer 2 MTU. The operator needs to be aware of ethernet and additional feature overhead when changing the MTU.

Virtual circuits/EVPL connections

What is the difference between EPL and EVPL circuits?

PacketFabric offers EPL services through our Point-to-Point product. Virtual circuits and cloud connectivity connections use EVPL connections.

EPL is a traditional point-to-point Ethernet virtual connect between physical interfaces. This type of connection is also commonly referred to as a “pseudowire.”
Each interface can support only one EPL connection, so each physical interface only has one logical interface (unit) associated with it.
There is no rate limiting or white/blacklisting of MAC addresses when using EPL mode.
EVPL allows for multiple point-to-point virtual connections between interfaces. Each physical interface can support multiple virtual circuits.
This means many logical interfaces (units) are associated to each interface, each with their own unique VLAN relative to the physical interface.
VLAN tags on either side of the virtual circuit do not have to match, but can.

For more information, see the following:

How do I change the VLAN ID for a virtual circuit?

You can add, remove, and change VLAN IDs by editing the virtual circuit.

What burst size is used for rate limits on virtual circuits?

By default we set a burst size of 6250000 bytes.

What are the recommended BFD timers to run across your virtual circuits?

This depends on the circuit distance. You can work with your Sales Engineer or our support team for specific guidance.

Point-to-point/EPL connections

Can I LAG multiple EPL services?

Not directly, but there is a workaround.

Our EPL service is transparent and our routers will not act on LACP packets. We only pass them to the other side of the circuit.

However, because the LACP packets are passed to the other side, it is still possible to exchange LACP packets between the both sides of the service.

This means that LAG participation will be between your network devices on each end of the service and not between your network device and our network device.