PacketFabric Frequently Asked Questions

PF-AE: LAG interfaces and aggregated dedicated cloud ports

PF-AB: Flex bandwidth container

PF-AP: Ports and non-aggregated dedicated cloud ports

PF-BC: Backbone virtual circuit

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

PF-DC: Marketplace virtual circuit

PF-IX: IX virtual circuit

PF-L3-CUST: Cloud Router

PF-L3-CON: Cloud Router connection

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

PF-PD: Point-to-point connection

PF-PS: Pseudo-interface

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.

For more acronyms, see Acronyms and Terms.

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

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

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

https://www.packetfabric.com/privacy

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

For more information, see Maintenance Notifications.

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:

• Company Contacts
• Administration - Users

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:

• Open a Support Ticket
• PacketFabric Contacts and Escalation Guide

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

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

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.

We only bill for services already rendered.

For example, the invoice you receive in August reflects the services you used in July.

Once you have a credit card on file, yes.

You can opt out of automatic payments at any time. For more information, see Automated Credit Card Payments.

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.

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

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

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

If you do not renew or extend your contract before it expires, your service will automatically revert to a month-to-month plan. This means that you can cancel it without paying an early termination liability fee. However, you will also be charged the current month-to-month service rates.

That depends on how the service is billed and the type of service. For more information, see Cancel a Service.

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

All PacketFabric services are delivered via single-mode fiber.

No.

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.

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

See the PacketFabric website: https://packetfabric.com/pfg-latency-metrics

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.

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.

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.

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.

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.

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.

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.

Billing begins 15 days after provisioning OR when a port becomes operationally up, whichever happens first. For more information, see Port Terms and Billing.

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.

A non-core location is also known as a “single-armed” or “single-homed” site.

Our core locations are multi-armed/multi-homed. This means that there are multiple fiber pathways connecting to the POP device, and should something happen to one fiber pathway we can reroute your traffic with minimal disruption.

However, a non-core location is connected to a single fiber pathway. Think of it like a cul-de-sac: one way in, one way out. This means that if something should disrupt connections along that pathway, we cannot reroute your traffic to avoid disruption, thereby upholding the SLA.

Yes, we support jumbo frames.

This depends on the service.

Access ports, point-to-point, backbone virtual circuits: for optimal performance, set your MTU to 9000 bytes.

Cloud connections: This depends on the cloud service provider. See below under “Cloud Connectivity.”

By default, the option to order an ENNI port is hidden. If you would like us to display this option in your portal, contact support@packetfabric.com.

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.

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

If a port already has a virtual circuit attached, you must remove the virtual circuit before adding it to the LAG.

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.

For EPL circuits, you can configure a multi-chassis LAG on your devices and we will transparently pass LACP frames between them.

EVPL circuits do not pass LACP frames transparently, and therefore multi-chassis LAGs cannot be configured across them.

We have not set any limits at this time.

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:

• Virtual Circuit Ethernet Features
• Ethernet Service Specifications

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

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

Currently, you can only add a capacity burst to a longhaul virtual circuit that is on a dedicated billing plan (e.g. 1 months, 12 months, etc.)

This is because those are the only type of circuits that would require an hourly burst.

• Metro - Metro virtual circuits are free of charge and do not have term limits. When creating the circuit, you should provision a capacity large enough to accomodate bursts. You can edit the virtual circuit to set rate limits for when you do not need extra capacity, or just delete the circuit altogether and create a larger or smaller one without worrying about prices or contract lengths.
• Longhaul usage-based circuits - These circuits have no capacity cap other than port size.
• Hourly longhaul circuits - If you want to increase the capacity for an hourly circuit, simply delete it and create a new one.
• Marketplace and IX virtual circuits - These virtual circuits involve a third party who must approve any capacity increases from their side, making bursts difficult.

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

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.

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.

Not currently. Contact sales@packetfabric.com to discuss your use case.

Yes, we provide a /31 for public connections.

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 can also use your own public IPs when configuring Microsoft public peering.

You cannot use your own IPs for Google or IBM.

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

Not at this time.

No, Cloud Routers only support EVPL virtual circuits.

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.

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

Yes.

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

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.

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 hair-pinning traffic and provides far more scalability.

Yes. However, review the requirements for the Cloud Router ASN before creating the Cloud Router: BGP Reference

For example, you can have both private and public AWS VIFs on a Cloud Router, but if you create the Cloud Router with a private ASN, then AS prepending does not work for public VIF connections. See AWS docs - Prerequisites for virtual interfaces.

It’s likely that we support a much broader range of VPN hardware and software than those that have been verified, as long as the device follows IPsec standards. If you have any questions about support for your device, we will be happy to help you test it. Contact sales@packetfabric.com to speak with one of our solutions experts.

Cloud Router public connections support NAT within the same Cloud Router, so you can achieve NAT from private space behind IPsec to a public cloud.

Note: We don’t support NAT on the IPsec connection itself on our side but the customer side can be behind a NAT gateway.

The VLAN ID on Hosted cloud connections cannot be modified once the circuit is created.

If you need to change the VLAN ID of an existing connection, you need to delete the connection and then re-provision it with the desired ID.

Depending on the cloud service provider (CSP), you should be able to reuse the unique identifier provided on the cloud side (e.g. pairing key, service key, etc.)

No, Hosted cloud connections are currently only available on monthly terms.

No, the connection automatically renews.

For access ports, point-to-point, backbone virtual circuits, set your MTU to 9000 bytes.

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

Billing

• Reseller customers do not create billing accounts. As such, when ordering services, reseller customers do not have an option to select a billing account.
• Reseller customers do not receive invoices from PacketFabric.
• Reseller customers cannot see the Billing tab in the portal.

All billing is handled between the reseller and the customer.

Support

• Reseller customers see customized Contact Us information. This information is provided by the reseller.
• The reseller - and not PacketFabric - provides technical support to their customers.

Registration

• Reseller customers do not have to wait for their account registration to be reviewed and approved.

Logging

• If a reseller performs any actions on behalf of the customer, that activity appears in the customer’s logs.

Contact your partner manager and they will work with you to modify pricing accordingly.

The MRR only shows services that are billing. We do not start billing for ports until the cross connect is in place or 15 days after ordering, whichever comes first.