Cisco IOS IPv6 Command Reference

ipv6 summary-address eigrp

To configure a summary aggregate address for a specified interface, use the ipv6 summary-address eigrp command in interface configuration mode. To disable a configuration, use the no form of this command.

ipv6 summary-address eigrp as-number ipv6-address [admin-distance]

no ipv6 summary-address eigrp as-number ipv6-address [admin-distance]

Syntax Description

Command Default

An administrative distance of 5 is applied to Enhanced Interior Gateway Routing Protocol (EIGRP) for IPv6 summary routes.
EIGRP for IPv6 automatically summarizes to the network level, even for a single host route.
No summary addresses are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipv6 summary-address eigrp command is used to configure interface-level address summarization. EIGRP for IPv6 summary routes are given an administrative distance value of 5. The administrative distance metric is used to advertise a summary address without installing it in the routing table.

Examples

The following example provides a summary aggregate address for EIGRP for IPv6 for AS 1:

ipv6 summary-address eigrp 1 2001:0DB8:0:1::/64

ipv6 tacacs source-interface

To specify an interface to use for the source address in TACACS packets, use the ipv6 tacacs source-interface command in global configuration mode. To remove the specified interface from the configuration, use the no form of this command.

ipv6 tacacs source-interface interface

no ipv6 tacacs source-interface interface

Syntax Description

Command Default

No interface is specified.

Command Modes

Global configuration (config)

Command History

Usage Guidelines

The ipv6 tacacs source-interface command specifies an interface to use for the source address in TACACS packets.

Examples

The following example shows how to configure the Gigabit Ethernet interface to be used as the source address in TACACS packets:

Router(config)# ipv6 tacacs source-interface GigabitEthernet 0/0/0

Related Commands

ipv6 traffic interface-statistics

To collect IPv6 forwarding statistics for all interfaces, use the ipv6 traffic interface-statistics command in global configuration mode. To ensure that IPv6 forwarding statistics are not collected for any interface, use the no form of this command.

ipv6 traffic interface-statistics [unclearable]

no ipv6 traffic interface-statistics [unclearable]

Syntax Description

Command Default

IPv6 forwarding statistics are collected for all interfaces.

Command Modes

Global configuration

Command History

Usage Guidelines

Using the optional unclearable keyword halves the per-interface statistics storage requirements.

Examples

The following example does not allow statistics to be cleared on any interface:

ipv6 traffic interface-statistics unclearable 

ipv6 traffic-filter

To filter incoming or outgoing IPv6 traffic on an interface, use the ipv6 traffic-filter command in interface configuration mode. To disable the filtering of IPv6 traffic on an interface, use the no form of this command.

ipv6 traffic-filter access-list-name {in | out}

no ipv6 traffic-filter access-list-name

Syntax Description

Command Default

Filtering of IPv6 traffic on an interface is not configured.

Command Modes

Interface configuration (config-if)
Policy-map configuration (config-pmap)

Command History

Examples

The following example filters inbound IPv6 traffic on Ethernet interface 0/0 as defined by the access list named cisco:

Router(config)# interface ethernet 0/0

Router(config-if)# ipv6 traffic-filter cisco in

Related Commands

ipv6 unicast-routing

To enable the forwarding of IPv6 unicast datagrams, use the ipv6 unicast-routing command in global configuration mode. To disable the forwarding of IPv6 unicast datagrams, use the no form of this command.

ipv6 unicast-routing

no ipv6 unicast-routing

Syntax Description

This command has no arguments or keywords.

Command Default

IPv6 unicast routing is disabled.

Command Modes

Global configuration

Command History

Usage Guidelines

Configuring the no ipv6 unicast-routing command removes all IPv6 routing protocol entries from the IPv6 routing table.

Examples

The following example enables the forwarding of IPv6 unicast datagrams:

Router(config)# ipv6 unicast-routing

Related Commands

ipv6 unnumbered

To enable IPv6 processing on an interface without assigning an explicit IPv6 address to the interface, use the ipv6 unnumbered command in interface configuration mode. To disable IPv6 on an unnumbered interface, use the no form of this command.

ipv6 unnumbered interface-type interface-number

no ipv6 unnumbered

Syntax Description

Command Default

This command is disabled.

Command Modes

Interface configuration

Command History

Usage Guidelines

IPv6 packets that are originated from an unnumbered interface use the global IPv6 address of the interface specified in the ipv6 unnumbered command as the source address for the packets. The ipv6 unnumbered interface command is used as a hint when doing source address selection; that is, when trying to determine the source address of an outgoing packet.

Note Serial interfaces using High-Level Data Link Control (HDLC), PPP, Link Access Procedure, Balanced (LAPB), Frame Relay encapsulations, and tunnel interfaces can be unnumbered. You cannot use this interface configuration command with X.25 or Switched Multimegabit Data Service (SMDS) interfaces.

Examples

The following example configures serial interface 0/1as unnumbered. IPv6 packets that are sent on serial interface 0/1 use the IPv6 address of Ethernet 0/0 as their source address:

Router(config)# interface ethernet 0/0

Router(config-if)# ipv6 address 3FFE:C00:0:1:260:3EFF:FE11:6770

Router(config)# interface serial 0/1

Router(config-if)# ipv6 unnumbered ethernet 0/0

Related Commands

ipv6 unreachables

To enable the generation of Internet Control Message Protocol for IPv6 (ICMPv6) unreachable messages for any packets arriving on a specified interface, use the ipv6 unreachables command in interface configuration mode. To prevent the generation of unreachable messages, use the no form of this command.

ipv6 unreachables

no ipv6 unreachables

Syntax Description

This command has no arguments or keywords.

Command Default

ICMPv6 unreachable messages can be generated for any packets arriving on that interface.

Command Modes

Interface configuration

Command History

Usage Guidelines

If the Cisco IOS software receives a nonbroadcast packet destined for itself that uses a protocol it does not recognize, it sends an ICMPv6 unreachable message to the source.

If the software receives a datagram that it cannot deliver to its ultimate destination because it knows of no route to the destination address, it replies to the originator of that datagram with an ICMP host unreachable message.

Examples

The following example enables the generation of ICMPv6 unreachable messages, as appropriate, on an interface:

interface ethernet 0

 ipv6 unreachables

ipv6 verify unicast reverse-path

To enable Unicast Reverse Path Forwarding (Unicast RPF) for IPv6, use the ipv6 verify unicast reverse-path command in interface configuration mode. To disable Unicast RPF, use the no form of this command.

ipv6 verify unicast reverse-path [access-list name]

no ipv6 verify unicast reverse-path [access-list name]

Syntax Description

Command Default

Unicast RPF is disabled.

Command Modes

Interface configuration (config-if)

Command History

Usage Guidelines

The ipv6 verify unicast reverse-path command is used to enable Unicast RPF for IPv6 in strict checking mode. The Unicast RPF for IPv6 feature requires that Cisco Express Forwarding for IPv6 is enabled on the router.

Note Beginning in Cisco IOS Release 12.0(31)S, the Cisco 12000 series Internet router supports both the ipv6 verify unicast reverse-path and ipv6 verify unicast source reachable-via rx commands to enable Unicast RPF to be compatible with the Cisco IOS Release 12.3T and 12.2S software trains.

Use the ipv6 verify unicast reverse-path command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that pass through a router. Malformed or forged source addresses can indicate denial-of-service (DoS) attacks based on source IP address spoofing.

When Unicast RPF is enabled on an interface, the router examines all packets received on that interface. The router checks to make sure that the source IPv6 address appears in the routing table and that it is reachable by a path through the interface on which the packet was received. Unicast RPF is an input feature and is applied only on the input interface of a router at the upstream end of a connection.

The Unicast RPF feature performs a reverse lookup in the CEF table to check if any packet received at a router interface has arrived on a path identified as a best return path to the source of the packet. If a reverse path for the packet is not found, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast RPF command. If an ACL is specified in the command, then when (and only when) a packet fails the Unicast RPF check, the ACL is checked to determine whether the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.

If no ACL is specified in the Unicast RPF command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.

