Layer 3 Configuration
The Cisco Nexus 3550-T Programmable Switch Platform supports a number of unicast and multicast routing protocols, along with static Network Address Translation (NAT) and filtering of ingress packets using Access Control Lists (ACL).
Border Gateway Protocol
Nexus 3550-T supports using BGP to exchange routes between configured peer routers both within the same Autonomous System and across Autonomous Systems. The following sections contain information about BGP features supported by Nexus 3550-T.
Starting a BGP Instance
To start a BGP instance, use the following command:
admin@NX-3550-T# config router bgp <AS NUMBER>
where AS NUMBER is the local Autonomous System number. Once the BGP instance is started, this argument can be omitted for the purpose of entering the BGP configuration mode. Currently, only one BGP instance can be active at any given time.
To stop the BGP instance, use the following command:
admin@NX-3550-T# config no router bgp
Configuring BGP Peers
Routers become part of a BGP network by explicitly peering with other BGP routers. To add a BGP peer, use the following command:
admin@NX-3550-T# config router bgp neighbor <ADDRESS> remote-as <AS NUMBER>
where ADDRESS is the IPv4 address of the neighbour and AS NUMBER is the neighbour's Autonomous System number.
To remove a BGP peer, use the "no" form of that command:
admin@NX-3550-T# config router bgp no neighbor <ADDRESS>
To display information about a BGP peer, use the following command:
admin@NX-3550-T# show ip bgp neighbors <ADDRESS>
If ADDRESS is omitted, then information about all configured BGP peers is displayed.
Configuring External Peer Maximum Hops
By default, an eBGP neighbour is assumed to be directly connected. To change the maximum allowed hops to an eBGP neighbour, use the following command:
admin@NX-3550-T# config router bgp neighbor <ADDRESS> ebgp-multihop <HOP>
Configuring Next-Hop-Self
By default, it is assumed that an Interior Gateway Protocol is running within an Autonomoys System, and routes advertised between iBGP neighbours do not point the next hop address to the advertising router. To change that behaviour, use the following command:
admin@NX-3550-T# config router bgp neighbor <ADDRESS> next-hop-self
Configuring Shared Password
To configure a shared password used during peering, use the following command:
admin@NX-3550-T# config router bgp neighbor <ADDRESS> password <PASSWORD>
Configuring Update-Source
Loopback Interfaces are commonly used for iBGP peering. This is because iBGP usually requires that the peers form a full mesh. If a physical interface is used for iBGP peering and that physical interface goes down, network connectivity will be disrupted. With loopback interfaces, the iBGP router can remain reachable through other routes.
To make the source IP address of BGP packets sent to the neighbour agree with the neighbour's configured IP address (which will be the address of our loopback interface), it is necessary to use to following command:
admin@NX-3550-T# config router bgp neighbor <ADDRESS> update-source <INTERFACE>
where INTERFACE is the name of the loopback interface.
Filtering Route Updates
Nexus 3550-T supports using both Route Maps and Prefix Lists to filter and modify prefixes advertised to and received from a BGP neighbour. To configure prefix list or route map filtering:
admin@NX-3550-T# config router bgp address-family ipv4 unicast neighbor <ADDRESS> <prefix-list|route-map> <NAME> <in|out>
where in applies the named prefix list or route map identified by NAME to route updates received from the peer, and out to route updates advertised to the peer.
To disable filtering, use the following command:
admin@NX-3550-T# config router bgp address-family ipv4 unicast no neighbor <ADDRESS> <prefix-list|route-map> <NAME> <in|out>
Resetting BGP Sessions
Resetting the affected BGP session is required after changing route filtering policies for a peer for the new policies to take effect. Nexus 3550-T supports both hard and soft reset. Hard reset closes the TCP connection to the BGP peer and re-establishes the connection, deleting all routes learnt from that peer. Soft reset, when enabled for a peer (see the next section), runs the new filtering policy through all recorded route updates.
To perform a BGP reset, use the following command:
admin@NX-3550-T# clear ip bgp <PEER|AS NUMBER|*> [soft <in|out>]
This command allows the user to reset BGP sessions with a given peer, for all peers with a given remote AS number, or all peers in the system.
Configuring Soft Reconfiguration
By default, if filtering policies are changed for an established BGP session, the new policies do not take effect until the peering session is reset. Nexus 3550-T supports inbound soft reconfiguration. When active in a peering session, Nexus 3550-T will store route updates from that neighbour in memory and update the BGP instance's routing table when filtering policies change. This removes the need to perform hard resets at the expense of memory usage. To enable inbound soft reconfiguration for a peer, use the following command:
admin@NX-3550-T# config router bgp neighbor <ADDRESS> soft-reconfiguration inbound
Announcing Reachable Networks
To add a network into the BGP routing table, use the following command:
admin@NX-3550-T# config router bgp address-family ipv4 unicast network <NETWORK>
where NETWORK is an IPv4 network specified using CIDR notation. Once the prefix is added to the BGP routing table, it
To remove a network from the BGP routing table, use the "no" form of the above command:
admin@NX-3550-T# config router bgp address-family ipv4 unicast no network <NETWORK>
Route maps can be used to modified attributes of statically-added BGP prefixes:
admin@NX-3550-T# config router bgp address-family ipv4 unicast network <NETWORK> route-map <RM NAME>
See the section on Route Maps for details.
Displaying the BGP Routing Table
To display the BGP routing table, use the following command:
admin@NX-3550-T# show ip bgp [NETWORK]
where NETWORK is an IPv4 network specified in CIDR notation. If this argument is given, then only those BGP prefixes through which the network is reachable are returned. Otherwise, the entire BGP routing table is displayed.
Configuring Redistribution into BGP
Routes from other routing protocols and sources can be redistributed into the BGP routing table. These sources include:
- Statically configured routes
- Kernel routes configured using Linux tools
- Directly connected networks
- OSPF
To configure redistribution into the BGP routing table, use the following command:
admin@NX-3550-T# config router bgp address-family ipv4 unicast redistribute <SOURCE>
SOURCE can be one of static, kernel, connected or ospf.
To disable a redistribution source, use the following command:
admin@NX-3550-T# config router bgp address-family ipv4 unicast no redistribute <SOURCE>
Route Maps can be used to control route redistribution into the BGP routing table.
Displaying Miscellaneous BGP Information
Displaying BGP Summary
admin@NX-3550-T# show ip bgp summary
BGP router identifier 192.168.10.1, local AS number 123
BGP table version 0
RIB entries 0, peers 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.10.2 4 456 0 0 0 0 0 00:00:00 active
Total number of neighbors 1
Open Shortest Path First Protocol
OSPFv2 is an IETF link-state protocol for IPv4 networks. It is an interior gateway protocol that operates within a single autonomous system. Neighbors advertise link-state information that include information like link cost that can be used to build a routing table for the network.
The Nexus 3550-T CLI can be used to enable and configure OSPFv2 on the device.
Configure OSPFv2
OSPF is enabled by starting a service instance. Nexus 3550-T currently only supports one OSPF instance. Once an instance is started interfaces can be associated with it. The OSPF instance has global and interface specific parameters that can be configured.
Start OSPFv2 instance
To enable OSPFv2 start an instance using the following CLI command:
admin@NX-3550-T# config router ospf
To stop the OSPFv2 instance use the following command:
admin@NX-3550-T# config no router ospf
To configure OSPF instance settings enter the OSPF router mode and configure the parameters as required. To set the specific parameters back to their default use the no <parameter> form.
admin@NX-3550-T# config router ospf
admin@NX-3550-T(config-router)#
Set the reference bandwidth used to calculate link cost with the following command (for example 40Gb):
admin@NX-3550-T(config-router)# auto-cost reference-bandwidth 40000
Set the OSPFv2 administrative distance. The allowed value is a decimal in the range 1-255. For example:
admin@NX-3550-T(config-router)# distance 120
Set all interfaces to be in passive mode by default. This will not affect interfaces already configured for OSPF.
admin@NX-3550-T(config-router)# passive-interface default
Set the routes that can be redistributed via OSPF. Options allowed are as follows:
- Statically configured routes
- Kernel routes not installed by the management software
- Directly connected networks
- BGP
To enable redistribution of BGP routes via OSPF use the following command:
admin@NX-3550-T(config-router)# redistribute bgp
Show the running OSPF instance details with the following CLI command:
admin@NX-3550-T# show ip ospf
OSPF Routing Process with ID: 192.168.200.1
Supports only single TOS(TOS0) routes
Does not support opaque LSA
Administrative distance 110
Reference Bandwidth is 100000 Mbps
Minimum LSA interval 5000 msec
Minimum LSA arrival 1000 msec
Number of external LSAs 0, checksum sum 0x0
Number of opaque AS LSAs 0, checksum sum 0x0
Number of areas is 0
Configure Networks
A network is configured by associating the interface that is connected to that network. All networks can be added to the default backbone area or new areas can be created. An area is identified by a number that is either a decimal number in the range 0-4294967295 or a valid IPv4 address. The backbone area is defined as Area 0 (0.0.0.0).
To associate a network interface with an OSPFv2 backbone area, use the following CLI commands:
admin@NX-3550-T# config int eth1 ip ospf area 0
Nexus 3550-T supports simple clear-text password authentication. To enable authentication and set the password use the following commands:
admin@NX-3550-T# config int eth1 ip ospf authentication
admin@NX-3550-T# config int eth1 ip ospf authentication-key secret
To change the routing cost of an interface to a decimal value between 1-65535, use:
admin@NX-3550-T# config int eth1 ip ospf cost 80
It is possible to change the network type that an interface is connected to. The default type is set to 'Broadcast'. Supported network types are:
- Broadcast multi-access network
- Non-broadcast multi-access network
- Point-to-multipoint network
- Point-to-point network
The following command can be used to set an interface to the 'point-to-point' network type:
admin@NX-3550-T# config int eth1 ip ospf network point-to-point
To set an interface to passive mode and suppress routing updates for that interface use:
admin@NX-3550-T# config int eth1 ip ospf passive-interface
The router priority can be set for an interface. Setting the priority to 0 means the router will never become the Designated Router. To set the router priority use:
admin@NX-3550-T# config int eth1 ip ospf priority 0
To show a summary of OSPF enabled interfaces, use the following command:
admin@NX-3550-T# show ip ospf interface brief
Total number of interfaces: 1
Interface Area Cost State Neighbors Status
ethernet1 0.0.0.0 10 Backup 1 up
To show the interface details use the following CLI command:
admin@NX-3550-T# show ip ospf interface
ethernet1 is up
IP address 192.168.4.2/24
Router ID 192.168.200.1, Area 0.0.0.0
State Backup, Network type BROADCAST, Cost 10
Transmit delay 1 sec, Priority 1
Backup Designated Router ID 192.168.200.1, Address 192.168.4.2
Neighbor count 1, adjacent with 1
Timer intervals: Hello 10s, Dead 40s, Wait 40s, Retransmit 5s
Hello due in 00:00:05
Display OSPFv2 Specific Information
When an OSPFv2 instance is enabled and interfaces have been associated neighbor and route information can be displayed.
Display OSPFv2 neighbor information
admin@NX-3550-T# show ip ospf neigbors
Total number of neigbors: 2
Neighbor ID Pri State Dead Time Address Interface
192.168.4.1 1 Full/DR 00:00:32 192.168.3.2 ethernet2
192.168.5.1 1 Full/DR 00:00:38 192.168.4.1 ethernet1
Display OSPFv2 route information
admin@NX-3550-T# show ip ospf route
Total number of networks: 7
Network Type Cost Area Nexthop
192.168.1.0/24 intra 20 0.0.0.0 192.168.4.1 on ethernet1
192.168.101.0/24 type2 20 192.168.3.2 on ethernet2
192.168.4.1 on ethernet1
192.168.2.0/24 intra 20 0.0.0.0 192.168.3.2 on ethernet2
192.168.3.0/24 intra 10 0.0.0.0 direct on ethernet2
192.168.4.0/24 intra 10 0.0.0.0 direct on ethernet1
192.168.6.0/24 inter 30 0.0.0.0 192.168.3.2 on ethernet2
192.168.4.1 on ethernet1
192.168.8.0/24 intra 10 4.3.2.1 direct on ethernet4
Configure Static Routing
With the Nexus 3550-T CLI, you can configure static routes. You have the following options:
- Via some physical interface
- Via a virtual interface
- A blackhole route without any interface
To configure routes, use the following commands.
Routes via Physical Interfaces
admin@NX-3550-T# config ip route 200.200.200.0/24 200.200.200.1 et48
Routes via Virtual Interfaces
admin@NX-3550-T# config ip route 200.200.210.0/24 200.200.210.1 vlan10
Blackhole Routes
admin@NX-3550-T# config ip route 200.200.220.0/24 null 255
You can also specify the admin distance for a particular route while configuring the routes as a last parameter of that command. The supported range of admin distance is 0 to 255, where the lower value has higher priority over the higher values. To view the configured routes by use the show running config command.
Note
If you configure two routes for the same network with same admin distance, then the behavior is undefined. If the admin distances are different, then the reachable route with lower admin distance is pushed to FIB.
IGMP and Multicast Support
Nexus 3550-T includes support for IGMP snooping to optimize delivery of IPv4 multicast traffic. Nexus 3550-T learns about the multicast traffic on the basis of either static joins triggered from CLI or dynamically by snooping the IGMP reports coming from the hosts connected to it.
Enable IGMP
You can select the routed ports that need to participate in the multicast traffic processing. To enable IGMP on a particular port, use the following CLI command:
admin@NX-3550-T# config int et8 ip pim
Verify the IGMP Status
The Nexus 3550-T CLI enables you to verify the status of IGMP service on a particular port by using the following CLI command:
admin@NX-3550-T# show ip pim int et8
ethernet8
IP address: 192.168.10.1
PIM DR: 192.168.10.1, DR's priority: 1
PIM neighbor count: 0
Dump IGMP Neighbor and Rendezvous Point
Apart from the generic PIM configurations, you can also dump the neighbor and rendezvous point by using the following CLI commands.
Dump IGMP Neighbor
To dump the IGMP neighbor, use the following CLI command:
admin@NX-3550-T# show ip pim neighbor et8
Neighbor Interface Uptime Holdtime DR Priority
Dump IGMP Rendezvous Point
To dump the IGMP rendezvous point, use the following CLI command:
admin@NX-3550-T# show ip pim rp
RP address Group OIF Source
192.168.10.2 224.0.0.0/4 ethernet8 static
Note
Currently, the option to enable or disable the IGMP reports snooping via CLI is not supported.
Display the Snooped IGMP Groups
The Nexus 3550-T CLI enables you to see all the multicast groups that have been snooped on a specific port by using the following CLI command:
admin@NX-3550-T# show ip igmp snooping
Switchport Group VLAN
et2 224.0.0.0/4 10
Configure IGMP Version
The Nexus 3550-T CLI enables you to configure the version of IGMP protocol. You can configure the version to be either IGMPv2 or IGMPv3 by using the following CLI command:
admin@NX-3550-T# config int et8 ip igmp version 3
Display IGMP Version
The Nexus 3550-T CLI enables you to verify the version of IGMP service running on each configured port by using the following CLI command:
admin@NX-3550-T# show ip igmp interface
Interface State Address V Querier Query Timer Uptime
ethernet1 up 10.0.1.1 2 local 00:01:20 05:34:37
ethernet8 up 192.168.10.1 3 local 00:01:20 05:34:37
vlan10 up 10.0.0.1 3 local 00:01:48 05:34:08
To verify the version on a particular port, use the same CLI command appended with the interface name:
admin@NX-3550-T# show ip igmp interface et1
Interface State Address V Querier Query Timer Uptime
ethernet1 up 10.0.1.1 2 local 00:01:20 05:34:37
Static IGMP Join
The Nexus 3550-T CLI enables you to configure joining multicast groups by using static joins. Use the following command to configure Nexus 3550-T as a member of a specific multicast group. To configure static joins for specific multicast groups, use the following CLI command:
admin@NX-3550-T# config int et8 ip igmp join-group 224.0.2.10
Display IGMP Groups Subscription
To verify the specific multicast groups subscribed on specific ports, use the following CLI command:
admin@NX-3550-T# show ip igmp groups
Interface Address Group Mode Timer Srcs V Uptime
ethernet8 192.168.10.1 224.0.2.10 EXCLUDE 00:04:19 1 3 00:00:04
To verify the specific multicast groups subscribed on specific ports which are locally joined by using the CLI, use the following CLI command:
admin@NX-3550-T# show ip igmp local-groups
Interface Address Source Group Uptime
ethernet8 192.168.10.1 * 224.0.2.10 00:05:37
Network Address Translation / Port Address Translation
Network Address Translation (NAT) / Port Address Translation (PAT) enables translation of local or private network IP addresses (and TCP/UDP ports) to global or public network IP addresses (and TCP/UDP ports). With the Nexus 3550-T you can configure a one-to-one mapping of the local IP address and port pair to the global IP Address and port pair. This configuration is also known as Static NAT.
Configuring NAT Rules
To add an address mapping, use the following command:
admin@NX-3550-T# config ip nat source static <LOCAL IP> <GLOBAL IP>
where LOCAL IP is the IP address as appears on the inside network, and GLOBAL IP is the IP address as appears on the outside network.
To add an address/port mapping, use the following command:
admin@NX-3550-T# config ip nat source static <tcp|udp> <LOCAL IP> <LOCAL PORT> <GLOBAL IP> <GLOBAL PORT>
Configuring NAT Ports
To let interfaces participate in NAT, place the inside NAT marker on inside-network-facing interfaces, and outside NAT marker on outside-network-facing interfaces:
admin@NX-3550-T# config int <INTERFACE> ip nat <inside|outside>
Packets that arrive on an outside NAT interface undergo destination address and port translation, while packets that arrive on an inside NAT interface undergo source address and port translation.
To disable NAT on an interface, use the "no" form of the above command:
admin@NX-3550-T# config int <INTERFACE> no ip nat <inside|outside>
Note
As of release 1.1.0, only L3 interfaces and L3 port channels can participate in NAT. Switchports and SVIs cannot perform NAT.
Access Control Lists
Nexus 3550-T supports ACL filtering of ingress packets on L3 interfaces and port channels. To apply packet filtering policies on an interface, first create a named access control list and then add the interface to that access group under the interface configuration mode.
Creating an Access Control List
To create a named ACL, use the following command to enter the ACL mode:
admin@NX-3550-T# config ip access-list <NAME>
Once inside the ACL mode, use the following command to create an ACL clause:
admin@NX-3550-T(config-acl)# [SEQ] <permit|deny> <PROT> <SRC NETWORK> [SRC PROT OPTIONS] <DST NETWORK> [DST PROT OPTIONS]
SEQ is an optional argument specifying where in the access control list to insert the new clause. If this argument is omitted for the first clause in a new ACL, that clause will have the sequence number 5. For a new clause in an existing ACL, the sequence number will be 5 after the sequence number of the last clause in the ACL.
When a packet is matched against an ACL, the clauses are evaluated in the order of their sequence numbers until a match is found, at which time the matching policy of the clause, which can either be "permit" or "deny", is returned as the evaluation result of the ACL. If no match is found, then the result is implicitly "deny".
PROT is the protocol that the clause will match. It can be a number from 0 to 255, or it can be one of "ip", "icmp", "tcp" or "udp". If a number is given, then that number is used to match verbatim the IPv4 protocol field of the packet. To match all IPv4 packets, use "ip".
SRC NETWORK and DST NETWORK match against the source and destination addresses of the IPv4 packet. The network can be specified in the following ways: CIDR notation, address plus bitmask, "any" for any host, and "host" for a single host, equivalent to a bitmask of 255.255.255.255 or an address length of 32 in CIDR notation.
SRC PROT OPTIONS and DST PROT OPTIONS are higher-level protocol options to match. As of release 1.1.0, the only options implemented are TCP and UDP ports. The port is specified using the operators "eq", "lt", and "gt", for "equal to", "less than" and "greater than", respectively. "lt" and "gt" can be used alone or combined to match against a range of ports, while "eq" can be used to match the exact TCP or UDP port.
Below is an example clause:
admin@NX-3550-T(config-acl)# 42 permit tcp any 192.168.0.0 255.255.0.0 eq 8080
which inserts a clause at sequence number 42 that permits TCP packets bound for 192.168.0.0/16 network with destination port 8080.
Note
As of release 1.1.0, to specify higher-level protocol options such as TCP and UDP port range, the protocol must be specified in text instead of number. If "6" is given as the protocol, the CLI will not recognise it as "tcp" or parse TCP protocol arguments.
Applying an Access Control List
To apply ACL filtering on an interface, use the following command:
admin@NX-3550-T# conf int <INTERFACE> ip access-group <NAME> in
where NAME is the name of the ACL to apply.
Currently only ACL filtering on the ingress direction is supported.
Note
As of release 1.1.0, ACL filtering is only supported on L3 interfaces and L3 port channels. Switchports and SVIs cannot use ACL.
Deleting Access Control Lists and Clauses
To delete an ACL clause, use either the no form of the ACL clause creation command:
admin@NX-3550-T(config-acl)# no <permit|deny> <PROT> <SRC NETWORK> [SRC PROT OPTIONS] <DST NETWORK> [DST PROT OPTIONS]
Alternatively, ACL clauses can also be deleted by sequence number:
admin@NX-3550-T(config-acl)# no <SEQ>
Examine the running configs to identify the sequence number of the clause to delete.
To delete an entire ACL, use the following command:
admin@NX-3550-T# conf no ip access-list <NAME>
Prefix Lists
A prefix list is an ordered list of network prefixes and matching policies. It is used for specifying network ranges for which to perform operations. When a network prefix, such as the destination network of a BGP route, is evaluated against a prefix list, each prefix list entry is compared with the network prefix in order until a match is found, at which point the matching policy ("permit" or "deny") is returned. "Permit" allows further processing of the network prefix, such as inserting into the BGP routing table.
Creating a Prefix List
To create a prefix list entry, use the following command:
admin@NX-3550-T# config ip prefix-list <NAME> [seq <SEQ>] <permit|deny> <NETWORK> [ge <LEN>|le <LEN>|eq <LEN>]
where NAME identifies the prefix list. SEQ is an optional argument that specifies where in the prefix list to insert the new entry. If omitted, 5 is chosen for the first entry in a new prefix list, and 5 after the sequence number of the last entry is used for additional entries in an existing prefix list.
NETWORK is an IPv4 prefix in CIDR notation. ge and le are lower and upper bounds for the address length of a matched prefix. If neither ge, le nor eq is provided, the address length of the match prefix must be exactly the same as that of NETWORK to produce a match. Otherwise, the significant bits in the matched prefix are checked against NETWORK and the address length is checked against the upper and lower bound.
For example, the following entry will only match a prefix that is exactly 192.168.0.0/16 and return deny:
admin@NX-3550-T# config ip prefix-list foo deny 192.168.0.0/16
while the following entry will permit a prefix included in 192.168.0.0/16 with an address length shorter than 24:
admin@NX-3550-T# config ip prefix-list foo deny 192.168.0.0/16 le 24
When the prefix 192.168.1.0/24 is evaluated against prefix list foo, the first entry will not match the prefix, since the length is 24 instead of 16, but the second entry will match the prefix, since 192.168.1.0/24 is a subset of 192.168.0.0/16 and the address length is exactly 24.
Deleting Prefix Lists and Entries
Similar to ACL, a prefix list entry can also be deleted either by policy:
admin@NX-3550-T# config no ip prefix-list <NAME> <permit|deny> <NETWORK> [ge <LEN>|le <LEN>|eq <LEN>]
or by sequence number:
admin@NX-3550-T# config no ip prefix-list <NAME> seq <SEQ>
To delete an entire prefix list, use the following command:
admin@NX-3550-T# config no ip prefix-list <NAME>
Route Maps
Route maps provides a mechanism to filter routes and set protocol-specific attributes based on certain match conditions. As of release 1.1.0, the only routing protocol that makes use of route maps is BGP.
A route map is a named list of entries. An entry has a sequence number, a matching policy, a number of match conditions, a number of set actions, and optionally a continue clause. When a route is evaluated against a route map, these entries are evaluated in the order of their sequence numbers until an entry is found where all match conditions are satisfied. If no matches are found, the route is implicitly denied. Depending on the matching policy and the presence of the continue clause, the following actions are taken when a match happens:
If the matching policy is deny, then the set actions and continue clauses are ignored. Execution stops and the route is denied.
If the matching policy is permit, then the set actions are carried out. By default, execution stops and the route is permitted, unless a continue clause is present, in which case execution continues at the specified clause. The behavior of the route map at this point is the same as described above except that if execution reaches the end of the route map without producing another match, permit is returned instead of the implicit deny.
Adding a Route Map Entry
To add a route map entry, use the following command:
admin@NX-3550-T# config route-map <NAME> <permit|deny> <SEQ>
This command will enter the CLI into the route map entry configuration mode, which allows the user to add match, set and continue actions to the entry.
admin@NX-3550-T(config-route-map)# ?
continue Continue on a different entry within this route map
end Exit configuration mode
exit Exit route-map configuration mode
match Match values from routing table
no Negate a command or set to defaults
set Set values in destination routing protocol
Match Conditions
As of release 1.1.0, the following match conditions are supported:
as-path: match the list of Autonomous Systems traversed to reach the destination network of a BGP prefixinterface: first-hop interface of a routeip address: match the destination network of a route, specified using a prefix listip next-hop: match the next-hop address of a route, specified using a prefix listmetric: match the metric value of a routeorigin: match the BGP origin code, which can be eitherigp,egporincomplete, for routes learnt from iBGP peers, eBGP peers and other sources, respectivelysource-protocol: match the routing protocol from which this route was redistributedtag: match the route tag
To remove a match condition, use the "no" form of the command:
admin@NX-3550-T(config-route-map)# no match <ATTR>
Set Actions
As of release 1.1.0, the following set actions are supported:
as-path prepend: prepend either the last Autonomous System or a specified AS number in front of the AS path of a BGP route to influence route preferencecommunity: set the community attribute of a BGP route. Theadditiveoption can be specified to add to the list of communities rather than overwrite itdistance: set the administrative distance of a route to influence route preferenceip next-hop: set the next hop of a route to either the advertising peer (BGP-specific) or a specified IPv4 addresslocal-preference: set the local preference attribute of a BGP routemetric: set the metric of a route. The metric can either be a number, or+or-followed by a number to add or subtract from the current metric.origin: set the BGP origin code toigp,egporincompletetag: set the route tagweight: set the weight attribute of a BGP route
To remove a set action, use the "no" form of the command:
admin@NX-3550-T(config-route-map)# no set <ATTR>
Continue Clause
To add a continue clause, use the following command:
admin@NX-3550-T(config-route-map)# continue [SEQ]
When this continue clause is evaluated, execution will continue from the first entry with a sequence number greater or equal to SEQ. If SEQ is omitted, execution continues with the next entry after the current entry.
To remove the continue clause, use the "no" form of the command:
admin@NX-3550-T(config-route-map)# no continue
Configuring Loopback Interfaces
When using Nexus 3550-T as the Rendezvous Point in PIM Sparse Mode or in an iBGP network, it is often preferable to use a loopback interface instead of physical interfaces. To create a loopback interface, use the following command:
admin@NX-3550-T# config int loopback <NUMBER>
NUMBER identifies the loopback interface. For example, if NUMBER is 0, loopback0 should be used to refer to the loopback interface after creation.
Setting ip address and options for a loopback interface follows the same CLI syntax as for physical interfaces.
This page was last updated on Mar-23-2021.