NLR PacketNet Technical Guide
NLR PacketNet Connection Information and Recommendations
Typical Member connection to NLR PacketNet:
Summary of Connections
1.) Primary 10GE РMembers get a 10GE interface on their ÒlocalÓ NLR PacketNet CRS1. For those members who are not local to a NLR PacketNet CRS node, NLR will provide a 10GE backhaul circuit over the NLR WaveNet to a pre-defined PacketNet node.
2.) Secondary VLAN – In addition, every member may request a 1GE port on their local NLR FrameNet 6509, mapped to a VLAN which will be transported to a second NLR PacketNet CRS1 node. There is no bandwidth dedicated to this connection on the NLR FrameNet backbone.
Both these connections are included as part of NLR membership.
Physical
Cross-connect Responsibility – It is the responsibility of the member to provide any cross-connects or local loop connectivity to get to their assigned ports on the NLR device(s). This includes providing and running fiber to the NLR device(s). An option available is to arrange for NLR Implementation to perform this work via contracted hands-and-eyes support, and charge this back to the member at cost.
Optics РNLR will supply the optics for the membersÕ connections on the PacketNet CRS1. These are LR1310nm XENPAKs, with a power output of 0.5dBm to -8.2dBm and a receive sensitivity of 0.5dBm to -14.4dBm. Attenuation will also be provided if required. Optics for the connection to the FrameNet 6509 will also be provided by NLR. Please see the document ÒConnecting to the NLR Layer2 NetworkÓ for more information.
Fiber Connector Type РFor the memberÕs primary 10GE connection, the connector type will be SC. For the memberÕs secondary VLAN connection, the connector type will be LC.
MTU – By default, NLR will set the interfaces facing NLR members to a layer3 (IP) MTU of 9000 bytes.
IP numbering – By default, for IPv4 and IPv6, NLR will expect the member to provide IP addressing for their connections to the NLR PacketNet.
Protocols
By Default, every member connection will be setup with the following protocols active:
1.) BGP
2.) MSDP
3.) PIMv2
BGP
ASN - NLR AS is 19401
Peering Addresses РBy default, BGP peering will be enabled between interface addresses. This would mean one BGP session for each memberÕs 10G primary connection and a second for the memberÕs VLAN backup connection.
IPv6 – By default, NLR will plan to enable IPv4 and IPv6 for each member. These will be enabled using a separate BGP session for IPv4 and for IPv6. If requested, NLR will provide a /40 allocation to any member without their own IPv6 address space.
Multicast – By default, NLR will plan to enable both unicast and multicast support for both IPv4 and IPv6 for each member. Members who wish to use multicast must enable the multicast SAFI and advertise all multicast enabled networks in that SAFI. If a member does not plan on configuring multicast, this should be discussed with the NLR engineer bringing up the connection.
Prefix Lists – NLR will use a prefix-list for each member to protect against unintended route leakage. The member should submit a list of prefixes they intend to advertise to the NLR NOC, to be added to their prefix list.
Route Type Limitations - There is no approval process for routes, but private addresses, bogons, and the routes from other ÒupstreamÓ providers are not allowed without further planning to ensure stability and proper route tagging.
Prefix Length Limitations – Members are encouraged to aggregate their routes wherever possible. However, there is no limit to the maximum or minimum prefix length accepted by NLR, either for IPv4 or IPv6.
MEDs from NLR РNLR will set MEDs on route advertisements equal to the IGP metric. It will be the memberÕs responsibility to ensure that traffic flows as they want. For example, if the member wants to make sure all their NLR L3 traffic flows over their primary 10G connection, they will need to make sure they set local pref, since relying on MEDs will cause some traffic to prefer the backup connection.
Dampening – BGP route dampening will be disabled on NLR.
Authentication – By default, authentication will not be used. NLR will support MD5 authenticated peering sessions if requested. NLR PacketNet supports GTSM.
BGP Communities – see the NLR BGP Communities page at <url> for details. NLR will not strip BGP communities attached by members.
MSDP
Peering Addresses - MSDP peering will use interface addresses by default.
SA Limitations – Administratively scoped group addresses, and groups from the SSM block will be blocked. Private addresses and bogons will be blocked as source addresses.
MSDP SA Advertisement Limits – PacketNet is currently unable to limit the number of SAs. This may be implemented in the future, with the type of limit (e.g. per source or per peer) depending on technical feasibility.
PIMv2
Versions - Only v2 PIM will be allowed. Dense mode is not supported.
RP Election Limits – NLR will block all auto-rp and bsr packets from members.
Security
Blackhole Routing – Users of NLR PacketNet can tag a pre-specified BGP community to on of their routes (usually a /32) that is currently being attacked. NLR will then blackhole traffic to that route rather than sending it on to the member. Members will only be able to blackhole their own routes.
In addition, users can request (via a normal trouble ticket) that an incident be investigated or a more particular packet filter be put in place.
nlr-participants.pdf