Unicast RPF events can be logged by specifying the logging option for the ACL entries used by the Unicast RPF command. Log information can be used to gather information about the attack, such as source address, time, and so on.

Note When you configure Unicast RPF for IPv6 on the Cisco 12000 series Internet router, the most recently configured checking mode is not automatically applied to all interfaces as on other platforms. You must enable Unicast RPF for IPv6 separately on each interface. When you configure a SPA on the Cisco 12000 series Internet router, the interface address is in the format slot/subslot/port. The optional access-list keyword for the ipv6 verify unicast reverse-path command is not supported on the Cisco 12000 series Internet router. For information about how Unicast RPF can be used with ACLs on other platforms to mitigate the transmission of invalid IPv4 addresses (perform egress filtering) and to prevent (deny) the reception of invalid IPv4 addresses (perform ingress filtering), refer to the "Configuring Unicast Reverse Path Forwarding" chapter in the "Other Security Features" section of the Cisco IOS Security Configuration Guide.

Note When using Unicast RPF, all equal-cost "best" return paths are considered valid. This means that Unicast RPF works in cases where multiple return paths exist, provided that each path is equal to the others in terms of the routing cost (number of hops, weights, and so on).

Do not use Unicast RPF on core-facing interfaces that are internal to the network. Internal interfaces are likely to have routing asymmetry, meaning that there are multiple routes to the source of a packet. Apply Unicast RPF only where there is natural or configured symmetry.

For example, routers at the edge of the network of an Internet service provider (ISP) are more likely to have symmetrical reverse paths than routers that are in the core of the ISP network. Routers that are in the core of the ISP network have no guarantee that the best forwarding path out of the router will be the path selected for packets returning to the router. Hence, it is not recommended that you apply Unicast RPF where there is a chance of asymmetric routing. It is simplest to place Unicast RPF only at the edge of a network or, for an ISP, at the customer edge of the network.

Examples

Unicast Reverse Path Forwarding on a Serial Interface

The following example shows how to enable the Unicast RPF feature on a serial interface:

interface serial 5/0/0

  ipv6 verify unicast reverse-path

Unicast Reverse Path Forwarding on a Cisco 12000 Series Internet Router

The following example shows how to enable Unicast RPF for IPv6 with strict checking on a 10G SIP Gigabit Ethernet interface 2/1/2:

Router# configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)# interface gigabitEthernet 2/1/2

Router(config-if)# ipv6 verify unicast reverse-path

Router(config-if)# exit

Unicast Reverse Path Forwarding on a Single-Homed ISP

The following example uses a very simple single-homed ISP to demonstrate the concepts of ingress and egress filters used in conjunction with Unicast RPF. The example illustrates an ISP-allocated classless interdomain routing (CIDR) block 209.165.202.128/28 that has both inbound and outbound filters on the upstream interface. Be aware that ISPs are usually not single-homed. Hence, provisions for asymmetrical flows (when outbound traffic goes out one link and returns via a different link) need to be designed into the filters on the border routers of the ISP.

interface Serial 5/0/0 

description Connection to Upstream ISP 

ipv6 address FE80::260:3EFF:FE11:6770/64 

no ipv6 redirects

ipv6 verify unicast reverse-path abc 

! 

ipv6 access-list abc 

permit ipv6 host 2::1 any 

deny ipv6 FEC0::/10 any 

  ipv6 access-group abc in

  ipv6 access-group jkl out

!

access-list abc permit ip FE80::260:3EFF:FE11:6770/64 2001:0DB8:0000:0001::0001any

access-list abc deny ipv6 any any log 

access-list jkl deny ipv6 host 2001:0DB8:0000:0001::0001 any log

access-list jkl deny ipv6 2001:0DB8:0000:0001:FFFF:1234::5.255.255.255 any log

access-list jkl deny ipv6 2002:0EF8:002001:0DB8:0000:0001:FFFF:1234::5172.16.0.0 

0.15.255.255 any log

access-list jkl deny ipv6 2001:0CB8:0000:0001:FFFF:1234::5 0.0.255.255 any log

access-list jkl deny ipv6 2003:0DB8:0000:0001:FFFF:1234::5 0.0.0.31 any log

access-list jkl permit ipv6

ACL Logging with Unicast RPF

The following example demonstrates the use of ACLs and logging with Unicast RPF. In this example, extended ACL abc provides entries that deny or permit network traffic for specific address ranges. Unicast RPF is configured on interface Ethernet 0/0 to check packets arriving at that interface.

For example, packets with a source address of 8765:4321::1 arriving at Ethernet interface 0 are dropped because of the deny statement in ACL "abc." In this case, the ACL information is logged (the logging option is turned on for the ACL entry) and dropped packets are counted per-interface and globally. Packets with a source address of 1234:5678::1 arriving at Ethernet interface 0/0 are forwarded because of the permit statement in ACL abc. ACL information about dropped or suppressed packets is logged (the logging option is turned on for the ACL entry) to the log server.

interface ethernet 0/0

ipv6 address FE80::260:3EFF:FE11:6770/64 link-local

ipv6 verify unicast reverse-path abc

!

ipv6 access-list abc

permit ipv6 1234:5678::/64 any log-input

deny ipv6 8765:4321::/64 any log-input

Related Commands

ipv6 verify unicast source reachable-via

To verify that a source address exists in the FIB table and enable Unicast Reverse Path Forwarding (Unicast RPF), use the ipv6 verify unicast source reachable-via command in interface configuration mode. To disable URPF, use the no form of this command.

ipv6 verify unicast source reachable-via {rx | any} [allow-default] [allow-self-ping] [access-list-name]

no ipv6 verify unicast

Syntax Description

Command Default

Unicast RPF is disabled.

Command Modes

Interface configuration (config-if)

Command History

Usage Guidelines

The ipv6 verify unicast reverse-path command is used to enable Unicast RPF for IPv6 in loose checking mode.

Use the ipv6 verify unicast source reachable-via command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that pass through an IPv6 router. Malformed or forged source addresses can indicate denial-of-service (DoS) attacks based on source IPv6 address spoofing.

The URPF feature checks to see if any packet received at a router interface arrives on one of the best return paths to the source of the packet. The feature does this by doing a reverse lookup in the CEF table. If URPF does not find a reverse path for the packet, U RPF can drop or forward the packet, depending on whether an access control list (ACL) is specified in the ipv6 verify unicast source reachable-via command. If an ACL is specified in the command, then when (and only when) a packet fails the URPF check, the ACL is checked to see if the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for U RPF drops and in the interface statistics for Unicast RPF.

If no ACL is specified in the ipv6 verify unicast source reachable-via command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.

U RPF events can be logged by specifying the logging option for the ACL entries used by the ipv6 verify unicast source reachable-via command. Log information can be used to gather information about the attack, such as source address, time, and so on.

Examples

The following example enables Unicast RPF on any interface:

ipv6 verify unicast source reachable-via any

Related Commands

ipv6 virtual-reassembly

To enable Virtual Fragment Reassembly (VFR) on an interface, use the ipv6 virtual-reassembly command in global configuration mode. To remove VFR configuration, use the no form of this command.

ipv6 virtual-reassembly [in | out] [max-reassemblies maxreassemblies] [max-fragments max-fragments] [timeout seconds] [drop-fragments]

no ipv6 virtual-reassembly [in | out] [max-reassemblies maxreassemblies] [max-fragments max-fragments] [timeout seconds] [drop-fragments]

Syntax Description

Command Default

Max-reassemblies = 64
Fragments = 16
If neither the in or out keyword is specified, VFR is enabled on the ingress direction of the interface only.
drop-fragments keyword is not enabled.

Command Modes

Interface configuration (config-if)

Command History

Usage Guidelines

When the ipv6 virtual-reassembly command is configured on an interface without using one of the command keywords, VFR is enabled on the ingress direction of the interface only. In Cisco IOS XE Release 3.4S, all VFR-related alert messages are suppressed by default.

Maximum Number of Reassemblies

Whenever the maximum number of 256 reassemblies (fragment sets) is crossed, all the fragments in the forthcoming fragment set will be dropped and an alert message VFR-4-FRAG_TABLE_OVERFLOW will be logged to the syslog server.

