Network Interface

A network interface (a logical IP routing interface) can be configured on a network-facing physical or logical port, and is used for connectivity purposes. Each network interface can have only one IP address. The connections are point-to-point; for example, a network port on an Ethernet interface cannot be connected to a LAN but must be connected to a network interface on another router.

Secondary IP address assignment, which is used to connect the same interface to more than one subnet, is not supported.

Network ports are used to transport Ethernet, ATM, and TDM services by means of pseudowires.

IP address assignment is not supported on access (customer-facing) ports except for services such as IES or VPRN.

On the 2-port 10GigE (Ethernet) Adapter card/module, the network interface can only be created on the v-port (not the ring ports).

The 7705 SAR can be used as an LER (label edge router) or LSR (label switch router).

OSPF, RIP, IS-IS, and BGP are supported as dynamic routing protocols, and static routes to next-hop addresses are also supported.

Some network Ethernet ports support network egress per-VLAN shapers on a per-network-interface basis. Refer to the “Per-VLAN Network Egress Shapers” section in the 7705 SAR OS Quality of Service Guide for details.

Dynamic ARP and Static MAC entry

The MAC address of the far end can be learned dynamically or be statically configured.

ARP is the common way to dynamically resolve the MAC address of next-hop IP hosts and is the primary way to resolve IP-to-MAC associations. ARP packets are sent as soon as a MAC address resolution is needed for a given IP address.

Static configuration of MAC addresses for next-hop routers is also supported. Static configuration provides a higher level of security against IP hijacking attacks.

Note: Because timeout is built into dynamic ARP, the MAC address of the remote peer needs to be renewed periodically. The flow of IP traffic resets the timers back to their maximum values. In the case of LDP ECMP, one link could be used for transporting user MPLS (pseudowire) traffic while the LDP session could be transported on another equal cost link. In ECMP for LDP and static LSP cases, it is important to ensure that the remote MAC address is learned and does not expire. Some of the equal cost links might only be transporting MPLS traffic, and in the absence of IP traffic, learned MAC addresses will eventually expire. Configuring static ARP entries or running continuous IP traffic ensures that the remote MAC address is always known. Running BFD for fast detection of Layer 2 faults or running any OAM tools with SAA ensures that the learned MAC addresses do not expire. For information on LDPs and static LSPs, refer to the 7705 SAR OS MPLS Guide.

Configurable ARP Retry Timer

A timer is available to configure a shorter retry interval when an ARP request fails. An ARP request may fail for a number of reasons, such as network connectivity issues. By default, the 7705 SAR waits 5000 ms before retrying an ARP request. The configurable retry timer makes it possible to shorten the retry interval to between 100 and 30 000 ms.

Note: The ARP retry default value of 5000 ms is intended to protect CPU cycles on the 7705 SAR, especially when it has a large number of interfaces. Configuring the ARP retry timer to a value shorter than the default should be done only on mission-critical links, such as uplinks or aggregate spoke SDPs transporting mobile traffic; otherwise, the retry interval should be left at the default value.

The configurable ARP retry timer is supported on VPRN and IES service interfaces, as well on the router interface.

Proxy ARP

Proxy ARP is a technique by which a router on one network responds to ARP requests intended for another node that is physically located on another network. The router effectively pretends to be the destination node by sending an ARP response to the originating node that associates the router’s MAC address with the destination node’s IP address (acts as a proxy for the destination node). The router then takes responsibility for routing traffic to the real destination.

Proxy ARP simplifies networking schemes because it enables nodes on a subnet to reach remote subnets without the need to configure routing or a default gateway.

The 7705 SAR supports both proxy ARP and local proxy ARP. Local proxy ARP is similar to proxy ARP except that it is used within a subnet; the router responds to all requests for IP addresses within the subnet and forwards all traffic between the hosts in the subnet. Local proxy ARP is used on subnets where hosts are prevented from communicating directly.

Typically, routers support proxy ARP only for directly attached networks. The 7705 SAR supports proxy ARP for all known networks in the routing instance where the virtual interface proxy ARP is configured.

Proxy ARP is supported on:

1. the global routing table
2. IES service interfaces
3. VPRN service interfaces

A typical application for proxy ARP is when hosts in a private subnet need to communicate to host/servers via the public Internet; for example, when using network address translation (NAT). Source NAT can be used for creating connections from inside (private network) to outside (public network). If an arriving IP packet on the 7705 SAR matches the NAT policy rules, an internal mapping is created between the private source IP address/source port and a public source IP address/source port. The public IP address and port are configured in the NAT pool policy.

