IPv6 Services
Services can now be defined with IPv6 CIDR block addresses. Services can be can be NAT’ed from IPv6 to IPv4 by creating an IPv6 based service address intending to destination NAT to an IPv4 based addressing using a IPv6 NAT target services route. In a similar fashion, IPv4 to IPv6 is also supported. Dual stack is not supported, meaning an IPv4 and IPv6 on a single interface will not work.
Example of a IPv4 service NATed to a IPv6 serviceService
service west
name west
service-group all
description "web service for everyone"
enabled true
tenant red
scope private
security aes1
address 172.16.2.201/32
access-policy red
source red
permission allow
exit
service-policy tcpPolicy
exit
Service-Route
service-route combo1
name combo1
service-name west
nat-target 2001:db8::172.16.3.2
next-hop test1 intf11
node-name test1
interface intf11
gateway-ip 2001:db8::172.16.3.2
exit
exit
Ingress Interface (IPv4)
network-interface intf10
name intf10
global-id 1
vlan 0
type external
tenant red
rewrite-dscp false
source-nat false
qp-value 30
mtu 1500
address 172.16.1.1
ip-address 172.16.1.1
prefix-length 24
gateway 172.16.1.201
exit
exit
Egress Interface (IPv6)
network-interface intf11
name intf11
global-id 2
vlan 0
type external
rewrite-dscp false
source-nat true
qp-value 30
mtu 1500
address 2001:db8::172.16.3.1
ip-address 2001:db8::172.16.3.1
prefix-length 120
gateway 2001:db8::172.16.3.2
exit
exit
Example of a IPv6 Service NATed to a IPv4 address Service
service east
name east
service-group all
description "web service for everyone"
enabled true
tenant red
scope private
security aes1
address 2001:db8::172.16.3.2/128
access-policy red
source red
permission allow
exit
service-policy tcpPolicy
exit
Service-Route
service-route combo2
name combo2
service-name east
nat-target 172.16.2.201
next-hop test2 intf11
node-name test2
interface intf11
gateway-ip 172.16.2.201
exit
exit
Ingress Interface (IPv6)
network-interface intf10
name intf10
global-id 1
vlan 0
type external
tenant red
rewrite-dscp false
source-nat false
qp-value 30
mtu 1500
address 2001:db8::172.16.3.2
ip-address 2001:db8::172.16.3.2
prefix-length 120
gateway 2001:db8::172.16.3.1
exit
exit
Egress Interface (IPv4)
device-interface 11
name 11
description "device 2"
type ethernet
pci-address 0000:00:05.0
capture-filter len>0
network-interface intf11
name intf11
global-id 2
vlan 0
type external
rewrite-dscp false
source-nat true
qp-value 30
mtu 1500
address 172.16.2.2
ip-address 172.16.2.2
prefix-length 24
gateway 172.16.2.201
exit
exit
exit
Quectel EC25-A LTE card support
The Quectel EC25-A LTE card is now supported as an integrated solution within the 128 Technology Router. This card can be configured much like any other supported LTE card, by configuring the device-interface and selecting the type to be LTE.
Router-Based Services
In prior releases, services would be shared across the entire authority and applied to all the routers. This can cause several unintended consequences.
-
Service configuration changes meant for one router end up triggering a configuration change on every single router across the entire authority.
-
Proliferation of services - for any “private” service that only has relevancy to a single router ends up being configured on all routers within the authority. This causes unnecessary FIB entries on routers.
Services now have a notion of locality - a way to identify which router(s) within the authority should be the consumer of this service. An example of a service configured within a router-group is given below.
service
name ntp
scope private
router-group branch1
transport udp
protocol udp
port-range 123
start-port 123
end-port 123
exit
exit
address 0.us.ntp.pool.org
access-policy internal
source internal
permission allow
exit
exit
router
name branch1
router-group branch1
exit
DHCP Server
The DHCP protocol provides a mechanism for unprovisioned hosts to request an IP-address and configuration via broadcast requests. Based on available address pools, a DHCP server can provide a DHCP client a time-limited IP address “lease”. The 128T now has support for a single integrated DHCP server. DHCP Server can be configured as a “dhcp-server” service-type within the “host-service/service-type” choice of a “network-interface/address”. 4.1.0 has the current restriction that dhcp-server can only be configured on a single network-interface per router.
network-interface intf4
name intf4
global-id 4
vlan 4
type external
source-nat false
mtu 9216
address 172.16.4.1
ip-address 172.16.4.1
prefix-length 24
host-service dhcp-server
service-type dhcp-server
server-name 128TDhcpServer4
max-lease-time 10
address-pool 172.16.4.161
start-address 172.16.4.161
domain-server 4.4.4.4
domain-name www.128technology.com
exit
exit
exit
exit
Azure Accelerated Networking Support
128 Technology solution can now be created and deployed as a VM with Azure Accelerated Networking support. Accelerated networking enables single root I/O virtualization (SR-IOV) to a VM, greatly improving its networking performance. This high-performance path bypasses the host from the datapath, reducing latency, jitter, and CPU utilization, for use with the most demanding network workloads on supported VM types.
The Azure instance needs to be configured to use an accelerated devices along with the 4.1.0 version of 128T software.
Core Isolation Mask Readability
The new sub-command cpu for show platform is very helpful in understanding how the system is configured and optimized for forwarding performance. The output of this command has been improved to display core isolation mask in a human readable form.
router# show platform cpu
Thu 2018-12-20 18:45:53 UTC
======================================================================
tp-colo-primary
======================================================================
---------------
CPU Information
---------------
Type: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz
Speed: 2 GHz
Hyper-Threading: no
Cores: 8
Forwarding Cores: 2
Isolated Cores: 1-2
Power-Saver: disabled
Completed in 1.25 seconds
GUI Dashboard Provides Improved Navigation
A new landing page for the GUI now offers a launchpad into other areas of the GUI as well as providing a snapshot of system activity.
Upgrade to CentOS 7.5
CentOS 7.5 offers a number of security upgrades to the kernel, third-party libraries and binaries. These updates provide stability improvements to the underlying operating system.
Loopback for BGP Peering
128T can be configured to used a loopback address for SVR BGP peering. This allows peering to remain ESTABLISHED when there are multiple links between two peers. If a physical interface is used for peering and that interface were to be down, the peering would break even though there is another link that is up, the ability to configure a loopback address resolves this issue. This also will offload per-interface peering that could place an unnecessary burden on low speed links where bandwidth a premium commodity.
UDP Transform NAT Traversal
When a 128T router is performing UDP transform, it becomes a UDP client, generating traffic on behalf of the originating TCP client, to the peer 128T. The TCP based client and server is not aware that the session is being transformed to UDP. In cases where the session is being UDP transformed, there can be lull in traffic coming from the TCP based client through 128T. An absence of TCP traffic between the client and server means no UDP traffic for the UDP transformed session. If this absence of traffic persists long enough, this can cause the session to be torn down or stranded if traversing a NAT due to NAT devices timeout values. The 128T can now be configured to send keep-alive messages over the UDP transformed session to ensure that the NAT device does not time out the session and it remains up for the lifetime of the TCP session.
udp-transform
mode auto-detect
detect-interval 10
nat-keep-alive-mode enabled
nat-keep-alive-timeout 30
#ReleaseNotes#BGPPeering#Azure#DHCP#Centos7.5#4.1.0#NAT#GUI#LTE#IPv6