IP router configuration

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. See the ‟Per-VLAN Network Egress Shapers” section in the 7705 SAR Quality of Service Guide for details.

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

• LSP creation (next hop) – when configuring MPLS paths and LSPs

• the addresses on a target router – to set up an LDP, OSPF, or BGP session between neighbors and to configure SDPs (the system interface is the service tunnel endpoint)

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).

Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow (or link to) an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface) and use it as the source IP address for packets originating from the interface.

The benefits of using unnumbered interfaces are:

• ISP backhaul can be enabled with a single IP address allocated to the CE nodes (network interface address is coupled with the system IP address)

• nodes can be added to or deleted from a network without address changes—unnumbered interfaces are linked to a centralized IP address and therefore do not require any address change if the nodes are relocated. After a topology change, the ARP table is updated to ensure reachability and the upper layer protocols re-establish the peering sessions.

Unnumbered interfaces are supported on:

• network interfaces

• IES interfaces

• VPRN interfaces

Only IPv4 addresses are supported.

Unnumbered interfaces are supported for the IS-IS and OSPF routing protocols and for MPLS (RSVP-TE and LDP). See the 7705 SAR Routing Protocols Guide, ‟Unnumbered interfaces” in the OSPF and IS-IS sections, for more information about IS-IS and OSPF unnumbered interface support. See the 7705 SAR MPLS Guide, ‟RSVP-TE Support for Unnumbered Interfaces” and ‟LDP Support for Unnumbered Interfaces”, for more information about MPLS unnumbered support.

This feature is supported via both dynamic and static ARP.

The following ports on the 7705 SAR adapter cards, modules, and fixed platforms support IP unnumbered interfaces:

• any datapath Ethernet port with null, dot1q, or qinq encapsulation (with the exception of the 10GigE port on the 2-port 10GigE (Ethernet) Adapter card)

• v-port on the 2-port 10GigE (Ethernet) Adapter card

• MWA ports on the Packet Microwave Adapter card

• any T1/E1 port (access or network) with ppp encapsulation

• any DS3/E3 port (network) with ppp encapsulation

• any OC3/STM1 port (network) with ppp-auto encapsulation (POS)

An IP address range can be reserved for IES or VPRN services by using the config>router>service-prefix command. When a service interface is configured, the IP address must be in the range specified in the service-prefix command. If the service-prefix command is not configured, then no limitation exists.

Addresses in the range of a defined service-prefix can be allocated to a network port unless the exclusive parameter is specified. Then, the address range is exclusively reserved for services.

When defining a range that is a superset of a previously defined service prefix, the new superset definition will replace the original configuration. For example, if a service prefix exists for 10.10.10.0/24, and a new service prefix is configured as 10.10.0.0/16, then the old address (10.10.10.0/24) will be replaced with the new address (10.10.0.0/16).

When defining a range that is a subset of a previously defined service prefix, the subset will replace the existing superset providing that the addresses used by services are not affected. For example, if a service prefix exists for 10.10.0.0/16, and a new service prefix is configured as 10.10.10.0/24, then the 10.10.0.0/16 entry will be unreserved as long as there no services configured that are using the 10.10.x.x addresses other than 10.10.10.x.

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. In its full notation, an IPv6 address appears as shown in the following example:

2001:0db8:0a0b:12f0:0000:0000:0000:0001

As per RFC 5952, the above IPv6 address appears as:

2001:db8:a0b:12f0::1

Leading zeros must be omitted from each block in the address. A series of zeros can be replaced with a double colon. 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:

• 6-port Ethernet 10Gbps Adapter card

• 8-port Gigabit Ethernet Adapter card, version 2 and version 3

• 2-port 10GigE (Ethernet) Adapter card (on the v-port)

• 10-port 1GigE/1-port 10GigE X-Adapter card

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.

The IPv6 header format is shown in the following figure and the table describes the fields.

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 about 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.

6PE allows IPv6 domains to communicate with each other over an IPv4 MPLS core network. Because forwarding is based on MPLS labels, backbone infrastructure upgrades and core router reconfiguration is not required in this architecture. 6PE is a cost-effective solution for IPv6 deployment.

Enhancements to 6PE allow IPv4 domains to communicate with each other over an IPv6 core network. The 7705 SAR supports BGP next-hop resolution on IPv6 SR-ISIS and LFPv6 tunnels for the following address families:

• label-IPv4
• label-IPv6
• VPN-IPv4
• VPN-IPv6

A 7705 SAR router can use the advertise-ipv6-next-hops command to advertise to peers that BGP routes belonging to the specified address families can be advertised with a global IPv6 address. For VPN-IPv4 or label-IPv4 routes, the remote peer must also advertise the necessary extended next-hop encoding capability with the extended-nh-encoding command. If the peer does not advertise the correct extended next-hop encoding, the 7705 SAR does not advertise those routes. If the peer does receive a label-IPv4 or VPN-IPv4 route without having advertised the matching extended next-hop encoding, the UPDATE message is considered malformed, causing either a session reset or treat-as-withdraw behavior, depending on the error handling settings.

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 and VPRN. Each DHCPv6 instance supports up to 8 DHCPv6 servers. For more information about DHCPv6 relay, see the 7705 SAR Services Guide, ‟DHCPv6 Relay”.

The 7705 SAR supports local DHCP server functionality on the base router and on access IP interfaces associated with VPRN, by dynamically assigning IPv4 or IPv6 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 or 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.

To prevent IPv4 address conflicts, the enable-ping-pool-address command can be configured on a DHCP server. The command is not supported on DHCPv6 servers. When a DHCP server configured with the enable-ping-pool-address command receives a DHCP message from a DHCP relay agent, the server pings the IPv4 address before offering it to the client. If there is no response, the 7705 SAR assumes the address is available and offers it to the client as described below. If there is a response, the address is removed from the pool of available addresses and added to a pool of conflicting addresses. The conflicting address is not offered for any future requests until the user manually clears it from that pool.

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, no IP address is offered to the client.

