Configuring Point-to-Point Links With a /31 or /127 Network Mask
When aggregating hundreds or thousands of mobile IPsec (remote workers) & site-to-site (Data Center to Cloud, Cloud to Cloud) VPNs to AWS, there has often been a trade-off of performance, cost, and manageability. There doesn’t need to be one.
The Netgate® TNSR High-Performance Routing & VPN Appliance for Amazon AWS is a powerful solution that connects thousands of mobile users, branch sites, and data centers. Customers are choosing the TNSR High-Performance Routing & VPN Appliance to get high performance, low TCO, and simple management, avoiding any trade-offs.
IPv4 P2P
RFC 3021 provides a method to optimize the use of IPv4 address space for P2P links by using a /31 network mask. This effectively doubles the number of usable addresses compared to a traditional /30 subnet and reduces (or addresses) security risks by removing the need for broadcast and network addresses. By reducing the number of possible hosts on a subnet (which reduces the attack surface) and eliminating unnecessary broadcast traffic, the /31 mask conserves address space and improves the security and efficiency of point-to-point connections. This makes it a best practice for IPv4 P2P links in modern networks.
Normally, a /30 subnet would be used for such connections, but this consumes four IP addresses, where two are usable, and two are reserved (network and broadcast addresses). With a /31 subnet, described in RFC 3021, only two IP addresses are needed, and they can be assigned to the two ends of the P2P link, eliminating the need for a network or broadcast address. This saves IP addresses by allowing you to use only two addresses (the minimum needed) for a point-to-point connection. To put this into perspective, consider a network with 500 P2P links. Using only two addresses for each connection would save 1000 addresses (the equivalent of a /22 address space.)
Example: If you use the network 203.0.113.0/31, then:
- Router A gets 203.0.113.0
- Router B gets 203.0.113.1
IPv6 P2P
Using a /127 prefix for P2P links in IPv6, as recommended by RFC 6164, provides significant benefits in terms of IP address conservation, enhanced security against certain attack vectors (such as ND flooding), and prevention of unnecessary traffic on the link. It also keeps the routing table simpler and avoids routing and address interpretation issues. By reducing the address space to just two usable addresses, the network becomes more efficient and secure, making it a best practice for IPv6 P2P link configurations.
As in IPv4, there is also the potential for wasted addresses in IPv6, but /127 prevents this, compared to a larger subnet (like /64 or /126). There are no concerns about network or broadcast addresses in IPv6, but using a larger prefix would assign many unnecessary addresses to the P2P link. Similar to using a /31 mask in IPv4, a /127 mask in IPv6 ensures that exactly two addresses are used on the link, conserving the address space.
Example: If you use the network 2001:db8::/127, then:
- Router A gets 2001:db8::
- Router B gets 2001:db8::1
Configuring TNSR Software P2P Links
Consider a P2P link configured between Router A and Router B based on the previous IPv4 and IPv6 examples. Routers have a direct link on interface GigabitEthernet0/4/0.
Figure 1
Starting with IPV4 configuration, subnet 203.0.113.0/31:
Run a ping test to verify IPv4 connectivity across the P2P link:
Next, we configure IPv6 P2P subnet 2001:db8::/127 and save the changes:
Running ping6 test will verify IPv6 connectivity across the P2P link:
The routing table reflects the newly created P2P networks as well:
We can also verify neighbor devices by looking at Address Resolution Protocol (ARP) and Neighbor Discovery Protocol (NDP) tables.
Conclusion
Netgate TNSR software supports the configuration of both /31 and /127 P2P subnets. This is particularly useful for conserving address space and improving security. The router's powerful VPP-based architecture ensures that high-performance, scalable routing operations, including these point-to-point configurations, are handled efficiently.
from Blog https://ift.tt/lphtnW4
via IFTTT
No comments:
Post a Comment