Maximum Number of Fragments per Fragment Set

If a datagram being reassembled receives more than eight fragments then, tall fragments will be dropped and an alert message VFR-4-TOO_MANY_FRAGMENTS will be logged to the syslog server.

Explicit Removal of Egress Configuration

As of the Cisco IOS 15.1(1)T release, the no ipv6 virtual-reassembly command, when used without keywords, removes ingress configuration only. To remove egress interface configuration, you must enter the out keyword.

Examples

The following example configures the ingress direction on the interface. It sets the maximum number of reassemblies to 32, maximum fragments to 4, and the timeout to 7 seconds:

Router(config)# interface Ethernet 0/0 

Router(config-if)# ipv6 virtual-reassembly max-reassemblies 32 max-fragments 4 timeout 7

The following example enables the VFR on the ingress direction of the interface. Note that even if the in keyword is not used, the configuration default is to configure the ingress direction on the interface:

Router(config)# interface Ethernet 0/0

Router(config-if)# ipv6 virtual-reassembly

Router(config-if)# end 

Router# show run interface Ethernet 0/0

interface Ethernet0/0

no ip address

ipv6 virtual-reassembly in

The following example enables egress configuration on the interface. Note that the out keyword must be used to enable and disable egress configuration on the interface:

Router(config)# interface Ethernet 0/0

Router(config-if)# ipv6 virtual-reassembly out 

Router(config-if)# end

Router# show run interface Ethernet 0/0

interface Ethernet0/0

no ip address

ipv6 virtual-reassembly out

end

The following example disables egress configuration on the interface:

Router(config)# interface Ethernet 0/0

Router(config-if)# no ipv6 virtual-reassembly out 

Router(config-if)# end

ipv6 virtual-reassembly drop-fragments

To drop all fragments on an interface, use the ipv6 virtual-reassembly drop-fragments command in global configuration mode. Use the no form of this command to remove the packet-dropping behavior.

ipv6 virtual-reassembly drop-fragments

no ipv6 virtual-reassembly drop-fragments

Syntax Description

This command has no arguments or keywords.

Command Default

Fragments on an interface are not dropped.

Command Modes

Global configuration

Command History

Examples

The following example causes all fragments on an interface to be dropped:

ipv6 virtual-reassembly drop-fragments

isdn switch-type (BRI)

To specify the central office switch type on the ISDN interface, use the isdn switch-type command in global or interface configuration mode. To remove an ISDN switch type, use the no form of this command.

isdn switch-type switch-type

no isdn switch-type switch-type

Syntax Description

Defaults

No ISDN switch type is specified.

Command Modes

Global configuration or interface configuration

Note This command can be entered in either global configuration or interface configuration mode. When entered in global configuration mode, the basic-qsig switch type command specifies that the Cisco MC3810 use QSIG signaling on all BRI interfaces; when entered in interface configuration mode, the command specifies that an individual BRI voice interface use QSIG signaling. The interface configuration mode setting overrides the global configuration setting on individual interfaces.

Command History

Usage Guidelines

For the Cisco AS5300 access server, you have the choice of configuring the isdn-switch-type command to support Q.SIG in either global configuration mode or interface configuration mode. When entered in global configuration mode, the setting applies to the entire Cisco AS5300 access server. When entered in interface configuration mode, the setting applies only to the T1/E1 interface specified. The interface configuration mode setting overrides the global configuration setting.

For example, if you have a Q.SIG connection on one line as well as on the PRI port, you can configure the ISDN switch type in one of the following combinations:

•Set the global isdn-switch-type command to support Q.SIG and set the interface isdn-switch-type command for interface serial 0:23 to a PRI setting such as 5ess.

•Set the global isdn-switch-type command to support PRI 5ess and set the interface isdn-switch-type command for interface serial 1:23 to support Q.SIG.

•Configure the global isdn-switch-type command to another setting (such as switch type VN3), set the interface isdn-switch-type command for interface serial 0:23 to a PRI setting, and set the interface isdn-switch-type command for interface serial 1:23 to support Q.SIG.

For the Cisco MC3810 router, if you are using different Cisco MC3810 BRI port interfaces with different ISDN switch types, you can use global and interface commands in any combination, as long as you remember that interface commands always override a global command.

For example, if you have a BRI QSIG switch interface on BRI voice ports 1, 2, 3 and 4, but a BRI 5ess switch interface on BRI backup port 0, you can configure the ISDN switch types in any of the following combinations:

•Enter the isdn switch-type basic-qsig global configuration command, and enter the
isdn switch-type bri-5ess command on interface 0.

•Enter the isdn switch-type bri-5ess global configuration command, and enter the
isdn switch-type basic-qsig command on interfaces 1, 2, 3, and 4 individually.

•Enter the isdn switch-type bri-5ess command on interface 0, and enter the isdn switch-type basic-qsig command on interfaces 1, 2, 3, and 4 individually.

If you use the no isdn switch-type global configuration command, any switch type that was originally entered in global configuration mode is canceled; however, any switch type originally entered on an interface is not affected. If you use the no isdn switch-type interface configuration command, any switch type configuration on the interface is canceled.

Note In the Cisco MC3810, ISDN BRI voice ports support only switch type basic-qsig; ISDN BRI backup ports support all other listed switch types, but not basic-qsig.

Note The dial-peer codec command must be configured before any calls can be placed over the connection to the PINX. The default codec type is G729a.

If you are using the Multiple ISDN Switch Types feature to apply ISDN switch types to different interfaces, refer to the chapters "Configuring ISDN BRI" and "Configuring ISDN PRI" in the Cisco IOS Dial Technologies Configuration Guide for additional details.

The Cisco IOS command parser accepts the following switch types: basic-nwnet3, vn2, and basic-net3; however, when viewing the NVRAM configuration, the basic-net3 or vn3 switch types are displayed, respectively.

To remove an ISDN switch type from an ISDN interface, specify the no isdn switch-type switch-type command.

Table 33 lists supported BRI switch types by geographic area.

Examples

The following example configures the French VN3 ISDN switch type:

isdn switch-type vn3

The following example uses the Multiple ISDN Switch Types feature and shows use of the global ISDN switch type basic-ni keyword (formerly basic-ni1) and the basic-net3 interface-level switch type keyword. ISDN switch type basic-net3 is applied to BRI interface 0 and overrides the global switch setting.

isdn switch-type basic-ni 
! 
interface BRI0 
 isdn switch-type basic-net3

The following example configures the Cisco MC3810 router to use BRI QSIG signaling for all of its BRI voice ports:

isdn switch-type basic-qsig 

The following example configures the Cisco MC3810 to use BRI QSIG signaling for BRI voice
port 1. On port 1, this setting overrides any different signaling set in the previous example.

interface bri 1

 isdn switch-type basic-qsig

isis ipv6 metric

To configure the value of an Intermediate System-to-Intermediate System (IS-IS) IPv6 metric, use the isis ipv6 metric command in interface configuration mode. To return the metric to its default value, use the no form of this command.

isis ipv6 metric {metric-value | maximum} [level-1 | level-2]

no isis ipv6 metric {metric-value | maximum} [level-1 | level-2]

Syntax Description

Command Default

The default metric value is set to 10.

Command Modes

Interface configuration

Command History

Usage Guidelines

The isis ipv6 metric command is used only in multitopology IS-IS.

Changing the metric allows differentiation between IPv4 and IPv6 traffic, forcing traffic onto different interfaces. This function allows you to use the lower-cost rather than the high-cost interface.

For using extended metrics, such as with the IS-IS multitopology for IPv6 feature, Cisco IOS software provides support of a 24-bit metric field, the so-called "wide metric." Using the new metric style, link metrics now have a maximum value of 16777214 with a total path metric of 4261412864.

Cisco IOS Release 12.4(13) and 12.4(13)T

Entering the maximum keyword will exclude the link from the SPF calculation. If a link is advertised with the maximum link metric, the link will not be considered during the normal SPF computation. When the link excluded from the SPF, it will not be advertised for calculating the normal SPF. An example would be a link that is available for traffic engineering, but not for hop-by-hop routing. If a link, such as one that is used for traffic engineering, should not be included in the SPF calculation, enter the isis ipv6 metric command with the maximum keyword.