When a DHCPv6 server receives a DHCP message from a DHCPv6 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 17 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-link-address command, the server uses the address supplied by the relay agent to find a matching subnet prefix. If a prefix is found, an address from the subnet is offered to the client. If no pool or prefix is found, no IP address is offered to the client.

IPv4 and IPv6 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 or no use-link-address command are specified, the server does not act.

Static route packets can be forwarded to an indirect next hop over a tunnel programmed in the TTM using the config>router>static-route-entry>tunnel-next-hop command.

If the tunnel-next-hop context is enabled and the resolution command under this context is set to any, any supported tunnel type in the static route context can be selected following the TTM preference. If resolution is set to disabled, the tunnel binding is removed and resolution to the next hop resumes in the RTM. If resolution is set to filter, the route can be bound to a subset of active tunnels in the TTM, determined by the resolution-filter configuration in the tunnel-next-hop context.

The following tunnel types are supported in the static route context: LDP, RSVP-TE, SR-ISIS, SR-OSPF, and SR-TE.

See Router Global Commands for more information about the tunnel-next-hop command.

The ECMP decision is performed at the ingress point on the node; therefore, ECMP must always be enabled on the ingress interface.

To enable LDP and GRT IP ECMP, the config>router>ecmp command is used.

To enable IP ECMP on a per-IP, next-hop basis (far-end PE) under the IP-VPRN context, the config>service>vprn>ecmp command is used.

For LDP ECMP, the lsr-load-balancing command under the system context enables optional LSR load balancing for the node. The lsr-load-balancing command under the router interface context overrides the system configuration for the specified interface.

For IP ECMP, the l4-load-balancing command under the system context enables optional Layer 4 load balancing for the node. The l4-load-balancing command under the router interface context, IES service interface context, or VPRN service interface context overrides the system configuration for the specified interface.

For IP ECMP, the teid-load-balancing command can be configured under the router interface context, IES interface context, and VPRN interface context.

For both LDP and IP ECMP, the system-ip-load-balancing command can be configured under the system context.

For information about the load-balancing commands, see Router interface commands, the 7705 SAR Basic System Configuration Guide, ‟System Information and General Commands”, and the 7705 SAR Services Guide, ‟VLL Services Command Reference”, ‟VPLS Command Reference”, ‟IES Command Reference”, and ‟VPRN Services Command Reference”.

The S-BFD reflector is configured using the following CLI commands:

configure 
   bfd 
      seamless-bfd 
        [no] reflector <name> 
                  description <string>
                  discriminator <value>
                  local-state {up | admin-down}
                  [no] shutdown

S-BFD reflection is enabled on the router when the S-BFD discriminator is configured. The discriminator value is configured from a defined range.

When the router receives an S-BFD packet from the initiator and the value in the YourDiscriminator field in the packet matches the configured discriminator value on the local router, the local router will send the S-BFD packet back to the initiator via a routed path. The State field in the reflected packet is populated with either the Up or AdminDown value based on the local-state configuration.

When the S-BFD reflector returns the S-BFD packet to the initiator, the source and destination UDP ports are swapped in the S-BFD response; that is, the received source port becomes the transmitted destination port and the received destination port becomes the transmitted source port.

S-BFD control packets are discarded when the reflector is not configured, or is shut down, or when the YourDiscriminator field does not match the discriminator of the reflector. Only IPv4 addresses are supported.

Before an application can request the establishment of an S-BFD session, a mapping table of remote discriminators to far-end peer IP addresses must exist on the router. This is statically configured using the following CLI commands:

configure>router>bfd
   seamless-bfd
      peer <ip-address> discriminator <remote-discriminator>
      peer <ip-address> discriminator <remote-discriminator>
      ...
      exit

With S-BFD, no session setup is required. The S-BFD initiator immediately begins sending S-BFD packets when it knows the far-end reflector discriminator. The initiator state goes from AdminDown to Up when it begins to send S-BFD packets.

The S-BFD initiator sends S-BFD packets to the reflector using the following fields:

• Src IP – the local session IP address

• Dst IP – the configured reflector IP address

• MyDiscriminator – the locally assigned discriminator value

• YourDiscriminator – the configured reflector discriminator value

When the initiator receives a valid response from the reflector with an Up state, the initiator declares the S-BFD session up. When the initiator receives a valid response from the reflector with an AdminDown state, the initiator declares the S-BFD session down and reduces the transmission interval but does not consider the session failed.

If the initiator fails to receive a certain number of responses as determined by the BFD multiplier in the BFD template for the session, the initiator declares the S-BFD session failed.

If any of the discriminators change, the session is taken down and the router attempts to start a new session with the new values.

If the reflector discriminator is changed at the far-end peer, the session fails. If the reflector discriminator is changed at the far-end peer and the mapping has not been updated locally before the system checks for a new reflector discriminator from the local mapping table, the session is bounced and brought up with the new values.

If any of the discriminators are deleted, the corresponding S-BFD sessions are deleted.

An application that requires an S-BFD session must provide sufficient information to BFD so that it can create a unique S-BFD session to a remote IP address associated with the application object, such as an LSP. The session type (S-BFD) is determined by the application. BFD checks that the BFD template parameters are appropriate for the requested session type. The only S-BFD session type that is supported is np.

An S-BFD session is configured using the following parameters in the config>router>bfd>bfd-template context:

• multiplier

• receive interval

• transmission interval

• type

An S-BFD session must also include the following parameters configured in the config>router>bfd>seamless-bfd context:

• remote reflector IP address

• remote reflector discriminator

If ECMP is enabled, which provides multiple primary next hops for a prefix, IP FRR is not used. That is, the LFA next hops are not populated in the RTM and the ECMP paths are used instead.

IGP shortcuts are an MPLS functionality where LSPs are treated like physical links within IGPs; that is, LSPs can be used for next-hop reachability. If an RSVP-TE LSP is used as a shortcut by OSPF or IS-IS, it is included in the SPF calculation as a point-to-point link for both primary and LFA next hops. It can also be advertised to neighbors so that the neighboring nodes can also use the links to reach a destination via the advertised next hop.

IGP shortcuts can be used to simplify remote LFA support and simplify the number of LSPs required in a ring topology.

When both IGP shortcuts and LFA are enabled under OSPF or IS-IS, and IP FRR is also enabled, the following applies:

• a prefix that is resolved to a direct primary next hop can be backed up by a tunneled LFA next hop

• a prefix that is resolved to a tunneled primary next hop will not have an LFA next hop; it relies on RSVP-TE FRR for protection

To configure IP FRR, LFA calculation by the SPF algorithm must first be enabled under the OSPF, OSPFv3, or IS-IS protocol level with the command:

config>router>ospf>loopfree-alternates

or

config>router>ospf3>loopfree-alternates

or

config>router>isis>loopfree-alternates

LFA can also be enabled on an OSPF or OSPFv3 instance within a VPRN service with the command:

config>service>vprn>ospf>loopfree-alternates

or

config>service>vprn>ospf3>loopfree-alternates

Next, IP FRR must be enabled to use the LFA next hop with the command config>router>ip-fast-reroute.

If IGP shortcuts are used, they must be enabled under the OSPF or IS-IS routing protocol. As well, they must be enabled under the MPLS LSP context, using the command config>router>mpls>lsp>igp-shortcut.

For information about LFA and IGP shortcut support for OSPF and IS-IS, see the 7705 SAR Routing Protocols Guide, ‟LDP and IP fast reroute for OSPF prefixes” and ‟LDP and IP fast reroute for IS-IS prefixes”.

The 7705 SAR supports both IP FRR and LDP FRR; for information about LDP FRR, see the 7705 SAR MPLS Guide, ‟LDP Fast Reroute (FRR)”.

A security session can be directionally aware. For example, a firewall security policy entry can be configured to allow packets with source IP address X and source port Y that are traveling from the private network to the public network to traverse the firewall. This means that any traffic arriving from the outside network on IP address X and port Y is denied entry to the inside network. However, a host in the private network can create a session from inside to outside for IP address X and port Y. Once this inside-to-outside session is created, traffic with IP address X and port Y traveling in the reverse direction (from outside to inside) is now allowed.

Similarly with NAT, a source NAT policy entry can be created to apply NAT on all arriving packets with source IP address X and source port Y to an outside source IP address A and source port B. When the first packet with IP address X and port Y arrives, NAT creates an inside-to-outside session and punches a hole through the firewall for that specific IP address and port number, allowing all packets to be transmitted from the inside network to the outside network.

Typically, the MTU in a private LAN is larger than the MTU of a public network; the MTU of a private LAN is usually 1500 bytes whereas the MTU of a public network is usually less than 1500 bytes. In addition, packets destined for the public network may have an additional header, such as a transport tunnel, appended to the original packet. These two factors can cause the TCP/IP packet to become fragmented when entering the public network. Fragmentation is not desirable for TCP applications where the server needs a lot of processing power to reassemble the fragmented packets.

To avoid fragmentation, the maximum segment size (MSS) of application data in a TCP connection can be adjusted. Applications use the MSS to calculate the maximum number of data bytes (not including the header) that can be transmitted in a single packet. By lowering the MSS value, an outgoing packet's MTU can be made smaller than the public network MTU, ensuring that the packets entering the public network will not be fragmented.

The 7705 SAR supports TCP MSS adjustment. When acting as a CE router, the 7705 SAR can insert or modify the MSS value in the header of a TCP SYN or SYN-ACK packet. The sending and receiving CE routers set their MSS based on the outgoing interface MTU. The routers exchange TCP SYN or SYN-ACK packets during TCP session negotiation, engaging in a three-way handshake to compare and then select the lowest MSS value.

On the 7705 SAR, MSS configuration and adjustment is supported on the following cards and platforms:

• on the 7705 SAR-8 Shelf V2 and the 7705 SAR-18:

  • 2-port 10GigE (Ethernet) Adapter card

  • 6-port Ethernet 10Gbps Adapter card

  • 8-port Gigabit Ethernet Adapter card, version 3

  • 10-port 1GigE/1-port 10GigE X-Adapter card, version 2 (7705 SAR-18 only)

  • Packet Microwave Adapter card

• 7705 SAR-Ax

• 7705 SAR-H

• 7705 SAR-Hc

• 7705 SAR-Wx

• 7705 SAR-X

When the tcp-mss command is configured, the 7705 SAR can adjust the MSS field in the TCP SYN packet or SYN-ACK packet. The 7705 SAR can also insert the MSS field in the TCP SYN packet and SYN-ACK packet if the field is not present.

The command is supported in the general router, VPRN service, and IES CLI contexts; MSS configuration interfaces per context  lists the supported interface types for each context.

The tcp-mss command is supported for TCP packets arriving on or leaving from MP-BGP tunnels in a VPRN only if tcp-mss is configured on VPRN SAP interfaces. Configuring tcp-mss only on the network interface that the MP-BGP traffic traverses will not cause the MSS adjustment to happen because labeled traffic can arrive on any network ingress interface, which may have different tcp-mss values configured.