Proxy ARP is therefore required for Source NAT when the NAT pool uses a range of IP public addresses. The NAT pool public IP address can either be in a different subnet than the public interface or in the same subnet as the public interface. Proxy ARP can be used to respond to ARP requests for an IP address in these NAT pools.

Note: Only remote proxy ARP is applicable for NAT.

In order to support NAT and other edge-like environments, proxy ARP supports policies that allow the provider to:

1. configure prefix lists that determine for which target networks proxy ARP will be attempted
2. configure prefix lists that determine for which source hosts proxy ARP will be attempted

As an example, when a source NAT pool is configured with a dynamic IP pool with the address range 1.1.1.2 to 1.1.1.254 on the public interface 1.1.1.1, proxy ARP can be used to resolve the ARP request of the NAT pool hosts with the local interface (1.1.1.1) MAC address (remote proxy ARP).

As another example, if a NAT pool of addresses in the range 2.2.2.1 to 2.2.2.100 is configured on the public Layer 3 interface 128.251.10.59, then by enabling remote proxy ARP, the 7705 SAR will respond to ARP requests from hosts 2.2.2.1 to 2.2.2.100. In addition, a route policy with a prefix list can be created and used as a proxy ARP policy for finer granularity of the IP range for which proxy ARP is being used.

For detailed information on NAT, see NAT.

System Interface

The system interface is associated with the node, not a specific interface. It is used during the configuration of the following entities:

The system interface is also referred to as the loopback interface. It is used as the router identifier if a router ID has not been explicitly configured. Additional loopback interfaces can be configured; however, the system interface is a special loopback interface.

The system interface is used to preserve connectivity (when alternate routes exist) and to decouple physical connectivity and reachability. If an interface carrying peering traffic fails, and there are alternative links to the same peer system interface, peering could be either unaffected or re-established over the alternate links. The system interface IP address is also used for MPLS and pseudowire/VLL signaling (via targeted LDP).

IPv6 Address Format

IPv6 uses a 128-bit address, as opposed to the IPv4 32-bit address. Unlike IPv4 addresses, which use the dotted-decimal format, with each octet assigned a decimal value from 0 to 255, IPv6 addresses use the colon-hexadecimal format X:X:X:X:X:X:X:X, where each X is a 16-bit section of the 128-bit address. For example:

2001:0DB8:0000:0000:0000:0000:0000:0000

Leading zeros can be omitted from each block in the address. A series of zeros can be replaced with a double colon. For example:

2001:DB8::

The double colon can only be used once in an address.

The IPv6 prefix is the part of the IPv6 address that represents the network identifier. The network identifier appears at the beginning of the IP address and is made up of the network address and subnet address. The IPv6 prefix length, which begins with a forward slash (/), specifies the number of bits in the network identifier; this is similar to the subnet mask in IPv4 addresses. For example, the address 1080:6809:8086:6502::1/64 means that the first 64 bits of the address represent the network identifier; the remaining 64 bits represent the node identifier.

The following adapter cards support the full IPv6 subnet range for IPv6 static routes and interface IP addresses:

For these cards, the supported route range for statically provisioned or dynamically learned routes is from /1 to /128. Supported interface IP address prefixes are from /4 to /127, and /128 on system or loopback interfaces.

For all other cards, modules, and ports (including the v-port on the 2-port 10GigE (Ethernet) module), the supported range for statically provisioned or dynamically learned routes is from /1 to /64 or is /128 (indicating a host route). Supported interface IP address prefixes are from /4 to /64, and /128 on system or loopback interfaces.

IPv6 Headers

The IPv6 header format is shown in Figure 1. Table 2 describes the fields.

Figure 1:  IPv6 Header Format 

Neighbor Discovery

IPv6 provides autoconfiguration of addresses, where equipment connecting to an IPv6 network can autoconfigure a usable address. There are two types of address autoconfiguration: stateless and stateful. Stateless autoconfiguration requires no manual configuration of hosts, minimal configuration of routers, and no servers. The host generates its own addresses using locally available information and information advertised by routers, such as the 7705 SAR. Stateless autoconfiguration is a feature of the neighbor discovery protocol.

Stateful autoconfiguration involves hosts obtaining interface addresses and/or configuration information from a server. For more information on stateful configuration, see DHCP Relay and DHCPv6 Relay.