Note The isis ipv6 metric maximum command applies only when the metric-style wide command has been entered. The metric-style wide command is used to configure IS-IS to use the new-style type, length, value (TLV) because TLVs that are used to advertise IPv6 information in link-state packets (LSPs) are defined to use only extended metrics.

Examples

The following example sets the value of an IS-IS IPv6 metric to 20:

Router(config)# interface Ethernet 0/0/1

Router(config-if)# isis ipv6 metric 20

The following example sets the IS-IS IPv6 metric for the link to maximum. SPF will ignore the link for both Level 1 and Level 2 routing because neither the level-1 keyword nor the level-2 keyword was entered.

Router(config)# interface fastethernet 0/0

Router(config-if)# isis ipv6 metric maximum

Related Commands

keepalive target

To identify Session Initiation Protocol (SIP) servers that will receive keepalive packets from the SIP gateway, use the keepalive target command in SIP user-agent configuration mode. To disable the keepalive target command behavior, use the no form of this command.

keepalive target {{ipv4:address | ipv6:address}[:port] | dns:hostname} | [tcp [tls]] | [udp] | [secondary]

no keepalive target [secondary]

Syntax Description

Command Default

No keepalives are sent by default from SIP gateway to SIP gateway. The SIP port number is 5060 by default.

Command Modes

SIP user-agent configuration (config-sip-ua)

Command History

Usage Guidelines

The primary or secondary SIP server addresses are in the following forms: dns:example.sip.com or ipv4:172.16.0.10.

Examples

The following example sets the primary SIP server address and defaults to the UDP transport:

sip-ua

 keepalive target ipv4:172.16.0.10

The following example sets the primary SIP server address and the transport to UDP:

sip-ua

 keepalive target ipv4:172.16.0.10 udp

The following example sets both the primary and secondary SIP server address and the transport to UDP:

sip-ua

 keepalive target ipv4:172.16.0.10 udp

 keepalive target ipv4:172.16.0.20 udp secondary

The following example sets both the primary and secondary SIP server addresses and defaults to the UDP transport:

sip-ua

 keepalive target ipv4:172.16.0.10

 keepalive target ipv4:172.16.0.20 secondary

The following example sets the primary SIP server address and the transport to TCP:

sip-ua

 keepalive target ipv4:172.16.0.10 tcp

The following example sets both the primary and secondary SIP server addresses and the transport to TCP:

sip-ua

 keepalive target ipv4:172.16.0.10 tcp

 keepalive target ipv4:172.16.0.20 tcp secondary

The following example sets the primary SIP server address and the transport to TCP and sets security to TLS mode:

sip-ua

 keepalive target ipv4:172.16.0.10 tcp tls

The following example sets both the primary and secondary SIP server addresses and the transport to TCP and sets security to the TLS mode:

sip-ua

 keepalive target ipv4:172.16.0.10 tcp tls

 keepalive target ipv4:172.16.0.20 tcp tls secondary

Related Commands

key

To identify an authentication key on a key chain, use the key command in key-chain configuration mode. To remove the key from the key chain, use the no form of this command.

key key-id

no key key-id

Syntax Description

Command Default

No key exists on the key chain.

Command Modes

Key-chain configuration (config-keychain)

Command History

Usage Guidelines

Only DRP Agent, Enhanced Interior Gateway Routing Protocol (EIGRP), and Routing Information Protocol (RIP) Version 2 use key chains.

It is useful to have multiple keys on a key chain so that the software can sequence through the keys as they become invalid after time, based on the accept-lifetime and send-lifetime key chain key command settings.

Each key has its own key identifier, which is stored locally. The combination of the key identifier and the interface associated with the message uniquely identifies the authentication algorithm and Message Digest 5 (MD5) authentication key in use. Only one authentication packet is sent, regardless of the number of valid keys. The software starts looking at the lowest key identifier number and uses the first valid key.

If the last key expires, authentication will continue and an error message will be generated. To disable authentication, you must manually delete the last valid key.

To remove all keys, remove the key chain by using the no key chain command.

Examples

The following example configures a key chain named chain1. The key named key1 will be accepted from 1:30 p.m. to 3:30 p.m. and be sent from 2:00 p.m. to 3:00 p.m. The key named key2 will be accepted from 2:30 p.m. to 4:30 p.m. and be sent from 3:00 p.m. to 4:00 p.m. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# interface ethernet 0

Router(config-if)# ip rip authentication key-chain chain1

Router(config-if)# ip rip authentication mode md5

!

Router(config)# router rip

Router(config-router)# network 172.19.0.0

Router(config-router)# version 2

!

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string key1

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string key2

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

The following named configuration example configures a key chain named chain1 for EIGRP address-family. The key named key1 will be accepted from 1:30 p.m. to 3:30 p.m. and be sent from 2:00 p.m. to 3:00 p.m. The key named key2 will be accepted from 2:30 p.m. to 4:30 p.m. and be sent from 3:00 p.m. to 4:00 p.m. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# router eigrp virtual-name

Router(config-router)# address-family ipv4 autonomous-system 4453

Router(config-router-af)# network 10.0.0.0

Router(config-router-af)# af-interface ethernet0/0

Router(config-router-af-interface)# authentication key-chain trees

Router(config-router-af-interface)# authentication mode md5

Router(config-router-af-interface)# exit

Router(config-router-af)# exit

Router(config-router)# exit

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string key1

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string key2

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

The following named configuration example configures a key chain named chain1 for EIGRP service-family. The key named key1 will be accepted from 1:30 p.m. to 3:30 p.m. and be sent from 2:00 p.m. to 3:00 p.m. The key named key2 will be accepted from 2:30 p.m. to 4:30 p.m. and be sent from 3:00 p.m. to 4:00 p.m. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# eigrp virtual-name

Router(config-router)# service-family ipv4 autonomous-system 4453

Router(config-router-sf)# network 10.0.0.0

Router(config-router-sf)# sf-interface ethernet0/0

Router(config-router-sf-interface)# authentication key-chain trees

Router(config-router-sf-interface)# authentication mode md5

Router(config-router-sf-interface)# exit

Router(config-router-sf)# exit

Router(config-router)# exit

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string key1

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string key2

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

Related Commands

key (TACACS+)

To configure the per-server encryption key on the TACACS+ server, use the key command in TACACS+ server configuration mode. To remove the per-server encryption key, use the no form of this command.

key [0 | 7] key-string

no key [0 | 7] key-string

Syntax Description

Command Default

No TACACS+ encryption key is configured.

Command Modes

TACACS+ server configuration (config-server-tacacs)

Command History

Usage Guidelines

The key command allows you to configure a per-server encryption key.

Examples

The following example shows how to specify an unencrypted shared key named key1:

Router (config)# tacacs server server1

Router(config-server-tacacs)# key 0 key1

Related Commands

key chain

To define an authentication key chain needed to enable authentication for routing protocols and enter key-chain configuration mode, use the key chain command in global configuration mode. To remove the key chain, use the no form of this command.

key chain name-of-chain

no key chain name-of-chain

Syntax Description

Command Default

No key chain exists.

Command Modes

Global configuration (config)

Command History

Usage Guidelines

Only DRP Agent, Enhanced Interior Gateway Routing Protocol (EIGRP), and Routing Information Protocol (RIP) Version 2 use key chains.

You must configure a key chain with keys to enable authentication.

Although you can identify multiple key chains, we recommend using one key chain per interface per routing protocol. Upon specifying the key chain command, you enter key chain configuration mode.

Examples

The following example configures a key chain named chain1. The key named key1 will be accepted from 1:30 p.m. to 3:30 p.m. and be sent from 2:00 p.m. to 3:00 p.m. The key named key2 will be accepted from 2:30 p.m. to 4:30 p.m. and be sent from 3:00 p.m. to 4:00 p.m. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# interface ethernet 0

Router(config-if)# ip rip authentication key-chain chain1