TCP MSS adjustment is supported on a Layer 3 IES or VPRN interface that is used as an r-VPLS interface for a Layer 2 VPLS or EVPN service. TCP MSS adjustment enables the 7705 SAR to modify or insert the MSS field in the TCP SYN and SYN-ACK packets traveling from a Layer 2 domain to a Layer 3 domain or traveling from a Layer 3 domain to a Layer 2 domain, via the r-VPLS interface that tcp-mss is configured on. The uplink supports GRE, MPLS, IPSec, NGE, or IP transport modes.

When the tcp-mss command is configured on an interface, TCP packets with a SYN or SYN-ACK flag will have the MSS value is adjusted or inserted as follows:

• If the TCP session has no defined MSS, the 7705 SAR inserts the field in the TCP packet.

• If the MSS value of the TCP session arriving from an access interface is greater than the MSS value configured on the 7705 SAR interface, the TCP session MSS is overwritten with the lower value.

• If the MSS value of the TCP session arriving from an access interface is less than the MSS value configured on the 7705 SAR interface, the TCP session MSS does not change.

The command can be configured on an ingress interface, an egress interface, or both. When configured on both interfaces, the smallest MSS value is used.

Fragmented packets are not monitored for TCP MSS adjustment.

TCP MSS configuration and adjustment is supported for both IPv4 and IPv6 interfaces. Because the tcp-mss value is configured separately for each interface, it is possible to configure and enforce a different MSS value for IPv4 and IPv6.

Timers are used to time out a NAT or firewall session and drop it. The 7705 SAR supports configurable timers for different connections. Timers can be idle or strict. Idle timers are activated by the lack of traffic. Strict timers are used for protocol state changes and are not affected by the presence of traffic. The supported timers are described in the following table.

The following application assurance parameters can be defined in a security profile:

• DNS

• ICMP

• IP options

• strict TCP

When a 7705 SAR security profile is configured with application level gateway (ALG), the firewall/NAT engine intercepts all upstream traffic destined for TCP port 21 (the FTP control channel), UDP port 69 (the TFTP port), or some other destination port configured to support ALG. All traffic matching the policy is extracted to the CSM for examination.

If the examined traffic is found to be an FTP control channel, the corresponding data channel is programmed to the datapath. When an FTP client sends the port command in the FTP control channel, the firewall/NAT ALG intercepts this command, creates a new mapping in the firewall/NAT table, and opens the data port based on the client port command. Firewalls configured in either passive or active mode must have ALG configured in order to allow the FTP datapath through the firewall. A temporary match rule for the FTP data port is placed on top of the security policy, and TCP timer configuration is inherited from ALG policy control timers. In short, the temporary data session inherits all the control session policy/profile configuration.

Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol that is implemented on top of the UDP/IP protocol and uses port 69. TFTP was designed to be small and easy to implement; therefore, it does not have most of the advanced features offered by more robust file transfer protocols such as FTP. TFTP requests from a client are always destined for UDP port 69 on the server. The server responds by sending an ACK and/or the data on a random port. The 7705 SAR firewall and the ALG are able to detect this random port and create a temporary rule to open the UDP port in the firewall.

The ALG security profile parameter can be configured as auto, ftp, or tftp.

When the parameter is configured as auto (the default), FTP or TFTP ALG is enabled on TCP port 21 (the default port for FTP) or UDP port 69 (the default port for TFTP). The firewall will enforce use of the ALG on the FTP or TFTP session for port translation, if NAT is being used, and for pin-hole operations.

When the parameter is configured as ftp, FTP ALG is enabled on any TCP port being used for FTP. For example, if a security session has been configured for a DNAT mapping where the destination port is not TCP port 21, configuring the ALG security parameter as ftp allows the FTP ALG to be enabled on TCP ports or TCP port ranges so that the session can be treated as FTP and so that the ALG can perform the correct translation and pin-hole functions as required by FTP.

When the parameter is configured as tftp, TFTP ALG is enabled on any UDP port being used for TFTP.

Unlike auto ALG, where only the default FTP and TFTP ports are inspected for a potential ALG session, FTP ALG and TFTP ALG inspect all packets that match their policy’s matching criteria. It is recommended that a specific destination port or port range be matched so that entire port ranges are not left open for potential attackers.

The following example shows a recommended configuration for incoming (DNAT) and outgoing FTP control.

*A:7705:Dut-A> config>security# info 
----------------------------------------------
    logging
    exit
    profile 10 create
        name "ALG-FTP"
         application
            alg ftp
        exit
        timeouts
         exit
    exit
    policy 1 create
        name "Inbound Policy"
        entry 1 create
            description "match Local non-default FTP"
            match local protocol tcp
                dst-port eq 1024
            exit
            limit                     
            exit
            action nat destination 10.100.0.2 port 21
            profile "ALG-FTP"
            logging to zone
        exit
        entry 2 create
            description "match forward FTP Ctl"
            match protocol tcp
                direction zone-inbound
                dst-port eq 1024
            exit
            limit
            exit
            action forward
            profile "ALG-FTP"
            logging to zone
        exit
     exit
    commit
----------------------------------------------
*A:7705:Dut-A> config>security# 

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

• The firewall drops all fragmented packets arriving on the 7705 SAR until the fragment that contains the TCP/UDP header arrives.

• For bidirectional forwarding, packets arriving from the opposite direction are discarded because no session was created for the forward direction.

• For any TCP/UDP packets traversing from a public network to a private network and destined for a local IP address on the 7705 SAR, fragmented packets that do not contain the TCP/UDP header are extracted to the CSM for processing and an ICMP error message is sent to the sender.

• For destination NAT (port forwarding) packets traversing from a public network to a private network and destined for a local IP address on the 7705 SAR, fragmented packets that do not contain the TCP/UDP header are extracted to the CSM for processing and an ICMP error message is sent to the sender.