Stateless autoconfiguration uses two neighbor discovery messages: router solicitation and router advertisement. The host sends router solicitation messages to find routers, and the routers send router advertisement messages to indicate their presence. The host sends the router solicitation message to all routers, requesting the IPv6 prefix as well as the IPv6 address of the routers. Each router responds with a router advertisement message indicating their IPv6 prefix and IPv6 address.

Neighbor discovery performs Layer 2 neighbor address resolution similar to ARP in IPv4. In addition, the neighbor discovery protocol performs a neighbor reachability function, where a “stale” neighbor entry is probed for reachability using a unicast neighbor solicitation message. This function ensures that link-layer address changes will be discovered reliably in addition to confirming the presence of the IPv6 neighbor.

Neighbor discovery is implemented within ICMPv6.

DHCP Relay and DHCPv6 Relay

The 7705 SAR provides DHCP/BOOTP Relay agent services and DHCPv6 Relay agent services for DHCP clients. DHCP is used for IPv4 network addresses and DHCPv6 is used for IPv6 network addresses. Both DHCP and DHCPv6 are known as stateful protocols because they use dedicated servers to maintain parameter information.

In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. The server maintains a database that keeps track of which addresses have been assigned to which hosts.

The 7705 SAR supports DHCP Relay on the base router, and on access IP interfaces associated with IES and VPRN. Each DHCP instance supports up to 8 DHCP servers.

The 7705 SAR supports DHCPv6 Relay on access IP interfaces associated with IES. Each DHCPv6 instance supports up to 8 DHCPv6 servers. For more information on DHCPv6 Relay, refer to the 7705 SAR OS Services Guide, “DHCP Relay”.

Local DHCP Server

The 7705 SAR supports local DHCP server functionality on the base router and on access IP interfaces associated with VPRN, by dynamically assigning IPv4 addresses to access devices that request them. This standards-based, full DHCP server implementation allows a service provider the option to decentralize IP address management into the network. The 7705 SAR can support public and private addressing in the same router, including overlapped private addressing in the form of VPRNs in the same router.

The 7705 SAR acts as a DHCP server only; it does not currently function as a DHCPv6 server.

An administrator creates pools of addresses that are available for assigned hosts. Locally attached hosts can obtain an address directly from the server. Routed hosts receive addresses through a relay point in the customer’s network.

When a DHCP server receives a DHCP message from a DHCP Relay agent, the server looks for a subnet to use for assigning an IP address. If configured with the use-pool-from-client command, the server searches Option 82 information for a pool name. If a pool name is found, an available address from any subnet of the pool is offered to the client. If configured with the use-gi-address command, the server uses the gateway IP address (GIADDR) supplied by the relay agent to find a matching subnet. If a subnet is found, an address from the subnet is offered to the client. If no pool or subnet is found, then no IP address is offered to the client.

IPv4 address assignments are temporary and expire when the configured lease time is up. The server can reassign addresses after the lease expires.

If both the no use-pool-from-client command and the no use-gi-address command are specified, the server does not act.

Session Creation

A NAT session is established by extracting session packets to the CSM to match them against NAT rules. Packet extraction is based on zone configuration. If a packet is inbound to or outbound from a zone, the packet is passed to the CSM and checked against NAT rules. If the extracted packet matches a NAT policy and an accompanying NAT action, a NAT session is created. NAT sessions created on the CSM are downloaded to the datapath and the throughput of the session is constrained by the 7705 SAR datapath throughput.

A 6-tuple lookup (source IP, destination IP, source port, destination UDP or TCP port, protocol, and source zone) is performed for a packet arriving on the ingress datapath. If there is a match, the packet has NAT applied to it and is routed based on the datapath NAT session table.

Once the active session is downloaded (established) any subsequent packet will match the established session and a 6-tuple will not be extracted or checked against the NAT policy.

When the downloaded NAT session times out, or closes because of TCP connection termination, the session is deleted from the datapath.

On the 7705 SAR-8 and 7705 SAR-18, NAT sessions survive a CSM redundancy switch.

NAT Zones

NAT configuration is based on zones. Zones segment a network, making it easier to control and organize traffic. A zone consists of a group of Layer 3 interfaces with common criteria, bundled together. NAT policies, which define a set of rules that determine how NAT should direct traffic, can be applied to the entire zone.