Router(config-if)# ip rip authentication mode md5

!

Router(config)# router rip

Router(config-router)# network 172.19.0.0

Router(config-router)# version 2

!

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string key1

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string key2

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

The following named configuration example configures a key chain named chain1 for EIGRP address-family. The key named key1 will be accepted from 1:30 p.m. to 3:30 p.m. and be sent from 2:00 p.m. to 3:00 p.m. The key named key2 will be accepted from 2:30 p.m. to 4:30 p.m. and be sent from 3:00 p.m. to 4:00 p.m. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# router eigrp virtual-name

Router(config-router)# address-family ipv4 autonomous-system 4453

Router(config-router-af)# network 10.0.0.0

Router(config-router-af)# af-interface ethernet0/0

Router(config-router-af-interface)# authentication key-chain trees

Router(config-router-af-interface)# authentication mode md5

Router(config-router-af-interface)# exit

Router(config-router-af)# exit

Router(config-router)# exit

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string key1

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string key2

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

The following named configuration example configures a key chain named trees for service-family. The key named chestnut will be accepted from 1:30 pm to 3:30 pm and be sent from 2:00 pm to 3:00 pm. The key birch will be accepted from 2:30 pm to 4:30 pm and be sent from 3:00 pm to 4:00 pm. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# router eigrp virtual-name

Router(config-router)# service-family ipv4 autonomous-system 4453

Router(config-router-sf)# sf-interface ethernet

Router(config-router-sf-interface)# authentication key chain trees

Router(config-router-sf-interface)# authentication mode md5

Router(config-router-sf-interface)# exit

Router(config-router-sf)# exit

Router(config-router)# exit

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string chestnut

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string birch

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

Related Commands

key-string (authentication)

To specify the authentication string for a key, use the key-string (authentication) command in key chain key configuration mode. To remove the authentication string, use the no form of this command.

key-string text

no key-string text

Syntax Description

Command Default

No authentication string for a key exists.

Command Modes

Key chain key configuration (config-keychain-key)

Command History

Usage Guidelines

Only DRP Agent, Enhanced Interior Gateway Routing Protocol (EIGRP), and Routing Information Protocol (RIP) Version 2 use key chains. Each key can have only one key string.

If password encryption is configured (with the service password-encryption command), the software saves the key string as encrypted text. When you write to the terminal with the more system:running-config command, the software displays key-string 7 encrypted text.

Examples

The following example configures a key chain named chain1. The key named key1 will be accepted from 1:30 p.m. to 3:30 p.m. and be sent from 2:00 p.m. to 3:00 p.m. The key named key2 will be accepted from 2:30 p.m. to 4:30 p.m. and be sent from 3:00 p.m. to 4:00 p.m. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# interface ethernet 0

Router(config-if)# ip rip authentication key-chain chain1

Router(config-if)# ip rip authentication mode md5

!

Router(config)# router rip

Router(config-router)# network 172.19.0.0

Router(config-router)# version 2

!

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string key1

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string key2

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

The following example configures a key chain named chain1 for EIGRP address-family. The key named key1 will be accepted from 1:30 p.m. to 3:30 p.m. and be sent from 2:00 p.m. to 3:00 p.m. The key named key2 will be accepted from 2:30 p.m. to 4:30 p.m. and be sent from 3:00 p.m. to 4:00 p.m. The overlap allows for migration of keys or a discrepancy in the set time of the router. There is a 30-minute leeway on each side to handle time differences.

Router(config)# eigrp virtual-name

Router(config-router)# address-family ipv4 autonomous-system 4453

Router(config-router-af)# network 10.0.0.0

Router(config-router-af)# af-interface ethernet0/0

Router(config-router-af-interface)# authentication key-chain trees

Router(config-router-af-interface)# authentication mode md5

Router(config-router-af-interface)# exit

Router(config-router-af)# exit

Router(config-router)# exit

Router(config)# key chain chain1

Router(config-keychain)# key 1

Router(config-keychain-key)# key-string key1

Router(config-keychain-key)# accept-lifetime 13:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 14:00:00 Jan 25 1996 duration 3600

Router(config-keychain-key)# exit

Router(config-keychain)# key 2

Router(config-keychain-key)# key-string key2

Router(config-keychain-key)# accept-lifetime 14:30:00 Jan 25 1996 duration 7200

Router(config-keychain-key)# send-lifetime 15:00:00 Jan 25 1996 duration 3600

Related Commands

lifetime (IKE policy)

To specify the lifetime of an Internet Key Exchange (IKE) security association (SA), use the lifetime command in Internet Security Association Key Management Protocol (ISAKMP) policy configuration mode. To reset the SA lifetime to the default value, use the no form of this command.

lifetime seconds

no lifetime

Syntax Description

Command Default

The default is 86,400 seconds (one day).

Command Modes

ISAKMP policy configuration

Command History

Usage Guidelines

Use this command to specify how long an IKE SA exists before expiring.

When IKE begins negotiations, the first thing it does is agree upon the security parameters for its own session. The agreed-upon parameters are then referenced by an SA at each peer. The SA is retained by each peer until the SA's lifetime expires. Before an SA expires, it can be reused by subsequent IKE negotiations, which can save time when setting up new IPSec SAs. Before an SA expires, it can be reused by subsequent IKE negotiations, which can save time when setting up new IPSec SAs. New IPSec SAs are negotiated before current IPSec SAs expire.

So, to save setup time for IPSec, configure a longer IKE SA lifetime. However, shorter lifetimes limit the exposure to attackers of this SA. The longer an SA is used, the more encrypted traffic can be gathered by an attacker and possibly used in an attack.

Note that when your local peer initiates an IKE negotiation between itself and a remote peer, an IKE policy can be selected only if the lifetime of the remote peer's policy is shorter than or equal to the lifetime of the local peer's policy. Then, if the lifetimes are not equal, the shorter lifetime will be selected. To restate this behavior: If the two peer's policies' lifetimes are not the same, the initiating peer's lifetime must be longer and the responding peer's lifetime must be shorter, and the shorter lifetime will be used.

Examples

The following example configures an IKE policy with a security association lifetime of 600 seconds (10 minutes), and all other parameters are set to the defaults:

crypto isakmp policy 15

 lifetime 600

 exit

Related Commands

limit address-count

To limit the number of IPv6 addresses allowed to be used on the port, use the limit address-count command in Neighbor Discovery Protocol (NDP) inspection policy configuration mode.

limit address-count maximum

Syntax Description

Command Default

The device role is host.

Command Modes

ND inspection policy configuration (config-nd-inspection)
RA guard policy configuration (config-ra-guard)

Command History

Usage Guidelines

The limit address-count command limits the number of IPv6 addresses allowed to be used on the port on which the policy is applied. Limiting the number of IPv6 addresses on a port helps limit the binding table size.

Use the limit address-count command after enabling NDP inspection policy configuration mode using the ipv6 nd inspection policy command.

Examples

The following example defines an NDP policy name as policy1, places the router in NDP inspection policy configuration mode, and limits the number of IPv6 addresses allowed on the port to 25:

Router(config)# ipv6 nd inspection policy policy1

Router(config-nd-inspection)# limit address-count 25

Related Commands

log-adjacency-changes

To configure the router to send a syslog message when an Open Shortest Path First (OSPF) neighbor goes up or down, use the log-adjacency-changes command in router configuration mode. To turn off this function, use the no form of this command.

log-adjacency-changes [detail]

no log-adjacency-changes [detail]

Syntax Description

Command Default

Enabled

Command Modes

Router configuration (config-router)

Command History

Usage Guidelines

This command allows you to know about OSPF neighbors going up or down without turning on the debug ip ospf packet command or the debug ipv6 ospf adjacency command. The log-adjacency-changes command provides a higher level view of those changes of the peer relationship with less output than the debug command provides. The log-adjacency-changes command is on by default but only up/down (full/down) events are reported, unless the detail keyword is also used.

Examples

The following example configures the router to send a syslog message when an OSPF neighbor state changes:

log-adjacency-changes detail

Related Commands

log-adjacency-changes (OSPFv3)