On the 7705 SAR-8 Shelf V2, 7705 SAR-18, and 7705 SAR-X, 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.

If packets for an application such as DNS or ICMP are fragmented and the first fragment does not contain the information needed to make a firewall decision, the packet is discarded.

A security profile configured with strict TCP requires that all packets, including packet fragments, are extracted to the CSM for processing. The CSM checks for repeated packet fragments and discards them, and also checks the fragment offset to ensure that all fragments correspond to the correct offset.

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 toward 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 the 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 the following figure.

In the figure, 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 or VPRN 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, GRT uplink zone 1, or VPRN uplink zone 1. Since the traffic from IES 10 or VPRN 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 the figure, 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, GRT uplink zone 1, or VPRN 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, GRT uplink zone 1, or VPRN uplink zone 1.

When using NAT in conjunction with IPSec, all IPSec tunnels must 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.

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 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.

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 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 the following figure. 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.

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.

With static one-to-one NAT, NAT is performed on packets traveling from an inside (private) interface to an outside (public) interface or from an outside interface to an inside interface. Static one-to-one NAT can be applied to a single IP address or a subnet of IP addresses and is performed on the IP header of a packet, not on the UDP/TCP port.

Mapping statements, or entries, can be configured to map an IP address range to a specific IP address. The direction of the NAT mapping entry dictates whether NAT is performed on a packet source IP address or subnet or on a packet destination IP address or subnet. The 7705 SAR supports inside mapping entries that map an inside IP address range to an outside IP address range sequentially.

With an inside mapping entry, the following points apply:

• Packets that originate from an inside interface and are destined for an inside interface are forwarded without any NAT being applied.

• If there is a matching one-to-one NAT mapping entry, packets that originate from an inside interface and are destined for an outside interface undergo static one-to-one NAT where NAT changes the source IP address of the packet IP header. The packet is forwarded whether or not a NAT mapping entry is found unless the drop-packets-without-nat-entry command is enabled. When a mapping entry is not found and the drop-packets-without-nat-entry command is enabled, the packet is not forwarded.

• If there is a matching one-to-one NAT mapping entry, packets that originate from an outside interface and are destined for an inside interface undergo static one-to-one NAT where NAT changes the destination IP address of the packet IP header. The packet is forwarded whether or not a NAT mapping entry is found unless the drop-packets-without-nat-entry command is enabled. When a mapping entry is not found and the drop-packets-without-nat-entry command is enabled, the packet is not forwarded.

• Packets that originate from an outside interface and are destined for an outside interface are forwarded without any NAT being applied.

Static one-to-one NAT is performed on packets that transit the node and match the mapping entry. These packets include IPSec packets, GRE packets, and IP packets. NAT can be performed on packets from a single inside interface or multiple inside interfaces that are traveling to a single outside interface or multiple outside interfaces.

Static one-to-one NAT is not performed on packets that are destined for the node nor is it performed on self-generated traffic or on routing protocols. The 7705 SAR blocks static one-to-one NAT to a public prefix that has the same IP subnet as a local interface.

Static one-to-one NAT is supported in the GRT and in VPRNs. For information about VPRNs and one-to-one NAT, see the 7705 SAR Services Guide, ‟Static One-to-One NAT and VPRN”.

The following table lists the types of outside and inside interfaces that are supported in the GRT for static one-to-one NAT.

The following steps describe how to configure a multi-chassis firewall:

1. On both routers, configure security profile, security policy, host group, and application group parameters. The parameter settings must be identical on both routers. See Security policy commands for information about configuring these parameters.

2. On both routers, configure identical security zone parameters so that the routers have the same zone ID on the same service ID and service type, the same NAT pool settings, and the same zone limits for inbound and outbound firewall sessions. The service ID and service type apply only to security zone configuration in the VPRN or IES context. For information about configuring security zone parameters in the VPRN context or in the IES context, see ‟VPRN Security Zone Configuration Commands” or ‟IES Security Zone Configuration Commands” in the 7705 SAR Services Guide. For information about configuring security zone parameters in the base router context, see Router security zone configuration commands.

3. On both routers, configure the multi-chassis firewall by configuring the following multi-chassis firewall peer parameters: the peer IP address, the system priority, and optional encryption or authentication parameters. For information about configuring these parameters, see ‟High Availability (Redundancy) Commands” in the 7705 SAR Basic System Configuration Guide.

4. On both routers, issue the config>redundancy>multi-chassis>peer>mc-firewall>no shutdown command to initiate communication between the peers and enable the master and slave selection. For more information about master and slave, see Multi-chassis firewall master/slave selection and policy and session database synchronization.

5. Issue the admin save command on each router to save the configuration.

Determining which router will be the master and which will be the slave is based on the system priority configured using the config>redundancy>multi-chassis>peer>mc-firewall>system-priority command. The router configured with the lower system priority becomes the master. If both routers have the same system priority, the router with the lowest MAC address becomes the master.

When the MCL is established and the master and slave routers are determined, the master router synchronizes its security policy configuration to the slave router over the MCL. This synchronization overwrites any security policy configuration on the slave.

In addition, the master synchronizes its session database to the slave. This synchronization is for all established security and NAT sessions. The master does not synchronize any half-open sessions to the slave. This synchronization overwrites the session database on the slave.

If policy synchronization fails, all security sessions are terminated and the security policy configuration on the slave router will be in an incomplete state. A policy synchronization flag on the master remains cleared until synchronization resumes. When synchronization completes, the policy synchronization flag changes to set. A corresponding log event is raised on the master router when the policy synchronization flag changes state.

Security zone and NAT pool information is not synchronized from the master to the slave. These parameters must be configured with identical settings on each router.

