PacketFabric Frequently Asked Questions

General

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

PF-AE: LAG interface and aggregated Dedicated cloud connections

PF-AP: Port and non-aggregated Dedicated cloud connections

PF-BC: Backbone virtual circuit

PF-DC: Marketplace/third-party virtual circuit

PF-IX: IX virtual circuit

PF-MC: A marketplace virtual circuit that connects to a cloud port

PF-CC: Hosted cloud connections and virtual circuits associated with Dedicated cloud connections

PF-PD: Point-to-point connection

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

Colt-powered port IDs start with CT-. If a virtual circuit has CT in its circuit ID, then one side of it lands on a Colt-powered port. For more information, see Colt-Powered Ports.

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

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

https://packetfabric.com/assets/documents/PacketFabric-SLA.pdf

Where can I find your Privacy Policy?

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

https://www.packetfabric.com/privacy

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 support@packetfabric.com or call 1-844-475-8322 ext. #2.

For more information, see the following:

User credentials and authentication

How long can I remain logged in?

User authentication sessions expire after 30 days, at which point you will be prompted to log in again.

What authentication apps do you support with MFA?

You can use any authenticator app that supports the Time-based One-time Password algorithm (TOTP). We have tested and confirmed compatibility with the following:

Google Authenticator
Microsoft Authenticator
LastPass Authenticator
1password
Authy
Duo

I have MFA enabled on my account, but I have lost my authenticating device. What should I do?

If you saved the backup codes you received when you enabled MFA, you can use one of those to access your account and set up a new device.

If you don’t have your backup codes, have an account admin contact support@packetfabric.com and we’ll work with them to restore your account.

If you are the only account admin, we will work with you directly to restore your account, but we will need to verify your identity via at least two contact methods.

Billing

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 ar@packetfabric.com 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.

You might see the following invoice statuses:

  • Finalized: The invoice includes all charges and is ready to be paid.
  • Overdue: The invoice has not been paid and it has been more than 30 days since the invoice date.
  • Closed: Payment has been received and applied.

How do I dispute charges?

To file a dispute, gather all relevant details and email ar@packetfabric.com.

Services and routes

What is the underlying technology used in your service offerings?

For our point-to-point EPL (Ethernet Private Line) product, we use L2VPN/pseudowire: https://tools.ietf.org/html/rfc4906

All other services are EVPL (Ethernet Virtual Private Line) and we use EVPN-VXLAN: https://tools.ietf.org/html/rfc8365

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?

No.

Are your services redundant?

Yes!

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 support@packetfabric.com 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 support@packetfabric.com.

Do ports need to be physically connected after an order is placed?

Cross connects are a physical connection, so yes.

However, all PacketFabric equipment is pre-patched and pre-cabled and ready for connections. This means that we just need to complete any patching to your local side that is not already in place.

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.

Ports

What does ‘powered by Colt’ mean?

When a port is “powered by Colt,” this means that it is owned and operated by Colt Technology Services but can be used as if it is a native part of the PacketFabric network.

For more information, see Colt-Powered Ports.

Do you support jumbo frames?

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.

We recommend setting your MTU to 9000 bytes.

How many bytes should I set for my MTU?

This depends on the service.

Access ports, point-to-point, backbone virtual circuits
For optimal performance, set your MTU to 9000 bytes.
Cloud connections
Check the cloud service provider requirements:
  • AWS Direct Connect: When creating a Direct Connect virtual interface, you can optionally enable jumbo frames at either 8500 (Transit VIF) or 9001 (Private VIF) bytes. If you do not enable jumbo frames, or if you use static routes, the MTU is 1500 bytes. For more information, see Setting network MTU for private virtual interfaces or transit virtual interfaces.

  • Google Cloud Interconnect: Google allows a maximum of 1440 bytes.

  • Azure ExpressRoute: Azure allows a maximum of 1500 bytes.

  • IBM Direct Link: IBM allows a maximum of 1500 bytes.

  • Oracle FastConnect: Oracle allows a maximum of 9000 bytes.

LAG interfaces

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.

Why can’t I add this port to a LAG?

To be included in a LAG, the ports must be at the same site, in the same zone, and have the same speed.

If you have verified it matches that criteria and you are still unable to include it in a LAG, then the port likely does not support LAGs. Not all edge ports support LAGs at this time.

How many ports can I add to a LAG?

We have not set any limits at this time.

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
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
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.

Cloud Routers

Do I need to set up a cross connect to PacketFabric?

No. You do not need a physical port or a data center presence to use Cloud Router services.

We can transfer data between your cloud environments, but then you would be responsible for reaching the cloud via another route (such as over the open internet or a VPN connection).

Can I connect my on-premises network to the cloud router?

Yes. If you aren’t already connected, you will need to provision an access port in one of our locations and set up a cross connect to our network.

If you already have an access port, you can use that to connect your on-premises network to the Cloud Router.

Is Q-in-Q supported?

Yes.

Q-in-Q tunneling is fully supported. Q-in-Q S-tag/S-VLAN is supported for Azure connections. If you require S-tag/S-VLAN for another cloud, contact your Customer Service Manager to discuss options.

Do you provide public IPs?

Not at this time.

Can I use my own public IPs for the router peering? What about my own public ASN?

At this time, you cannot use your own public ASN.

For an AWS public virtual interface, you can use your own public IPs. When you provision your connection, we send AWS an automated email to confirm that you are authorized to use our public ASN with your public IPs. All public virtual interfaces require up to 72 hours approval by AWS.

You cannot use your own IPs for Google or IBM.

At this time, we do not support Microsoft public peering.

Can I use my own private IPs?

This depends on the cloud service provider.

For router peer IPs:

  • AWS allows you to input your own IP addresses or have them generated on your behalf.
  • Microsoft Azure requires you to provide your own subnet ranges. The peer IPs are auto-allocated from this range.
  • For Google Cloud and IBM Cloud, the IP addresses are generated on your behalf and cannot be edited.

When advertising VPC subnets, you can set your own prefixes (up to 1000 in and 1000 out).

Is IPv6 supported?

Not at this time.

How long does provisioning take?

Provisioning can take up to 10 minutes, depending on the cloud.

Additional configuration takes a few more minutes depending on how many prefixes you need to add.

How many connections can I have per Cloud Router?

At this time, we have not set a limit on connections.

Can a virtual circuit be ordered from a Cloud Router to anywhere in the PacketFabric network?

Yes.

Will my data traverse the public internet?

No, all traffic stays within PacketFabric’s software-defined network.

How do you choose the best path for data to take?

Our network architects have carefully engineered our software-defined network to take the best routes between on-net locations. This applies to both primary paths and fallback paths.

What do you mean when you say it’s a “distributed” service?

Rather than creating one centralized router to handle inter-cloud, we create routing instances at each location you provision a connection.

This allows us to avoid hairpinning traffic and provides far more scalability.