RIPE plays with 1.1.1.1 and 1.2.3.4 following APNIC allocation
Last month, IANA allocated the 1.0.0.0/8 and 27.0.0.0/8 networks to APNIC (the Internet registry for the Asia-Pacific region), pushing the total IPv4 address space utilization above the ominous 90% mark. Passing this benchmark should not come as a surprise to anyone, given the painfully slow adoption of IPv6. But what's interesting about the first range in particular is the amount of junk traffic already present.
As part of an effort to de-bogonise this newly allocated address space, RIPE, in cooperation with APNIC, made some test advertisements to the global BGP table for several prefixes with 1.0.0.0/8. Specifically, these networks included 1.1.1.0/24 and 1.2.3.0/24. Why these networks? Because they contain the novel (and illegal) IPv4 addresses 1.1.1.1 and 1.2.3.4, of course.
Shortly after announcing the routes to the world, RIPE's RIS was flooded with over 50 Mbps of traffic destined for what is still an unallocated network; it should not appear on the global Internet.
The RIS RRC from which we announced 1.1.1.0/24 has connections to AMS-IX, NL-IX and GN-IX. The ... image shows the incoming traffic on the AMS-IX port (10 MBit), which was instantly maxed out, mostly by traffic coming towards 1.1.1.1. The AMS-IX sflow graphs suggested that all together our peers were trying to send us more than 50 MBit/s of traffic. Most of this traffic was dropped due to the 10 MBit limit of our AMS-IX port.
And of course, no routing experiment is complete without pretty charts:
Unfortunately, the current amount of pollution (unwanted traffic from the Internet) in the 1.1.1.0/24 and 1.2.3.0/24 prefixes makes them essentially useless and, to an extent, also devalues their less-specific parent prefixes. All because people can't follow simple standards.
Understanding IP prefix lists
IOS prefix lists work like access lists for route advertisements (prefixes). While extended (and to a limited extent, standard) access lists can be employed to match prefix announcements, prefix lists are generally more graceful. Prefix lists work very similarly to access lists; a prefix list contains one or more ordered entries which are processed sequentially. As with access lists, the evaluation of a prefix against a prefix list ends as soon as a match is found.
Assume you wanted to prevent a route for 10.0.0.0/24 from being redistributed from OSPF to BGP. One way to accomplish this would be to define an extended ACL matching this prefix and reference it from the BGP redistribution route map:
router ospf 1 router-id 2.2.2.2 log-adjacency-changes ! router bgp 65100 no synchronization bgp router-id 2.2.2.2 bgp log-neighbor-changes redistribute ospf 1 route-map OSPF->BGP neighbor 172.16.23.3 remote-as 65100 no auto-summary ! ip access-list extended OSPF_Redist deny ip host 10.0.0.0 host 255.255.255.0 permit ip any any ! route-map OSPF->BGP permit 10 match ip address OSPF_Redist
The above configuration prevents the exact prefix 10.0.0.0/24 from being advertised by denying the 10.0.0.0 network ("source" address) with a mask of 255.255.255.0 ("destination" address). All other prefixes are allowed by the permit ip any any statement.
This can be accomplished more intuitively by employing a prefix list:
router ospf 1 router-id 2.2.2.2 log-adjacency-changes ! router bgp 65100 no synchronization bgp router-id 2.2.2.2 bgp log-neighbor-changes redistribute ospf 1 route-map OSPF->BGP neighbor 172.16.23.3 remote-as 65100 no auto-summary ! ip prefix-list OSPF_Redist seq 5 deny 10.0.0.0/24 ip prefix-list OSPF_Redist seq 10 permit 0.0.0.0/0 le 32 ! route-map OSPF->BGP permit 10 match ip address prefix-list OSPF_Redist
As you can see, there are two entries in the prefix list defined above. These accomplish the same tasks as the two access list entries in the earlier example: deny 10.0.0.0/24 denies the exact prefix 10.0.0.0/24, and permit 0.0.0.0/0 le 32 allows all other prefixes.
The second prefix list entry warrants some explanation. Two keywords can be optionally appended to a prefix list entry: le (less than or equal to) and ge (greater than or equal to). Without either, an entry will match an exact prefix. The le parameter can be included to match all more-specific prefixes within a parent prefix up to a certain length. For example, 10.0.0.0/24 le 30 will match 10.0.0.0/24 and all prefixes contained therein with a length of 30 or less.
We can use le to create an entry to match "any" prefix: 0.0.0.0/0 le 32 matches any prefix with a length between 0 and 32 bits (inclusive). This matches all possible IPv4 prefixes.
The ge parameter works similarly to le but in the opposite direction; it specifies a minimum prefix length whereas le specifies a maximum length. For example, 10.0.0.0/8 ge 16 will match all prefixes within the 10.0.0.0/8 network that are at least 16 bits in length. The length specified by ge should naturally be longer than the length of the initial prefix as it is impossible to match anything larger than the initial prefix.
le and ge can also be combined. Continuing the ge example, 10.0.0.0/8 ge 16 le 24 will match all prefixes within the 10.0.0.0/8 network having a mask both a) greater than or equal to 16 bits, and b) less than or equal to 24 bits in length. For instance, 10.42.0.0/18 would be matched, because its length is between 16 and 24 (inclusive), but neither 10.8.0.0/12 nor 10.123.77.128/25 would be matched.
Prefix lists take some getting used to, but can be very helpful in expressing routing policy within IOS configuration once you've gotten the hang of them.
A call for educational IOS licensing
As Greg Ferro of Etherealmind has pointed out, IOS 15.0 will be introducing some significant complexity into the way we install and manage IOS images on Cisco routers. This brings some potentially devastating changes to the way we've been maintaining IOS devices for the last decade or so.
Up to and including IOS 12.4, the software image to be installed on a device depended on the feature set purchased from Cisco (as well as the device's physical hardware capabilities). With the latest major IOS revision, Cisco introduced a more modern (read: painful) approach to feature activation using a single universal software image and per-feature set unique license keys.
Setting aside the enormous implications this introduces to what used to be a delightfully straightforward software management scheme, I worry about what this means for the future of networking education. Up until now, the use of IOS images by students and other individuals in their home labs has been generally avoided as a topic of discussion altogether (as covered by the first two rules of Fight Lab) and accepted as a fact of the industry. But Cisco's new IOS licensing mechanism thrusts the issue into harsh light.
Cisco likes to talk about how proactive they are in education and how hard they work to help engineers pursue career advancement. And indeed they do, with their "learning network", their own press, and most recently their own CCIE study program. But what I want to see is legitimate IOS licenses and CCO accounts issued at no or low cost for individuals to use strictly for educational purposes.
To elaborate, I want to see Cisco make available fully-featured (yet restricted) IOS licenses at little or no cost for educational use by individuals. Utilizing the new software activation scheme in IOS 15, these license keys could unlock all the features of an IOS for study, yet cripple the operation of a parent device so as to make it virtually useless in a production network. Implementing a simple packet throughput limitation, for example, would do the trick. Thousands of software applications already implement such a scheme for personal and demonstration use; why not IOS?
Yes, it's a development which requires a significant investment by Cisco and yields no direct return. But consideration must also be paid to the many thousands of people who have relied on home labs and the Dynamips IOS emulator (both of which typically make use of not-quite-legally obtained software images) to achieve certification or simply to enhance their abilities as engineers overall. While I'm not against the new licensing scheme Cisco has implemented to protect their intellectual property, there is no need to forsake the community in doing so.
EtherChannel considerations
EtherChannel is Cisco's term for bundling two or more physical Ethernet links for the purposes of aggregating available bandwidth and, to a lesser extent, providing a measure of physical redundancy. Under normal conditions, all but one redundant physical link between two switches will be disabled by STP at one end.
With EtherChannel configured, multiple links are grouped into a port-channel, which is assigned its own configurable virtual interface. The bundle is treated as a single link.
EtherChannel Negotiation
An EtherChannel can be established using one of three mechanisms:
- PAgP - Cisco's proprietary negotiation protocol
- LACP (IEEE 802.3ad) - Standards-based negotiation protocol
- Static Persistence ("On") - No negotiation protocol is used
Any of these three mechanisms will suffice for most scenarios, however the choice does deserve some consideration. PAgP, while perfectly able, should probably be disqualified as a legacy proprietary protocol unless you have a specific need for it (such as ancient hardware). That leaves LACP and "on", both of which have a specific benefit.
LACP helps protect against switching loops caused by misconfiguration; when enabled, an EtherChannel will only be formed after successful negotiation between its two ends. However, this negotiation introduces an overhead and delay in initialization. Statically configuring an EtherChannel ("on") imposes no delay yet can cause serious problems if not properly configured at both ends.
To configure an EtherChannel using LACP negotiation, each side must be set to either active or passive; only interfaces configured in active mode will attempt to negotiate an EtherChannel. Passive interfaces merely respond to LACP requests. PAgP behaves the same, but its two modes are refered to as desirable and auto.
Only a single line is needed to configure a group of ports as an EtherChannel:
S1(config)# interface range f0/13 -15 S1(config-if-range)# channel-group 1 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected S1(config-if-range)# channel-group 1 mode active Creating a port-channel interface Port-channel 1
As noted, a virtual port-channel interface Port-channel1 has been created to represent the logical link. Switchport configurations applied to this interface are replicated to the physical member interfaces. We can inspect the health of the EtherChannel with the show etherchannel summary command:
S1# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SD) LACP Fa0/13(D) Fa0/14(D) Fa0/15(D)
The opposite side of the LACP EtherChannel will typically be configured as passive, however it can be active as well.
S2(config-if-range)# channel-group 1 mode passive Creating a port-channel interface Port-channel 1
When the member ports on both sides of the EtherChannel are enabled, the port-channel interface also transitions to the up state. However, note the timing of the system messages:
*Mar 1 00:45:50.647: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up *Mar 1 00:45:50.683: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up *Mar 1 00:45:50.691: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to up *Mar 1 00:45:53.487: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up
Almost a full three seconds elapsed between the member ports transitioning to the up state and the port-channel interface coming up. Once it did, we can see the state of the EtherChannel has changed to "in use":
S1# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) LACP Fa0/13(P) Fa0/14(P) Fa0/15(P)
Note the S indicating layer two operation; on multilayer platforms, EtherChannel interfaces can be configured for routed operation as well.
For comparison, let's reconfigure the EtherChannel to function without a negtiation protocol ("on" mode):
S1(config)# no interface po1 S1(config)# interface range f0/13 -15 S1(config-if-range)# channel-group 1 mode on Creating a port-channel interface Port-channel 1 S1(config-if-range)# no shutdown
This time we observe that the port-channel interface is enabled as soon as its first member port comes up, as there is no delay imposed by negotiation:
*Mar 1 00:56:12.271: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up *Mar 1 00:56:12.287: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up *Mar 1 00:56:12.291: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up *Mar 1 00:56:12.307: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to up
In the Campus Network High Availability Design Guide, Cisco recommend forgoing the use of a negotiation protocol and configuring EtherChannels for static "on/on" operation; however they also caution that this approach offers no protection against the effect of misconfigurations.
EtherChannel Load-Balancing
Another consideration to make when implementing EtherChannels is the type of load-balancing in effect. EtherChannel provides load-balancing only per frame, not per bit. A switch decides which member link a frame will traverse by the outcome of a hash function performed against one or more fields of each frame. Which fields are considered is dependent on the switch platform and configuration. For example, a Catalyst 3550 can match only against a frame's destination or source MAC address:
S1(config)# port-channel load-balance ? dst-mac Dst Mac Addr src-mac Src Mac Addr
The show etherchannel load-balance command reveals that source MAC address load-balancing is default on the Catalyst 3550:
S1# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-mac
EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source MAC address
IPv4: Source MAC address
More powerful platforms can match against IP address(es) or layer four port(s). Generally speaking, higher layer fields are more favorable as they tend to be more dynamic, resulting in a more granular distribution of traffic across member links.
Direction of flow is also an important detail. For example, consider the following topology:
Routed packets entering the subnet from S1 are always sourced from the MAC address of the VLAN interface. If source MAC load-balancing is in use, these frames will be forwarded down only one member link, because the outcome of the hash function will always be the same. Configuring destination MAC load-balancing on S1 is recommended to achieve a more varied distribution of frames and make better use of the available bandwidth.
The opposite is true on S2: Since all frames entering the EtherChannel from LAN hosts are destined for the MAC address of the gateway (VLAN interface), source MAC address load-balancing works better here.
EtherChannel Bandwidth and Costs
Finally, remember that the perceived bandwidth of a port-channel interface is equal to the sum of its active member links. For example, an EtherChannel with three active 100 Mbps members will show a bandwidth of 300 Mbps. Because members can still fail individually, the bandwidth of a port-channel interface can fluctuate without going down.
For more information on EtherChannel bandwidth and spanning tree considerations, see Etherchannel costs and failover.
Fight Lab
The rules of Fight Lab are:
- You do not talk about IOS licensing.
- YOU DO NOT TALK ABOUT IOS LICENSING.
- If someone yells "stop," goes limp, or taps out, the lab is over.
- Only two guys (or girls) to a pod.
- One lab a time.
- No formatting, no deletions.
- Labs will go on as long as they have to.
- If this is your first lab, you have to
write erase&reload.
(For those who don't get the reference, watch this.)
Have a good weekend!
Review of the Opengear CM4116
For years, I've wanted to put together a collection of lab hardware for public use, but had many technical obstacles to overcome. Many people starting out in networking have grown accustomed to deploying old Cisco 2511 routers as access servers for labs. While these might suffice for an individual, they're hardly a robust solution and simply unfit for a managed lab. For serious console access over IP, I needed something more.
It wasn't until I came across a line of console servers produced by Opengear that a free community lab became a real possibility. With Opengear's help, the community lab I had envisioned quickly became a reality. Many readers have asked for a more in-depth explanation of how access to the lab is managed, so here it is.
The Opengear CM4116
The heart of the lab is an Opengear CM4116.
This is a solid-state, ultra-low-power 1U box with 16 RS-232 serial ports (the CM4000 line also offers port densities of 1, 8, and 48). Each port can be connected to an out-of-band console interface of various hardware, such as the console or auxiliary ports on most Cisco hardware. The box itself is attached to an Ethernet LAN and provides connectivity to the serial ports through a variety of means, such as Telnet or SSH.
The box runs a custom-built lightweight Linux operating system, which is available without a software license and even customizable through Opengear's custom development kit (CDK). It can be managed both through console and an HTTPS interface as pictured below.
Serial Port Configuration
Anyone who has used HyperTerminal or a similar terminal emulator before will find console port configuration very familiar.
Beside typical settings like baud rate and flow control, each port can be configured independently to function in one of several modes:
- Console Server - Provides access to the serial port over IP via Telnet, SSH, raw TCP, and/or RFC 2217 bridging
- SDT - Secure tunneling through Opengear's SDT Connector software (Java-based)
- Terminal Server - Enables TTY login for a local terminal
- Serial Bridge - Connect two serial endpoints over IP using RFC 2217
In console server mode, ports can be independently configured for allowed protocol, logging level, syslog facility, and other parameters. Optionally, the entire serial stream of a port can be exported to a remote server via syslog.
Console access is achieved by connecting via Telnet or SSH on the TCP port for a given serial port. User authentication is provided either locally, by a centralized RADIUS, TACACS+, or LDAP server, or by a combination thereof.
$ telnet 192.168.20.2 2003 Trying 192.168.20.2... Connected to 192.168.20.2. Escape character is '^]'. login: root Password: R3# R3#
Power Management
One especially handy feature is inline power management utilizing SNMP-controlled UPS or RPC devices. First, an UPS or RPC device is configured and its available outlets automatically discovered.
Next, the administrator creates a managed device, which is essentially a mapping of serial port to UPS/RPC outlet.
When power control is enabled under the serial port configuration, a logged-in user can then manipulate the power outlet of the device he's consoled into directly from the console:
R3# ~p Power Commands: O - Power ON P - Power OFF R - Power cycle off then on again s - Show current power status . - Exit power menu ? - Show this message [R3] Power > R Cycling power ... Connection 1: Unknown [R3] Power > . System Bootstrap, Version 12.3(8r)T9, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 2004 by cisco Systems, Inc. PLD version 0x10 GIO ASIC version 0x127 c1841 processor with 262144 Kbytes of main memory Main memory is configured to 64 bit mode with parity disabled ...
This is a critical feature, allowing remote users to perform hard reboots for tasks like password recovery.
Console Pattern Matching and Alerts
Opengear provides a very elegant solution for what is, in my opinion, the most daunting concern for anyone running a multi-user lab: How do you grant a newbie full control over a device, yet protect the device from accidental software erasures and the like?
The CM4116 software allows for pattern matching against the input and output serial streams of each port. With just a rudimentary understanding of regular expressions, an administrator can define an alert to look for certain strings and perform a variety of actions.
For example, I have defined a number of alerts on the lab's CM4116 to protect against corruption or deletion of the IOS and ASA software images, or formatting of the Flash filesystems. These simple alerts have already saved me hours of having to xmodem a new software image onto corrupted devices.
Here is an example of such an alert in action:
R3# format flash: Format operation may take a while. Continue? [confirm]^C R3# R3# R3# ABUSIVE COMMAND DETECTED on port03 R3# R3#Connection closed by foreign host. $
When a specific output from the device is detected, the alert fires and executes a custom script. In this case, the script has injected a control character (ctrl-c) to cancel the command, printed an error message, and kicked off the user. Additionally, it has notified the administrator of the event by email. Note that this is simply what I've chosen to do; with a little knowledge of bash scripting, you can make an alert do just about anything.
Management via Console
Hardcore engineers know never to rely solely on a graphical interface for systems management, and the folks at Opengear are well aware of this maxim. Unmitigated root access to the console server is available via Telnet or SSH. The config utility is provided for easy inspection and manipulation of configuration parameters.
# config -g config.ports.port5.speed config.ports.port5.speed 9600 # config -s config.ports.port5.parity=None # config -g config.ports.port5.parity config.ports.port5.parity None
Coupled with remote command execution via SSH, config makes automated changes a snap.
Final Thoughts
I have been thoroughly pleased with the capabilities of this console server. I have no doubt that without it, I would still be searching for a lab access solution. Opengear's CM4000 series is an ideal solution for both critical out-of-band console access and robust lab management.
BGP peer templates
When Cisco introduced peer groups for BGP neighbors, their intention was to associate neighbors which shared routing policies in an effort to optimize CPU utilization. A side effect of peer-group configuration is reduced syntax. For example, consider the following verbose configuration:
neighbor 192.168.0.1 remote-as 100 neighbor 192.168.0.1 ttl-security hops 1 neighbor 192.168.0.1 timers 30 300 neighbor 192.168.0.2 remote-as 100 neighbor 192.168.0.2 ttl-security hops 1 neighbor 192.168.0.2 timers 30 300 neighbor 192.168.0.3 remote-as 100 neighbor 192.168.0.3 ttl-security hops 1 neighbor 192.168.0.3 timers 30 300 neighbor 192.168.0.4 remote-as 100 neighbor 192.168.0.4 ttl-security hops 1 neighbor 192.168.0.4 timers 30 300
These twelve lines become only eight after implementing a peer group, removing much redundancy from the original configuration:
neighbor MyGroup peer-group neighbor MyGroup remote-as 100 neighbor MyGroup ttl-security hops 1 neighbor MyGroup timers 30 300 neighbor 192.168.0.1 peer-group MyGroup neighbor 192.168.0.2 peer-group MyGroup neighbor 192.168.0.3 peer-group MyGroup neighbor 192.168.0.4 peer-group MyGroup
Unfortunately, because simplified syntax was never the primary goal of peer groups, they can still be rather unwieldy when attempting to configure neighbors with similar, but not identical, routing policies.
In IOS 12.0(24)S, Cisco introduced dynamic update peer groups, a feature which essentially enables the software to automatically group BGP neighbors into peer groups and generate update messages accordingly. Although this new feature effectively obsoleted manually defined peer groups, they have stuck around as many administrators appreciate the convenience they offer in configuration.
Around the same time dynamic update peer groups were introduced, Cisco also debuted BGP peer templates. With the burden of CPU optimization delegated to dynamic update peer groups, peer templates introduced a much more flexible, hierarchical peer configuration scheme. There are two types of peer templates: session templates and policy templates.
Session templates affect the actual BGP session with a neighboring router, whereas policy templates affect protocol-specific (NLRI) policy (e.g. IPv4 versus IPv6). The following table lists which parameters are defined in each type of template (as of IOS 12.4T):
| Session Templates | Policy Templates |
|
|
To illustrate how peer templates work, consider the following peer group configuration:
router bgp 65200 no synchronization bgp router-id 10.0.0.3 bgp log-neighbor-changes neighbor IBGP-Peers peer-group neighbor IBGP-Peers remote-as 65200 neighbor IBGP-Peers timers 30 300 neighbor EBGP-Peers peer-group neighbor EBGP-Peers ttl-security hops 1 neighbor EBGP-Peers timers 30 300 neighbor 10.0.1.1 remote-as 65101 neighbor 10.0.1.1 peer-group EBGP-Peers neighbor 10.0.1.2 remote-as 65102 neighbor 10.0.1.2 peer-group EBGP-Peers neighbor 10.0.2.4 peer-group IBGP-Peers neighbor 10.0.2.5 peer-group IBGP-Peers no auto-summary
Two peer groups have been created: one for IBGP neighbors, and one for EBGP neighbors. Each group defines some unique session characteristics, but they both also have one in common (the BGP timers configuration). Because of the way peer groups work (again, they were originally intended only for CPU optimization), common attributes must be replicated across peer groups, introducing redundancy in the configuration.
Peer templates embrace a hierarchical approach to combat such redundancy. We can create one template for session parameters common to all BGP neighbors, and then create more-specific templates which inherit those parameters. Templates are created under the BGP routing process:
R3(config)# router bgp 65200 R3(config-router)# template ? peer-policy Template configuration for policy parameters peer-session Template configuration for session parameters R3(config-router)# template peer-session BGP-All R3(config-router-stmp)# timers 30 300 R3(config-router-stmp)# exit-peer-session R3(config-router)#
The BGP-All template holds the timers configuration line we want to apply to all peers. Next we'll create separate IBGP and EBGP templates, both of which will inherit parameters from the BGP-All template using the inherit peer-session command.
The completed configuration looks like this:
router bgp 65200 template peer-session BGP-All timers 30 300 exit-peer-session ! template peer-session IBGP remote-as 65200 inherit peer-session BGP-All exit-peer-session ! template peer-session EBGP ttl-security hops 1 inherit peer-session BGP-All exit-peer-session ! no synchronization bgp router-id 10.0.0.3 bgp log-neighbor-changes neighbor 10.0.1.1 remote-as 65101 neighbor 10.0.1.1 inherit peer-session EBGP neighbor 10.0.1.2 remote-as 65102 neighbor 10.0.1.2 inherit peer-session EBGP neighbor 10.0.2.4 inherit peer-session IBGP neighbor 10.0.2.5 inherit peer-session IBGP no auto-summary
Admittedly, with only four neighbors and only two significant classifications (EBGP and IBGP), the improvement might not seem all that drastic. But consider the efficiency afforded when configuring dozens of BGP peers in a similar matter.
The above example demonstrates peer session templates at work. As you might have guessed, peer policy templates work very similarly:
R3(config-router)# template peer-policy BGP-All R3(config-router-ptmp)# prefix-list DENY-MARTIANS in R3(config-router-ptmp)# exit-peer-policy R3(config-router)# neighbor 10.0.1.1 inherit peer-policy BGP-All
Policy template inheritance works the same way, but with the inherit peer-policy command.
Finally, the show ip bgp template command can be used to verify template inheritance:
R3# show ip bgp template peer-session Template:BGP-All, index:1 Local policies:0x20, Inherited polices:0x0 *Inherited by Template IBGP, index= 2 *Inherited by Template EBGP, index= 3 Locally configured session commands: timers 30 300 Inherited session commands: Template:IBGP, index:2 Local policies:0x1, Inherited polices:0x20 This template inherits: BGP-All index:1 flags:0x0 Locally configured session commands: remote-as 65200 Inherited session commands: timers 30 300 Template:EBGP, index:3 Local policies:0x800, Inherited polices:0x20 This template inherits: BGP-All index:1 flags:0x0 Locally configured session commands: ttl-security hops 1 Inherited session commands: timers 30 300 R3# show ip bgp template peer-policy Template:BGP-All, index:1. Local policies:0x40, Inherited polices:0x0 Locally configured policies: prefix-list DENY-MARTIANS in Inherited policies:
Understanding NAT address types
My first networking job was an airman in the US Air Force. Having been deepy involved with early Internet development, the US military owns significant chunks of the IPv4 address space. As such, network address translation (NAT) is often unnecessary on DoD-owned networks. While this made for convenient design, it prevented me from gaining vital real-world experience with NAT until later on in my career.
When first studying NAT, I remember being most confused by the addressing terminology. An IP address as related to NAT falls into one of four categories, as seen in the output of show ip nat translations on IOS:
- Inside global
- Inside local
- Outside local
- Outside global
None of the explanations I read in books at the time settled well in my mind, until I was able to grasp a key concept: there are two attributes of each address in play here: location and perspective.
Location is described by the first word in the tuple, either inside or outside. It refers to the "side" of the NAT boundary router in which the address logically exists. In a typical NAT deployment, inside addresses will usually (but not necessarily) be private RFC 1918 addresses, and outside addresses will usually be globally routable (registered) IP addresses.
Perspective refers to the side of the NAT boundary from which the address is observed, either local or global. If an address is seen by an inside host, it is being observed locally. If an address is seen by an outside host, it is observed globally.
A practical example should help clarify this distinction. To begin with, consider a simple one-to-one static NAT mapping configured on R2 (no layer four port translation is involved in this example).
interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.252 ip nat outside ! interface FastEthernet0/1 ip address 192.168.0.1 255.255.255.0 ip nat inside ! ip nat inside source static 192.168.0.10 192.0.2.10
This static mapping creates a simple NAT translation rule:
R2# show ip nat translations Pro Inside global Inside local Outside local Outside global --- 192.0.2.10 192.168.0.10 --- ---
Note that only the first two address classes have entries. This is because no stateful session is being tracked, and thus there is only one address, the inside address. The entry describes both the global and local perspectives of a single inside address.
To summarize:
- Inside global: The address of the inside host as seen from the outside
- Inside local: The address of the inside host as seen from the inside
If we initiate a TCP session from R1 to R3, we can see that a second, temporary NAT translation is created, this time with all four classes populated with an address:
R2# show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 192.0.2.10:23 192.168.0.10:23 10.0.0.2:32978 10.0.0.2:32978 --- 192.0.2.10 192.168.0.10 --- ---
The meanings of the first two columns are the same as with our static entry; they describe the globally- and locally-significant addresses of the inside host. The second two columns note the locally- and globally-significant addresses of the outside host. The two addresses of the outside address are identical, as global addresses are not being translated between sides of the NAT boundary.
To review:
- Inside global: The address of the inside host as seen from the outside
- Inside local: The address of the inside host as seen from the inside
- Outside local: The address of the outside host as seen from the inside
- Outside global: The address of the outside host as seen from the outside
Routing table profiling
As of 12.0, Cisco IOS routers include a little-known feature to aid in tracking changes to the routing table: ip route profile. Here we examine how this feature offers an indicator of the network's stability.
The routing table of any router in the above topology is predictable:
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 6 subnets
C 10.0.10.0 is directly connected, Loopback0
C 10.0.12.0 is directly connected, FastEthernet0/0
C 10.0.13.0 is directly connected, FastEthernet0/1
O 10.0.30.0 [110/11] via 10.0.13.3, 00:00:03, FastEthernet0/1
O 10.0.23.0 [110/20] via 10.0.13.3, 00:00:03, FastEthernet0/1
[110/20] via 10.0.12.2, 00:00:03, FastEthernet0/0
O IA 10.0.20.0 [110/11] via 10.0.12.2, 00:00:03, FastEthernet0/0
First we need to enable route profiling:
R1# show ip route profile IP routing profile not enabled R1# conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)# ip route profile R1(config)# ^Z R1# show ip route profile IP routing table change statistics: Frequency of changes in a 5 second sampling interval ------------------------------------------------------------- Change/ Fwd-path Prefix Nexthop Pathcount Prefix interval change add change change refresh ------------------------------------------------------------- 0 0 0 0 0 0 1 0 0 0 0 0 2 0 0 0 0 0 3 0 0 0 0 0 4 0 0 0 0 0 5 0 0 0 0 0 10 0 0 0 0 0 15 0 0 0 0 0 20 0 0 0 0 0 25 0 0 0 0 0 30 0 0 0 0 0 55 0 0 0 0 0 80 0 0 0 0 0 105 0 0 0 0 0 130 0 0 0 0 0 155 0 0 0 0 0 280 0 0 0 0 0 405 0 0 0 0 0 530 0 0 0 0 0 655 0 0 0 0 0 780 0 0 0 0 0 1405 0 0 0 0 0 2030 0 0 0 0 0 2655 0 0 0 0 0 3280 0 0 0 0 0 3905 0 0 0 0 0 7030 0 0 0 0 0 10155 0 0 0 0 0 13280 0 0 0 0 0 Overflow 0 0 0 0 0
Route profiling works by inspecting the routing table every five seconds. Changes to routes between inspections are categorized into one or more of the five rightmost columns and their frequency is noted by row according to the leftmost column. For example, a value of 3 in the 2 row of the prefix refresh means that there were three five-second intervals during which two prefix refreshes occurred.
Yes, it's a bit confusing.
Before we dig any further, a description of each of the event columns (as described in the documentation) may be helpful:
- Forward-Path Change - This statistic is the number of changes in the forwarding path, which is the accumulation of prefix-add, next-hop change, and pathcount change statistics.
- Prefix-Add - A new prefix was added to the routing table.
- Next-Hop Change - A prefix is not added or removed, but the next hop changes. This statistic is only seen with recursive routes that are installed in the routing table.
- Pathcount Change - The number of paths in the routing table has changed. This statistic is the result of an increase in the number of paths for an Interior Gateway Protocol (IGP) prefix in the routing table.
- Prefix Refresh - Standard routing table maintenance; the forwarding behavior is not changed.
Of course, the table is empty immediately after enabling route profiling. After a few minutes, however, we begin to notice significant values:
R1# show ip route profile IP routing table change statistics: Frequency of changes in a 5 second sampling interval ------------------------------------------------------------- Change/ Fwd-path Prefix Nexthop Pathcount Prefix interval change add change change refresh ------------------------------------------------------------- 0 96 96 96 96 96 1 0 0 0 0 0 2 0 0 0 0 0 3 0 0 0 0 0 4 0 0 0 0 0 5 0 0 0 0 0 10 0 0 0 0 0 15 0 0 0 0 0 20 0 0 0 0 0 25 0 0 0 0 0 30 0 0 0 0 0 55 0 0 0 0 0 80 0 0 0 0 0 105 0 0 0 0 0 130 0 0 0 0 0 155 0 0 0 0 0 280 0 0 0 0 0 405 0 0 0 0 0 530 0 0 0 0 0 655 0 0 0 0 0 780 0 0 0 0 0 1405 0 0 0 0 0 2030 0 0 0 0 0 2655 0 0 0 0 0 3280 0 0 0 0 0 3905 0 0 0 0 0 7030 0 0 0 0 0 10155 0 0 0 0 0 13280 0 0 0 0 0 Overflow 0 0 0 0 0
We can see that all five events have a value of 96 in the 0 row. This tells us two things: first, route profiling has been enabled for the last 8 minutes (96 * 5 seconds per interval = 480 seconds / 60 = 8 minutes). Second, since all columns only have an entry in the 0 row, this tells us that no changes have occurred; in other words, the routing table has remained stable.
But stability is boring, so let's force a change. Assume R2 loses its connection to the 10.0.23.0/30 network. This will be reflected as a change in the next update of the profile:
R1# show ip route profile IP routing table change statistics: Frequency of changes in a 5 second sampling interval ------------------------------------------------------------- Change/ Fwd-path Prefix Nexthop Pathcount Prefix interval change add change change refresh ------------------------------------------------------------- 0 172 172 173 173 173 1 1 1 0 0 0 2 0 0 0 0 0 3 0 0 0 0 0 4 0 0 0 0 0 5 0 0 0 0 0 10 0 0 0 0 0 15 0 0 0 0 0 20 0 0 0 0 0 25 0 0 0 0 0 30 0 0 0 0 0 55 0 0 0 0 0 80 0 0 0 0 0 105 0 0 0 0 0 130 0 0 0 0 0 155 0 0 0 0 0 280 0 0 0 0 0 405 0 0 0 0 0 530 0 0 0 0 0 655 0 0 0 0 0 780 0 0 0 0 0 1405 0 0 0 0 0 2030 0 0 0 0 0 2655 0 0 0 0 0 3280 0 0 0 0 0 3905 0 0 0 0 0 7030 0 0 0 0 0 10155 0 0 0 0 0 13280 0 0 0 0 0 Overflow 0 0 0 0 0
At this point, there have been:
- 172 intervals where no forward-path changes have occurred,
- 1 interval where a single forward-path change has occurred,
- and 0 intervals where any other number of forward-path changes have occurred.
The same is true for prefix additions. The other three event categories remain unaffected (all 173 intervals detected 0 changes applicable to those categories).
If two such events were detected within the interval, 1 would appear in the 2 row of both columns instead. Likewise, if ten such events were detected within the interval, the 10 row would be incremented instead.
When R2's link is restored, we see the second event reflected in the profile:
R1# show ip route profile IP routing table change statistics: Frequency of changes in a 5 second sampling interval ------------------------------------------------------------- Change/ Fwd-path Prefix Nexthop Pathcount Prefix interval change add change change refresh ------------------------------------------------------------- 0 238 239 240 239 239 1 2 1 0 1 1 2 0 0 0 0 0 3 0 0 0 0 0 4 0 0 0 0 0 5 0 0 0 0 0 10 0 0 0 0 0 15 0 0 0 0 0 20 0 0 0 0 0 25 0 0 0 0 0 30 0 0 0 0 0 55 0 0 0 0 0 80 0 0 0 0 0 105 0 0 0 0 0 130 0 0 0 0 0 155 0 0 0 0 0 280 0 0 0 0 0 405 0 0 0 0 0 530 0 0 0 0 0 655 0 0 0 0 0 780 0 0 0 0 0 1405 0 0 0 0 0 2030 0 0 0 0 0 2655 0 0 0 0 0 3280 0 0 0 0 0 3905 0 0 0 0 0 7030 0 0 0 0 0 10155 0 0 0 0 0 13280 0 0 0 0 0 Overflow 0 0 0 0 0
By now you've no doubt deduced that lower values (except the 0 row) indicate a more-stable routing table. This feature probably isn't ideal for enterprise-wide network management, but might come in handy when attempting to detect sporadic and/or short-lived fluctuations in the topology during troubleshooting.
Learn the phonetic alphabet
How often have you been on one end of a telephone conversation that went like this?
A: "Okay, give me the MAC address." B: "Zero zero, zero two, six bee--" A: "Six what?" B: "Bee." A: "Bee?" B: "No, bee!" A: "Dee?" B: "Yeah. Six bee, four dee--" A: "Four bee?"
...and so on. Many letters and sounds are easily confused over telephone conversations or distorted by background noise. It is subsequently worthwhile to every IT professional to memorize the NATO phonetic alphabet to better communicate fragile sounds.
The phonetic alphabet is a mapping of individual letters and numbers to specially chosen words which are unlikely to be mistaken for one another (for instance, none of the words in the phonetic alphabet rhyme). By substituting the NATO alphabet telephony for independent letters and numbers, you can ensure other parties (who also grasp the idea of the phonetic alphabet) can reliably interpret your communication. And you can avoid sounding like a character on a Saturday morning children's show, repeating, "A as in apple, B as in ball..."
NATO Phonetic Alphabet
| Character | Telephony | Character | Telephony |
| A | Alpha | S | Sierra |
| B | Bravo | T | Tango |
| C | Charlie | U | Uniform |
| D | Delta | V | Victor |
| E | Echo | W | Whiskey |
| F | Foxtrot | X | Xray |
| G | Golf | Y | Yankee |
| H | Hotel | Z | Zulu |
| I | India | 0 | Zero |
| J | Juliet | 1 | One |
| K | Kilo | 2 | Two |
| L | Lima | 3 | Three |
| M | Mike | 4 | Four |
| N | November | 5 | Five |
| O | Oscar | 6 | Six |
| P | Papa | 7 | Seven |
| Q | Quebec | 8 | Eight |
| R | Romeo | 9 | Niner |