When the firewall database between the master and slave has been synchronized, the firewalls on both routers can process existing connections and signatures for arriving packets. However, the master firewall must create a datapath signature in the firewall database for each new connection.

If there is no datapath firewall database, all traffic from both the slave and master router is forwarded to the CSM on the master router. The slave router forwards its packets to the master CSM over the MCL. The master CSM examines the packet against the firewall security policy and creates a 5-tuple signature including the action (drop or forward).

This signature is downloaded to the datapath firewall database on the master and to the datapath firewall database on the slave over the MCL. From this point on, both the master and slave have the packet signature and action in their datapath firewall database.

The following steps describe how to add a new firewall security policy or modify an existing one in a multi-chassis firewall configuration:

1. On the master router, use the begin command to start an editing session.

2. In the config>security context, configure settings for security profile, host-group, app-group, or policy (rule) commands on the master router.

3. When the changes are complete, issue the commit command on the master router to save the policy settings.

   The configuration is automatically synchronized to the slave router.

4. Issue the admin save command on the master and slave routers to save the configuration.

The following steps describe how to delete a firewall security policy in a multi-chassis firewall configuration:

1. Ensure that the policy is not being used by a zone on either the master or slave router.

2. On the master router, use the begin command to start an editing session.

3. Delete a policy from the master router using the config>security>no policy policy-id | policy-name command.

4. When the policy is deleted, issue the commit command on the master router to save the change.

   The change is automatically synchronized to the slave router.

5. Issue the admin save command on the master and slave routers to save the configuration.

In a multi-chassis firewall, zone configuration is not synchronized between the master and slave routers. All zone-level configuration, including the addition and deletion of zones, must be performed on each router separately.

The master and slave routers identify zones based on their assigned zone IDs. In the VPRN and IES service contexts, zone IDs must match and be assigned to the same service ID and service type on both the master and the slave routers. In all contexts (base router, IES, and VPRN), all zone parameter configurations must match on both routers, except for the assigned interfaces.

Security logging parameters and settings must match on the master and slave routers. To configure logging for each entry of a security policy or for a zone, the policy and zone must be put into a draft state using the begin command. When the changes are complete, the commit command must be used to save them to the firewall database.

If a multi-chassis firewall activity switch occurs, the existing security sessions on the new master router do not retain their logging attributes. Instead, new sessions that are established after the switch will assume the configured logging attributes.

On the CLI, security session status, timers, and details are shown only for the master. Session statistics for each 5-tuple signature are shown on both the master and slave.

If the MCL goes down between the two firewalls for any reason, the two firewalls will function as standalone firewalls. They will each learn and process new connections arriving on the firewall, compare the connections against their own CSM firewall security policies, and program their respective databases accordingly.

When the MCL is re-established, the slave firewall will become synchronized to the master firewall. Previously learned signatures and previously provisioned configurations on the slave are overwritten with those on the master firewall.

Only source NAT is supported in multi-chassis firewall configuration. For NAT to function correctly, a loopback address with the same IP address must be created on both firewall routers. This IP address should be in the NAT pool for source NAT so that return traffic can be routed to either router and undergo reverse NAT at either firewall. Proxy ARP can be created for this loopback address. See Proxy ARP for information.

The multi-chassis firewall messages on the MCL between the master and slave can be encrypted and authenticated. Encryption and authentication are important on this link in order to avoid man-in-the-middle attacks where hackers can insert signature packets and create new unwanted states in the firewall. The MCL is encrypted using the config>redundancy>multi-chassis>peer>mc-firewall>encryption command.

The 7705 SAR supports AES128 and AED256 encryption algorithms and SHA256 and SHA512 authentication algorithms.

A security association (SA) contains the keys that are required to encrypt and authenticate the link. A security association is uniquely identified by a security parameter index (SPI). There are two SPIs for key rollover. On egress, only the active outbound SA is used for encryption and authentication. The active-outbound-sa num command identifies the active SA, where num is the SPI for that SA. On ingress, decryption is done using both SPIs. Using both SPIs means that packets can be decrypted using the current and previous keys, allowing for a smooth transition.

Use the following CLI syntax to configure a system interface:

CLI syntax:

config>router
    interface ip-int-name 
        address {ip-addr/mask-length}| {ip-addr/netmask} 

Example:

config>router# interface ‟system”
config>router>if# address 192.168.0.0/16
config>router>if# exit

On the 2-port 10GigE (Ethernet) Adapter card/module, a network address is assigned to the v-port only.

Use the following CLI syntax to configure a network interface:

CLI syntax:

config>router
    interface ip-int-name 
        address {ip-addr/mask-length | ip-addr/netmask | dhcp} [client-identifier [ascii-value | interface-name]] [vendor-class-id vendor-class-id] 
        egress
            agg-rate-limit agg-rate [cir cir-rate]
            filter ip ip-filter-id
            queue-policy name
        ingress
            filter ip ip-filter-id
        port port-name

Example:

config>router> interface "to-NOK-2"
config>router>if# address 192.168.0.1/16
config>router>if# port 1/1/1
config>router>if# egress 
config>router>if>egress# filter ip 12
config>router>if>egress# exit
config>router>if# ingress 
config>router>if>ingress# filter ip 10
config>router>if>ingress# exit
config>router>if# exit

The preceding syntax example shows a configuration where the address is entered manually. To have the interface enabled for dynamic address assignment, use the dhcp keyword and, optionally, assign client ID and vendor class ID.

In addition, to apply and configure a per-VLAN network egress aggregate shaper, use the queue-policy and agg-rate-limit commands.

The following example displays the IP configuration output showing the interface information.