With source NAT, a traffic session can only be initiated from a private domain to a public domain. Unless a session is created, packets from the public domain cannot be forwarded to the private domain. All arriving packets from the private domain, which are routed towards a public interface are checked to determine if they traverse a NAT zone. If so, the packets are examined against the NAT policy rules. If there is a match between the policy and the packet, NAT is applied to the packet. Source NAT changes the source IP address and the source port of the packet, based on the configured NAT pool.

Zones can be segmented as small as a single interface or as large as the maximum number of interfaces supported by 7705 SAR. For example, in metrocell applications, all the SAPs on the access point used to aggregate the metrocell can be placed in a single zone (zone 2) and the uplink public interface can be placed in another zone (zone 1). All traffic routed between the two zones uses NAT rules based on the NAT policies created for zone 1 and zone 2.

An example of the above zone configuration is shown in Figure 2.

Note: Zone 1 or zone 2 can be omitted if no specific security policy match criteria are required on the zone. If a packet does not travel between any zones, then NAT policies are not applied.

Figure 2:  Zone Configuration in a Mobile Backhaul Network 

In Figure 2, the OAM traffic from the metrocell is not encrypted. The OAM traffic is aggregated into a single VPRN service and IPSec functionality encrypts the OAM traffic. The encrypted traffic enters IES 10 with an IPSec header that has a routable IP destination address (typically to a security gateway) in addition to the encrypted payload. The far end destination IP address can be reached through IES uplink zone 1 or GRT uplink zone 1. Since the traffic from IES 10 to the uplink zone crosses a zone boundary, the zone policy is applied to the uplink interface, and NAT is applied to the packet. The source IP address in the packet is replaced with the IP address of the uplink Interface.

Similarly, in Figure 2, traffic from the metrocell (indicated by the dashed line), is encrypted by the metrocell with a valid IP header that contains a destination IP address (typically to a security gateway). The far end destination is reachable through IES uplink zone 1 or GRT uplink zone 1. The packet has NAT applied to it because the packet must cross a zone boundary. The source IP address of the metrocell packet that enters IES 2 is replaced with the source IP address of IES uplink zone 1 as it exits the 7705 SAR. In addition the source UDP/TCP port may also be replaced depending on the NAT policy configured for the zone.

In both of the cases described above, NAT is applied to the IP traffic according to NAT zone policy rules configured for IES uplink zone 1 or GRT uplink zone 1.

When using NAT in conjunction with IPSec, all IPSec tunnels need to be configured (enabled) with NAT Traversal (NAT-T) functionality. Enabling NAT-T on IPSec causes an insertion of the UDP port below the IPSec IP header. This UDP port can be used by NAT to uniquely identify each IPSec tunnel.

With static destination NAT, when packets from a public domain arrive at a zone, their source and destination IP addresses are evaluated to determine from which interface within the zone the packet will egress.

Zone Direction

NAT policies can be configured based on traffic direction entering (inbound) the zone or leaving (outbound) the zone. A zone can be configured so that all traffic inbound to the zone has NAT applied to it based on the configured NAT policy for that zone. Likewise, a zone can be configured so that all traffic leaving the zone has NAT applied to it.

An example of inbound zone direction is shown in Figure 3. All traffic entering zone 2 has NAT applied to it based on the configured NAT policy assigned to zone 2.

Figure 3:  Zone Direction (Inbound) 

An example of outbound zone direction is shown in Figure 4. All traffic leaving zone 1 has NAT applied to it based on the configured NAT policy assigned to zone 1.

Figure 4:  Zone Direction (Outbound) 

NAT Security Profile

A NAT security profile defines security profile features such as session idle timeouts. Profiles can vary from subscriber to subscriber and are applied to policies, which are then applied to zones at the time the zone is created. All profile timeouts are defined in days, hours, minutes, and seconds. Profiles are referenced by NAT policies.

Profile timeouts are used for timing out datapath sessions within specified connection states. For example, in a TCP three-way handshake, each state has its own configurable timeout value. If the TCP connection has not transitioned from a state within the time period of the configured timeout, the session will automatically time out and be removed from the datapath.

Note: NAT security profile 1 is the default profile and cannot be modified. By default, this profile is assigned to any security policy that does not have a profile.

NAT profile attributes are described in Table 5.

NAT Policies

A NAT policy defines the method by which NAT should be applied to traffic that is inbound to or outbound from a NAT zone. Policies can vary from subscriber to subscriber and are applied to zones at the time the zone is created. NAT policies are all of type NPAT, meaning that they use both a network address translation and port address translation mechanism.

