PacketFabric Frequently Asked Questions
What does the “PF-XX” stand for in interface and circuit names?
PF-AE: LAG interface
PF-BC: Backbone virtual circuit
PF-DC: Third-party virtual circuit
PF-IX: IX virtual circuit
PF-CC: Cloud connection
PF-PD: Point-to-point connection
Where can I find your Service Level Agreement (SLA)?
There is a link to the SLA 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 firstname.lastname@example.org or call 1-844-475-8322 ext. #2.
For more information, see the following:
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.
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 email@example.com.
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?
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?
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 firstname.lastname@example.org 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.
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?
What burst size is used for rate limits on virtual circuits?
What are the recommended BFD timers to run across your virtual circuits?
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.