A:ALU-A>config>router# info 
#------------------------------------------
# IP Configuration
#------------------------------------------
        interface "system"
            address 192.168.0.0/16
        exit
        interface "to-NOK-2"
            address 192.168.0.1/16
            port 1/1/1
            ingress
                filter ip 10
            exit

Use the following CLI syntax to configure an unnumbered interface:

CLI syntax:

config>router
    interface ip-int-name 
        unnumbered [ip-int-name | ip-address] [dhcp] [client-identifier ascii-value | interface-name] [vendor-class-id vendor-class-id] 

Example:

config>router> interface "to-NOK-3"
config>router>if# unnumbered ‟system”
config>router>if# exit

The preceding syntax example shows a configuration where the address is entered manually. To have the interface enabled for dynamic assignment of the system IP address, use the dhcp keyword and, optionally, assign client ID and vendor class ID.

If a packet does not match any of the rules in a security policy, the packet is dropped from a security session because the default security policy action is to reject non-matching packets. With rule-based logging, in order to see that event in the event log, the policy must be configured with a rule to log rejected, non-matching packets to the log-id, and this rule must be configured as the last entry in the policy.

Use the following CLI syntax to configure rule-based security logging:

CLI syntax:

config>security
    logging
        profile {profile-id | profile-name} [create]
            description description-string 
            event-control event-type [event event] {suppress | throttle | off}
            name name 
        exit
        log-id {log-id | log-name} [create] 
            description description-string
            destination {memory [size] | syslog syslog-id}
            name name 
            profile {logging-profile-id | logging- profile-name} 
            no shutdown 
        exit
    exit
    begin 
    profile {profile-id | profile-name} [create]
        name profile-name 
        description description-string 
        application 
            assurance 
                dns 
                    [no] reply-only
                icmp
                    [no] limit-type3
                    request limit packets
                ip
                    options {permit ip-option-mask | permit-any}
                    options ip-option-name [ip-option-name]
                tcp
                    [no] strict 
                exit
            exit
        exit
        timeouts
        exit
    exit
    policy {policy-id | policy-name} [create]
        description description-string 
        entry entry-id 
            match [protocol {protocol-id | name}]
                direction {zone-outbound | zone-inbound | both}
                src-ip ip-address to ip-address
            action reject
            logging to log-id {log-id | log-name}
            exit
        exit

The following example displays a rule-based logging configuration output.

*A:7705:Dut-C>config>security# info
----------------------------------------------
    logging
        profile 2 create
            event-control "policy" event "1" throttle
            event-control "policy" event "2" throttle
        exit
        profile 100 create
            event-control "policy" event "1" throttle
            event-control "policy" event "2" throttle
        exit
        log-id 10 create
            name "SecurityLog10"
            description "Security Log ID 10"
            destination memory 1024
            profile "100"
            no shutdown
        exit
        log-id 20 create
            name "SecurityLog20"
            description "Security Log ID 20"
            destination memory 1024
            no shutdown
        exit
        log-id 30 create
            name "SecurityLog30"
            description "Security Log ID 30"
            destination memory 1024
            no shutdown
        exit
        log-id 40 create
            name "SecurityLog40"
            description "Security Log ID 40"
            destination memory 1024
            profile "100"
            no shutdown
        exit
        log-id 50 create
            name "SecurityLog50"
            description "Security Log ID 50"
            destination memory 1024
            no shutdown
        exit
        log-id 100 create
            name "SecurityLog100"
            description "Security Log ID 100"
            destination memory 1024
            no shutdown
        exit
    exit
    begin
    profile 10 create
        name "StrictTCP"
        description "Strict TCP Enabled"
        application
            assurance
                ip
                exit
                icmp
                exit
                tcp
                    strict
                exit
                dns
                exit
            exit
        exit
        timeouts
        exit
    exit
    profile 20 create
        name "DNS"
        description "DNS_Reply_Strict"
        application
            assurance
                ip
                exit
                icmp
                exit
                tcp
                exit
                dns
                exit
            exit
        exit
        timeouts
        exit
    exit
    profile 30 create
        name "ICMP"
        description "ICMP Type3 Response Limit"
        application
            assurance
                ip
                exit
                icmp
                exit
                tcp
                exit
                dns
                exit
            exit
        exit
        timeouts
        exit
    exit
    policy 10 create
        description "Strict TCP"
        entry 10 create
            description "Entry 10"
            match protocol tcp
                direction zone-outbound
                src-ip 10.1.1.2
            exit
            limit
            exit
            action forward
            profile "StrictTCP"
            logging to log-id "SecurityLog10"
        exit
        entry 20 create
            description "TCP"
            match protocol tcp
                direction zone-outbound
            exit
            limit
            exit
            action forward
            logging to log-id "SecurityLog20"
        exit
        entry 30 create
            description "UDP and DNS"
            match protocol udp
                direction zone-outbound
            exit
            limit
            exit
            action forward
            profile "DNS"
            logging to log-id "SecurityLog30"
        exit
        entry 40 create
            description "ICMP"
            match protocol icmp
                direction zone-outbound
            exit
            limit
            exit
            action forward
            profile "ICMP"
            logging to log-id "SecurityLog40"
        exit
        entry 50 create
            description "SCTP Drop Rule"
            match protocol sctp
                direction zone-outbound
            exit
            limit
            exit
            action drop
            logging to log-id "SecurityLog50"
        exit
        entry 255 create
            description "Non Supported Protocol Rule"
            match
            exit
            limit
            exit
            logging to log-id "SecurityLog100"
        exit
    exit
----------------------------------------------
*A:7705:Dut-C>config>security#

The following example displays the error that occurs when there is an attempt to configure a log-id at both the policy level and the zone level.