To configure the router to send a syslog message when an Open Shortest Path First version 3 (OSPFv3) neighbor goes up or down, use the log-adjacency-changes command in router configuration mode. To turn off this function, use the no form of this command.

log-adjacency-changes [detail]

no log-adjacency-changes [detail]

Syntax Description

Command Default

This feature is enabled

Command Modes

OSPFv3 router configuration mode (config-router)

Command History

Usage Guidelines

Use the log-adjacency changes command to notify you when OSPFv3 neighbors go up or down. The log-adjacency-changes command provides a higher level view of those changes of the peer relationship with less output than debug commands provide. The log-adjacency-changes command is on by default, but only up/down (full/down) events are reported unless the detail keyword is also used.

Examples

The following example configures the router to send a syslog message when an OSPFv3 neighbor state changes:

Router(config-router)# log-adjacency-changes

Related Commands

logging event link-status (interface configuration)

To enable link-status event messaging on an interface, use the logging event link-status command in interface configuration mode. To disable link-status event messaging, use the no form of this command.

logging event link-status [bchan | dchan | nfas]

no logging event link-status [bchan | dchan | nfas]

Syntax Description

Command Default

Interface state-change messages are not sent.

Command Modes

Interface configuration (config-if)

Command History

Usage Guidelines

To enable system logging of interface state-change events on a specific interface, enter the logging event link-status command.

Examples

The following example shows how to enable link-status event messaging on an interface:

Router(config-if)# logging event link-status

This example shows how to disable link-status event messaging on an interface:

Router(config-if)# no logging event link-status 

logging host

To log system messages and debug output to a remote host, use the logging host command in global configuration mode. To remove a specified logging host from the configuration, use the no form of this command.

logging host {{ip-address | hostname} [vrf vrf-name] | ipv6 {ipv6-address | hostname}} [discriminator discr-name | [[filtered [stream stream-id] | xml]] [transport {[beep [audit] [channel chnl-number] [sasl profile-name] [tls cipher [cipher-num] trustpoint trustpt-name]]] | tcp [audit] | udp} [port port-num]] [sequence-num-session] [session-id {hostname | ipv4 | ipv6 | string custom-string}]

no logging host {{ip-address | hostname} | ipv6 {ipv6-address | hostname}}

Syntax Description

Command Default

System logging messages are not sent to any remote host.
When this command is entered without the xml or filtered keyword, messages are sent in the standard format.

Command Modes

Global configuration (config)

Command History

Usage Guidelines

Standard system logging is enabled by default. If logging is disabled on your system (using the no logging on command), you must enter the logging on command to reenable logging before you can use the logging host command.

The logging host command identifies a remote host (usually a device serving as a syslog server) to receive logging messages. By issuing this command more than once, you can build a list of hosts that receive logging messages.

To specify the severity level for logging to all hosts, use the logging trap command.

Use the vrf vrf-name keyword and argument to enable a syslog client (a provider edge [PE] router) to send syslog messages to a syslog server host connected through a VRF interface. To delete the configuration of the syslog server host from the VRF, use the no logging host command with the vrf vrf-name keyword and argument.

When XML-formatted syslog is enabled using the logging host command with the xml keyword, messages are sent to the specified host with the system-defined XML tags. These tags are predefined and cannot be configured by a user. XML formatting is not applied to debug output.

If you are using the ESM feature, you can enable ESM-filtered syslog messages to be sent to one or more hosts using the logging host filtered command. To use the ESM feature, you must first specify the syslog filter modules that should be applied to the messages using the logging filter command. See the description of the logging filter command for more information about the ESM feature.

Note ESM and message discriminator usage are mutually exclusive on a given syslog session.

Using the BEEP transport protocol, you can have reliable and secure delivery for syslog messages and configure multiple sessions over eight BEEP channels. The sasl profile-name, tls cipher cipher-num, trustpoint trustpt-name keywords and arguments are available only in crypto images.

To configure standard logging to a specific host after configuring XML-formatted or ESM-filtered logging to that host, use the logging host command without the xml or filtered keyword. Issuing the standard logging host command replaces an XML- or ESM- filtered logging host command, and vice versa, if the same host is specified.

You can configure the system to send standard messages to one or more hosts, XML-formatted messages to one or more hosts, and ESM-filtered messages to one or more hosts by repeating this command as many times as desired with the appropriate syntax. (See the "Examples" section.)

When the no logging host command is issued with or without the optional keywords, all logging to the specified host is disabled.

Examples

In the following example, messages at severity levels 0 (emergencies) through 5 (notifications) (logging trap command severity levels) are logged to a host at 192.168.202.169:

Router(config)# logging host 192.168.202.169 

Router(config)# logging trap 5 

In the following example, standard system logging messages are sent to the host at 192.168.200.225, XML-formatted system logging messages are sent to the host at 192.168.200.226, ESM-filtered logging messages with the stream 10 value are sent to the host at 192.168.200.227, and ESM-filtered logging messages with the stream 20 value are sent to host at 192.168.202.129:

Router(config)# logging host 192.168.200.225 

Router(config)# logging host 192.168.200.226 xml 

Router(config)# logging host 192.168.200.227 filtered stream 10 

Router(config)# logging host 192.168.202.129 filtered stream 20 

In the following example, messages are logged to a host with an IP address of 172.16.150.63 connected through a VRF named vpn1:

Router(config)# logging host 172.16.150.63 vrf vpn1

In the following example, the default UDP on an IPv6 server is set because no port number is specified. The default port number of 514 is used:

Router(config)# logging host ipv6 AAAA:BBBB:CCCC:DDDD::FFFF 

In the following example, TCP port 1774 on an IPv6 server is set:

Router(config)# logging host ipv6 BBBB:CCCC:DDDD:FFFF::1234 transport tcp port 1774

In the following example, the UDP port default is used on an IPv6 server with a hostname of v6-hostname:

Router(config)# logging host ipv6 v6-hostname transport udp port 514

In the following example, a message discriminator named fltr1 is specified as well as the BEEP protocol for port 600 and channel 3.

Router(config)# logging host host2 dicriminator fltr1 transport beep channel 3 port 600 

Related Commands

logging origin-id

To add an origin identifier to system logging messages sent to remote hosts, use the logging origin-id command in global configuration mode. To disable the origin identifier, use the no form of this command.

logging origin-id {hostname | ip | ipv6 | string user-defined-id}

no logging origin-id

Syntax Description

Command Default

This command is disabled.

Command Modes

Global configuration (config)

Command History

Usage Guidelines

The origin identifier is added to the beginning of all system logging (syslog) messages sent to remote hosts. The identifier can be the hostname, the IP address, the IPv6 address, or any text that you specify. The origin identifier is not added to messages sent to local destinations (the console, monitor, or buffer).

The origin identifier is useful for identifying the source of system logging messages in cases where you send syslog output from multiple devices to a single syslog host.

When you specify your own identification string using the logging origin-id string user-defined-id command, the system expects a string without spaces. For example:

Router(config)# logging origin-id string Cisco_Systems 

To use spaces (multiple words) or additional syntax, enclose the string with quotation marks (" "). For example:

Router(config)# logging origin-id string "Cisco Systems, Inc." 

Examples

In the following example, the origin identifier "Domain 1, router B" will be added to the beginning of all system logging messages sent to remote hosts:

Router(config)# logging origin-id string Domain 1, router B

In the following example, all logging messages sent to remote hosts will have the IP address configured for serial interface 1 added to the beginning of the message:

Router(config)# logging host 209.165.200.225 

Router(config)# logging trap 5 

Router(config)# logging source-interface serial 1 

Router(config)# logging origin-id ip 

Related Commands

logging source-interface

To specify the source IPv4 or IPv6 address of system logging packets, use the logging source-interface command in global configuration mode. To remove the source designation, use the no form of this command.

logging source-interface type number vrf vrf_name

no logging source-interface

Syntax Description

Command Default

The wildcard interface address is used.

Command Modes

Global configuration (config)

Command History

Usage Guidelines