Within a NAT policy, a specific set of matching criteria can be configured. If there is a match on a packet, an action is applied. If the action is NAT, the packet has NAT applied to it based on the configured NAT pool IP address and ports.

Note: A security policy is a template that can be applied to multiple zones.

NAT policy attributes and packet matching criteria are described in Table 6.

Dynamic Source NAT

Source NAT can be used to create sessions from inside a private network to an outside (public) network. If an arriving IP packet on the 7705 SAR matches the NAT policy rules, an internal mapping is created between the inside (private) source IP address/source port and an outside (public) source IP address/source port. The public IP address and port are configured in the NAT pool policy.

NAT automatically creates a reverse mapping for arriving traffic from the public domain to the private domain for the same connection. This reverse mapping is based on an outside destination IP address and destination port to an inside destination IP address and destination port.

The configurable outside NAT pool for the source IP address and source port can be either a range of addresses and ports or a unique IP address and port.

The 7705 SAR also supports a single public IP address so that all inside (private) source IP addresses can be mapped to a single outside IP address and a range of ports. In this case, the interface name can be assigned to the NAT pool configuration. For ease of configuration, any local interfaces on the 7705 SAR can be assigned to the NAT pool (for example, local Layer 3 interfaces, loopback interfaces).

By assigning the Layer 3 interface name, the NAT pool inherits the IP address of that specific interface. For a DHCP client, the NAT pool IP address can change based on the IP address assigned to the interface by the DHCP server. If the interface IP address changes, all associated NAT sessions are cleared and re-established.

Local Traffic and NAT

Source NAT does not support self-generated traffic such as OSPF, BGP, or LDP.

Only packets transiting the 7705 SAR node have NAT applied to them. Any packet arriving on the 7705 SAR with a local IP address will be checked against active NAT sessions on the datapath (6-tuple lookup), and if there is no match, the packet is sent to the CSM for processing as local traffic.

Port Forwarding (Static Destination NAT)

Port forwarding consists of mapping an outside destination port to an inside destination IP address and port. For example, a packet arriving from outside on port X and using a UDP protocol (from any IP address) is mapped to an inside destination port and destination IP address.

A typical use of port forwarding is shown in Figure 5. Each inside application is uniquely accessible via an outside port. For example, the surveillance camera behind the 7705 SAR can be reached via the UDP protocol and port 50. Any packet from any IP address arriving on destination port 50 is mapped to an internal destination IP address of 192.168.1.3 and destination port 50.

Note: Using port forwarding for well-known ports can disrupt in-band local management traffic.

Figure 5:  Static Port Forwarding with NAT 

Static port forwarding can provide accessibility to applications behind a single IP address. Each application can be uniquely accessed via the public IP address and the destination port for that application.

Matching criteria for port forwarding includes local interface IP address, source IP address, and source UDP/TCP port.

Session Resource Alarms

The system monitors the overall session resource utilization. An alarm state is declared if the utilization exceeds the user-configurable high watermark (session-high-wmark). The alarm condition is only cleared when the utilization has dropped below the user-configurable low watermark (session-low-wmark).

If the thresholds are not configured, an alarm is raised if utilization reaches 100% and is cleared when utilization drops to 0%.

Session resource utilization alarms are described in Table 7.

NAT Support for Fragmented Packets

The NAT functionality on the 7705 SAR can process UDP packet fragments; however, the fragment containing the header must arrive first. If this condition is not met, the following actions occur:

On the 7705 SAR-8 and 7705 SAR-18, in addition to the condition requiring the fragment containing the header to arrive first, all fragments of a given packet must arrive on the same adapter card for processing.

For example, if an upstream router in the network performs IP ECMP load balancing and the load balancing takes Layer 4 port information into account in its hashing algorithm, it is possible that the algorithm will put the packet fragment that contains the UDP header information (that is, the first fragment of the packet) on one Layer 3 interface and the packet fragment that does not contain the UDP information (that is, the subsequent fragments of the packet) on a different Layer 3 interface. When packet fragments traverse different Layer 3 interfaces, depending on the interface latency, it is possible that the fragments will arrive out of sequence at the destination. Should this occur and the non-UDP packet fragments arrive ahead of the packet fragment that contains the UDP header, the 7705 SAR router will discard the packets that do not have UDP information because they arrived out of sequence. In order to avoid fragment sequencing issues caused by Layer 4 load balancing hashing algorithms such as IP ECMP or LAG, it is recommended that these algorithms be disabled on all routers in the network if it is foreseen that packet fragments might be arriving on the 7705 SAR router.