*A:7705:Dut-C>config>service>vprn# info
----------------------------------------------
            route-distinguisher 65000:1
            vrf-target target:1:1
            interface "vprn-1-10.1.1.1" create
                address 192.168.0.0/16
                ip-mtu 1500
                spoke-sdp 1:10 create
                    no shutdown
                exit
            exit
            interface "vprn-1-10.1.1.1" create
                address 192.168.0.1/16
                ip-mtu 1500
                spoke-sdp 3:20 create
                    no shutdown
                exit
            exit
            zone 10 create
                description "Zone 10: "
                interface "vprn-1-10.1.1.1"
                exit
                nat
                exit
                policy "10"
                inbound
                    limit
                    exit
                exit
                outbound
                    limit
                    exit
                exit
                commit
            exit
            no shutdown
----------------------------------------------
*A:7705:Dut-C>config>service>vprn#   zone 10 log 100
MINOR: FIREWALL #1086 Policy level rule logging enabled. - Can not configure 
logids at both policy and zone levels

Zone-based logging is enabled when the config>security>policy>entry>logging to zone command is configured as part of the security policy configuration. Zone-based logging can be configured after the policy has been created, but this requires the begin and commit actions, which cause existing security sessions to be cleared.

Use the following CLI syntax to configure zone-based security logging:

CLI syntax:

config>security
    logging
        profile {profile-id | profile-name} [create]
            description description-string 
            event-control event-type [event event] {suppress | throttle | off}
            name name 
        log-id {log-id | log-name} [create] 
            description description-string 
            destination {memory [size] | syslog syslog-id}
            name name 
            profile {logging-profile-id | logging- profile-name} 
            no shutdown 
            exit
        exit
    profile {profile-id | profile-name} [create]
        description description-string 
        name name 
        application 
            assurance
                dns
                    reply-only
                tcp
                    strict
                    exit
                exit
            exit
        exit
    policy {policy-id | policy-name} [create]
        description description-string 
        entry entry-id 
            match [protocol {protocol-id | name}]
                direction {zone-outbound | zone-inbound | both}
                src-ip ip-address to ip-address
            action {drop | forward | nat | reject}
            logging to zone

The following example displays a zone-based logging configuration output.

*A:7705:Dut-C>config>security# info
----------------------------------------------
    logging
        profile 10 create
            event-control "packet" event "10" suppress
        exit
        log-id 10 create
            name "SecurityLog10"
            description "Security Log ID 10"
            destination memory 1024
            profile "10"
            no shutdown
        exit
        log-id 11 create
            destination memory 1024
            no shutdown
        exit
    exit
    profile 100 create
        name "StrictTCP"
        description "Strict TCP Enabled"
        application
            assurance
                ip
                exit
                icmp
                exit
                tcp
                    strict
                exit
                dns
                exit
            exit
        exit
        timeouts
        exit
    exit
    profile 101 create
        name "SessTimeout"
        description "timout"
        application
            assurance
                ip
                exit
                icmp
                exit
                tcp
                    strict
                exit
                dns
                exit
            exit
        exit
        timeouts
            other-sessions idle sec 40
        exit
    exit
    policy 10 create
        name "Mixed bag"
        description "Ingress Uni-directional"
        entry 1 create
            description "unknown"
            match protocol 48
                direction zone-outbound
            exit
            limit
            exit
            action forward
            logging to zone
        exit
        entry 2 create
            description "UDPLite"
            match protocol 136
                direction zone-outbound
            exit
            limit
            exit
            action forward
            logging to zone
        exit
        entry 3 create
            description "TCP"
            match protocol tcp
                direction zone-outbound
                src-port range 1024 15000
            exit
            limit
            exit
            action forward
            logging to zone
        exit
        entry 4 create
            description "Strict TCP"
            match protocol tcp
                direction zone-outbound
                src-port lt 1024
            exit
            limit
            exit
            action forward
            profile "StrictTCP"
            logging to zone
        exit
        entry 5 create
            description "GRE"
            match protocol gre
                direction zone-outbound
            exit
            limit
            exit
            action forward
            logging to zone
        exit
        entry 6 create
            description "UDP bad"
            match protocol udp
                direction zone-outbound
                src-port lt 1024
            exit
            limit
            exit
            logging to zone
        exit
        entry 7 create
            description "UDP good"
            match protocol udp
                direction zone-outbound
                src-port gt 1024
            exit
            limit
            exit
            action forward
            logging to zone
        exit
        entry 8 create
            description "UDP bad"
            match protocol udp
                direction zone-outbound
                src-port eq 1024
            exit
            limit
            exit
            action drop
            logging to zone
        exit
        entry 9 create
            description "IPv6 Encap"
            match protocol ipv6
                direction zone-outbound
            exit
            limit
            exit
            action forward
            logging to zone
        exit
    exit
    commit
----------------------------------------------
*A:7705:Dut-C>config>security#

The following example displays a zone-based logging configuration output for a VPRN service.

*A:7705:Dut-C>config>service>vprn# info
----------------------------------------------
            route-distinguisher 65000:1
            vrf-target target:1:1
            interface "vprn-1-10.1.1.1" create
                address 192.168.0.0/16
                ip-mtu 1500
                spoke-sdp 1:10 create
                    no shutdown
                exit
            exit
            interface "vprn-1-10.1.1.2" create
                address 192.168.0.1/16
                ip-mtu 1500
                spoke-sdp 3:20 create
                    no shutdown
                exit
            exit
            zone 10 create
                description "Zone 10: "
                interface "vprn-1-10.1.1.1"
                exit
                nat
                exit
                policy "Mixed bag"
                inbound
                    limit
                    exit
                exit
                outbound
                    limit
                    exit
                exit
                log "SecurityLog10"
                commit
            exit
            no shutdown
----------------------------------------------