This command can be configured on the Virtual Routing and Forwarding (VRF) and non-VRF interfaces. Normally, a syslog message contains the IPv4 or IPv6 address of the interface used to exit the router. The logging source-interface command configures the syslog packets that contain the IPv4 or IPv6 address of a particular interface, regardless of which interface the packet uses to exit the router.

When no specific interface is configured, a wildcard interface address of 0.0.0.0 (for IPv4) or :: (for IPv6) is used, and the IP socket selects the best outbound interface.

If you configure the same VRF interface multiple times the newest configuration will override earlier configurations.

The maximum allowable source-interfaces commands is 200 since there can be only a maximum of 200 hosts.

Examples

The following example shows how to specify that the IP address of Ethernet interface 0 is the source IP address for all syslog messages:

Router(config)# logging source-interface ethernet 0 

The following example shows how to specify the IP address for Ethernet interface 2/1 is the source IP address for all syslog messages:

Router(config)# logging source-interface ethernet 2/1 

The following sample output displays that the logging source-interface command is configured on a VRF source interface:

Router# show running interface loopback49

             Building configuration...

             Current configuration : 84 bytes

             !

             interface Loopback49

              ip vrf forwarding black

              ip address 49.0.0.1 255.0.0.0

             end

Router# show running | includes logging

      logging source-interface Loopback49 vrf black

      logging host 130.0.0.1 vrf black

Related Commands

log-neighbor-changes (IPv6 EIGRP)

To enable the logging of changes in Enhanced Interior Gateway Routing Protocol (EIGRP) IPv6 neighbor adjacencies, use the log-neighbor-changes command in router configuration mode. To disable the logging of changes in EIGRP IPv6 neighbor adjacencies, use the no form of this command.

log-neighbor-changes

no log-neighbor-changes

Syntax Description

This command has no arguments or keywords.

Command Default

Adjacency changes are logged.

Command Modes

Router configuration

Command History

Usage Guidelines

The log-neighbor-changes command enables the logging of neighbor adjacency changes to monitor the stability of the routing system and to help detect problems.

Logging is enabled by default. To disable the logging of neighbor adjacency changes, use the no form of this command.

Examples

The following example disables logging of neighbor changes for EIGRP process 1:

ipv6 router eigrp 1

 no log-neighbor-changes

The following configuration enables logging of neighbor changes for EIGRP process 1:

ipv6 router eigrp 1

 log-neighbor-changes

Related Commands

log-neighbor-warnings

Note Effective with Cisco IOS Release 15.0(1)M, 12.2(33)SRE and Cisco IOS XE Release 2.5, the log-neighbor-warnings command was replaced by the eigrp log-neighbor-warnings command for IPv4 and IPv6 configurations. The log-neighbor-warnings command is still available for IPX configurations.

To enable the logging of Enhanced Interior Gateway Routing Protocol (EIGRP) neighbor warning messages, use the log-neighbor-warnings command in router configuration mode. To disable the logging of EIGRP neighbor warning messages, use the no form of this command.

log-neighbor-warnings [seconds]

no log-neighbor-warnings

Syntax Description

Command Default

Neighbor warning messages are logged.

Command Modes

Router configuration (config-router)

Command History

Usage Guidelines

When neighbor warning messages occur, they are logged by default. With the log-neighbor-warnings command, you can disable and enable the logging of neighbor warning messages and configure the interval between repeated neighbor warning messages.

Examples

The following example shows that neighbor warning messages will be logged for EIGRP process 1 and warning messages will be repeated in 5-minute (300 seconds) intervals:

Router(config)# ipv6 router eigrp 1

Router(config-router)# log-neighbor-warnings 300

Related Commands

managed-config-flag

To verify the advertised managed address configuration parameter, use the managed-config-flag command in router advertisement (RA) guard policy configuration mode.

managed-config-flag {on | off}

Syntax Description

Command Default

Verification is not enabled.

Command Modes

RA guard policy configuration (config-ra-guard)

Command History

Usage Guidelines

The managed-config-flag command enables verification of the advertised managed address configuration parameter (or "M" flag). This flag could be set by an attacker to force hosts to obtain addresses through a potentially untrusted DHCPv6 server.

Examples

The following example defines an RA guard policy name as raguard1, places the router in RA guard policy configuration mode, and enables M flag verification:

Router(config)# ipv6 nd raguard policy raguard1

Router(config-ra-guard)# managed-config-flag on

Related Commands

mask

To specify the destination or source mask, use the mask command in aggregation cache configuration mode. To disable the destination mask, use the no form of this command.

mask {destination | source} minimum value

no mask destination minimum value

Syntax Description

Command Default

The default value of the minimum mask is zero.

Command Modes

Aggregation cache configuration

Command History

Usage Guidelines

This command is only available with router-based aggregation. Minimum masking capability is not available if router-based aggregation is not enabled.

Examples

The following example shows how to configure the mask to use the destination-prefix as the aggregation cache scheme with a minimum mask value of 32:

Router(config)# ipv6 flow-aggregation cache destination-prefix

Router(config-flow-cache)# mask destination minimum 32

Related Commands

match (IKEv2 policy)

To match a policy based on Front-door VPN Routing and Forwarding (FVRF) or local parameters, such as an IP address, use the match command in IKEv2 policy configuration mode. To delete a match, use the no form of this command.

match address local {ipv4-address | ipv6-address | fvrf fvrf-name | any}

no match address local {ipv4-address | ipv6-address | fvrf fvrf-name | any}

Syntax Description

Command Default

If no match address is specified, the policy matches all local addresses.

Command Modes

IKEv2 policy configuration (crypto-ikev2-policy)

Command History

Usage Guidelines

Use this command to match a policy based on the FVRF or the local IP address (IPv4 or IPv6). The FVRF specifies the VRF in which the IKEv2 security association (SA) packets are negotiated. The default FVRF is the global FVRF. Use the match fvrf any command to match a policy based on any FVRF.

A policy with no match address local statement will match all local addresses. A policy with no match FVRF statement will match the global FVRF. If there are no match statements, an IKEv2 policy matches all local addresses in the global VRF.

Examples

The following example shows how to match an IKEv2 policy based on the FVRF and the local IPv4 address:

Router(config)# crypto ikev2 policy policy1

Router(config-ikev2-policy)# proposal proposal1

Router(config-ikev2-policy)# match fvrf fvrf1

Router(config-ikev2-policy)# match address local 10.0.0.1

The following example shows how to match an IKEv2 policy based on the FVRF and the local IPv6 address:

Router(config)# crypto ikev2 policy policy1

Router(config-ikev2-policy)# proposal proposal1

Router(config-ikev2-policy)# match fvrf fvrf1

Router(config-ikev2-policy)# match address local 2001:DB8:0:ABCD::1

Related Commands

match (IKEv2 profile)

To match a profile on front-door VPN routing and forwarding (FVRF) or local parameters such as the IP address, the peer identity, or the peer certificate, use the match command in IKEv2 profile configuration mode. To delete a match, use the no form of this command.

match {address local {ipv4-address | ipv6-address | interface name} | certificate certificate-map | fvrf {fvrf-name | any} | identity remote {address {ipv4-address [mask] | ipv6-address prefix} | email [domain] string | fqdn [domain] string | key-id opaque-string}

no match {address local {ipv4-address | ipv6-address | interface name} | certificate certificate-map} | fvrf {fvrf-name | any} | identity remote {address {ipv4-address [mask] | ipv6-address prefix} | email [domain] string | fqdn [domain] string | key-id opaque-string}

Syntax Description

Command Default

A match is not specified.

Command Modes

IKEv2 profile configuration (crypto-ikev2-profile)

Command History

Usage Guidelines

In an IKEv2 profile, multiple match statements of the same type are logically ORed and match statements of different types are logically ANDed.

Note The match identity remote and match certificate statements are considered the same type of statements and are ORed.

The result of configuring multiple match certificate statements is the same as configuring one match certificate statement. Hence, using a single match certificate statement as a certificate map caters to multiple certificates and is independent of trustpoints.

Note There can only be one match FVRF statement.

For example, the following command translates to the subsequent "and", "or" statement:

crypto ikev2 profile profile-1

 match vrf green

 match local address 10.0.0.1

 match local address 10.0.0.2

 match certificate remote CertMap

(vrf = green AND (local addr = 10.0.0.1 OR local addr = 10.0.0.1) AND remote certificate match CertMap).

There is no precedence between match statements of different types, and selection is based on the first match. Configuration of overlapping profiles is considered as a misconfiguration.

Examples

The following examples show how an IKEv2 profile is matched on the remote identity. The following profile caters to peers that identify using fqdn example.com and authenticate with rsa-signature using trustpoint-remote. The local node authenticates with pre-share using keyring-1.

Router(config)# crypto ikev2 profile profile2

Router(config-ikev2-profile)# match identity remote fqdn example.com

Router(config-ikev2-profile)# identity local email router2@example.com

Router(config-ikev2-profile)# authentication local pre-share

Router(config-ikev2-profile)# authentication remote rsa-sig

Router(config-ikev2-profile)# keyring keyring-1

Router(config-ikev2-profile)# pki trustpoint trustpoint-remote verify

Router(config-ikev2-profile)# lifetime 300

Router(config-ikev2-profile)# dpd 5 10 on-demand

Router(config-ikev2-profile)# virtual-template 1

Related Commands 

match access-group name

To specify the name of an IPv6 access list against whose contents packets are checked to determine if they belong to the traffic class, use the match access-group name command in class-map configuration mode. To remove the name of the IPv6 access list, use the no form of this command.

match access-group name ipv6-access-group

no match access-group name ipv6-access-group

Syntax Description

Command Default

No match criteria are configured.

Command Modes

Class-map configuration

Command History

Usage Guidelines

For class-based weighted fair queueing (CBWFQ), you define traffic classes based on match criteria including access control lists (ACLs), protocols, input interfaces, QoS labels, and EXP field values. Packets satisfying the match criteria for a class constitute the traffic for that class.

The match access-group name command specifies an IPv6 named ACL only. The contents of the ACL are used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map.

To use the match access-group name command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish. After you identify the class, you can use one of the following commands to configure its match criteria:

•match access-group

•match dscp

•match mpls experimental

•match precedence

•match protocol

If you specify more than one command in a class map, only the last command entered applies. The last command overrides the previously entered commands.

Examples

The following example specifies an access list named ipv6acl against whose contents packets will be checked to determine if they belong to the traffic class:

class-map ipv6_acl_class

match access-group name ipv6acl

Related Commands

match dscp

To identify one or more differentiated service code point (DSCP), Assured Forwarding (AF), and Certificate Server (CS) values as a match criterion, use the match dscp command in class-map configuration or policy inline configuration mode. To remove a specific DSCP value from a class map, use the no form of this command.

match [ip] dscp dscp-value [dscp-value dscp-value dscp-value dscp-value dscp-value dscp-value dscp-value]

no match [ip] dscp dscp-value

Syntax Description

Command Default

No match criteria are configured.
If you do not enter the ip keyword, matching occurs on both IPv4 and IPv6 packets.

Command Modes

Class-map configuration (config-cmap)
Policy inline configuration (config-if-spolicy-inline)

Command History

Usage Guidelines

This command can be used with both Flexible NetFlow and Performance Monitor. These products use different commands to enter the configuration mode in which you issue this command.

Cisco Performance Monitor in Cisco IOS Release 15.1(3)T and 12.2(58)SE

You must first enter the service-policy type performance-monitor inline command.

DSCP Values

You must enter one or more differentiated service code point (DSCP) values. The command may include any combination of the following:

•Numbers (0 to 63) representing differentiated services code point values

•AF numbers (for example, af11) identifying specific AF DSCPs

•CS numbers (for example, cs1) identifying specific CS DSCPs

•default—Matches packets with the default DSCP.

•ef—Matches packets with EF DSCP.

For example, if you wanted the DCSP values of 0, 1, 2, 3, 4, 5, 6, or 7 (note that only one of the IP DSCP values must be a successful match criterion, not all of the specified DSCP values), enter the match dscp 0 1 2 3 4 5 6 7 command.

This command is used by the class map to identify a specific DSCP value marking on a packet. In this context, dscp-value arguments are used as markings only and have no mathematical significance. For instance, the dscp-value of 2 is not greater than 1. The value simply indicates that a packet marked with the dscp-value of 2 is different than a packet marked with the dscp-value of 1. The treatment of these marked packets is defined by the user through the setting of Quality of Service (QoS) policies in policy-map class configuration mode.

Match Packets on DSCP Values

To match DSCP values for IPv6 packets only, the match protocol ipv6 command must also be used. Without that command, the DSCP match defaults to match both IPv4 and IPv6 packets.

To match DSCP values for IPv4 packets only, use the ip keyword. Without the ip keyword the match occurs on both IPv4 and IPv6 packets. Alternatively, the match protocol ip command may be used with match dscp to classify only IPv4 packets.

After the DSCP bit is set, other QoS features can then operate on the bit settings.

The network can give priority (or some type of expedited handling) to marked traffic. Typically, you set the precedence value at the edge of the network (or administrative domain); data is then queued according to the precedence. Weighted fair queueing (WFQ) can speed up handling for high-precedence traffic at congestion points. Weighted Random Early Detection (WRED) can ensure that high-precedence traffic has lower loss rates than other traffic during times of congestion.

Cisco 10000 Series Routers

The Cisco 10000 series routers support DSCP matching of IPv4 packets only. You must include the ip keyword when specifying the DSCP values to use as match criterion.

You cannot use the set ip dscp command with the set ip precedence command to mark the same packet. DSCP and precedence values are mutually exclusive. A packet can have one value or the other, but not both.

Examples

The following example shows how to set multiple match criteria. In this case, two IP DSCP value and one AF value.

Router(config)# class-map map1

Router(config-cmap)# match dscp 1 2 af11

Cisco Performance Monitor in Cisco IOS Release 15.1(3)T and 12.2(58)SE

The following example shows how to use the policy inline configuration mode to configure a service policy for Performance Monitor. The policy specifies that packets traversing Ethernet interface 0/0 that match the criteria specified by DSCP value 2 will be monitored based on the parameters specified in the flow monitor configuration named fm-2:

Router(config)# interface ethernet 0/0

Router(config-if)# service-policy type performance-monitor inline input

Router(config-if-spolicy-inline)# match dscp 2

Router(config-if-spolicy-inline)# flow monitor fm-2

Router(config-if-spolicy-inline)# exit

Related Commands

match identity

To match an identity from a peer in an Internet Security Association and Key Management Protocol (ISAKMP) profile, use the match identity command in ISAKMP profile configuration mode. To remove the identity, use the no form of this command.

match identity {group group-name | address {address [mask] [fvrf] | ipv6 ipv6-address} | host host-name | host domain domain-name | user user-fqdn | user domain domain-name}

no match identity {group group-name | address {address [mask] [fvrf] | ipv6 ipv6-address} | host host-name | host domain domain-name | user user-fqdn | user domain domain-name}

Syntax Description

Command Default

No default behavior or values

Command Modes

ISAKMP profile configuration (conf-isa-prof)

Command History

Usage Guidelines

There must be at least one match identity command in an ISAKMP profile configuration. The peers are mapped to an ISAKMP profile when their identities are matched (as given in the ID payload of the Internet Key Exchange [IKE] exchange) against the identities that are defined in the ISAKMP profile. To uniquely map to an ISAKMP profile, no two ISAKMP profiles should match the same identity. If the peer identity is matched in two ISAKMP profiles, the configuration is invalid.

Examples

The following example shows that the match identity command is configured:

crypto isakmp profile vpnprofile

 match identity group vpngroup

 match identity address 10.53.11.1

 match identity host domain example.com

 match identity host server.example.com

Related Commands

match ipv6

To configure one or more of the IPv6 fields as a key field for a Flexible NetFlow flow record, use the match ipv6 command in Flexible NetFlow flow record configuration mode. To disable the use of one or more of the IPv6 fields as a key field for a Flexible NetFlow flow record, use the no form of this command.

match ipv6 {dscp | flow-label | next-header | payload-length | precedence | protocol | traffic-class | version}