Blog Posts in February 2008
Building Customer-Resilient BGP networks
When Kate Gerwig, my wonderful editor from SearchTelecom.com, and myself agreed on the contents of the “Building customer-resilient BGP networks” article, we had no idea that it would become extremely relevant just days before it was published. The article describes the tools a Service Provider should use to ensure that its customers cannot harm its BGP routing data (and consequently its other customers and the Internet at large).
On February 24th, someone in Pakistan decided to block local access to YouTube … and someone else decided that the best way to approach the problem was to block the whole world’s access to YouTube.
Unconditional trunking port on a Catalyst 3560
Rob van Ooijen has sent me a really interesting question:
I've configured a switch port to be unconditionally a trunk with the switchport mode trunk configuration command. However, when the interface was enabled, I've got a dynamic trap indicating the trunking was still dynamic (and the show commands also showed negotiation of trunking is enabled).
In fact, adjacent layer-2 devices can negotiate a number of things these days, among them:
- Speed and duplex settings (we'll leave this can of worms safely closed);
- Trunking (a port can be access or trunk port);
- Trunk encapsulation (ISL or 802.1q);
With the switchport mode trunk command you just disable the trunking negotiation (the port will never become an access port), but the switch still runs Dynamic Trunking Protocol (DTP) on it, unless you disable DTP with switchport nonegotiate, which (in combination with all the other configuration commands) makes the port configuration totally static. More configuration can be found in Cisco's documentation and in the Basics of DTP document.
This article is part of You've asked for it series.
Merging VTY configurations
line vty 0 2He wanted to merge the three configuration blocks back into a single one but somehow didn't know how to do it.
login
line vty 3
password secret
login
line vty 4
login
To realize what's going on, you have to understand how the IOS generates line configurations. It takes the first line (VTY 0, for example) and generates its configuration. If the next line (VTY 1) has exactly the same configuration, the range of numbers is expanded (becoming VTY 0 1) and so forth until the pool of similar lines is exhausted or a line is found that has at least one parameter different from the starting one, in which case a new block is started. That's why the sample configuration has three blocks (0-2, 3 and 4) even though the first and the third block are identical.
However, if you change the offending parameter, the VTY lines will have identical configurations and will be automatically merged. If you want to be on the safe side, you should change the parameter for all lines, for example:
line vty 0 4
login
password secret
Note: This article is part of You've asked for it series.
Reduce IP addressing errors in lab environment
hostname Core-2… and use IPCP negotiation on the POP router to pick up the WAN IP address:
!
interface Serial1/0
description link to POP
ip address 10.0.2.1 255.255.255.252
encapsulation ppp
peer default ip address 10.0.2.2
hostname POP
!
interface Serial1/0
description link to Core-1
ip address negotiated
encapsulation ppp
You should not configure no peer neighbor-route on the router that gets dynamic IP address, as the subnet mask is not assigned with IPCP; you need the IPCP-generated host routes if you want to do hop-by-hop telnet between the routers.
Time-based BGP policy routing
He uses BGP communities to achieve the switch (perfect solution if your ISP supports them) and time-based ACL in a route-map to set the community based on time-of-day. As Cisco changed the way BGP imports local routes in IOS release 12.3T, he then devises an ingenious solution based on reliable static routing to trigger a change in the IP routing table.
The optimum solution is way simpler: you just configure two EEM applets to perform clear ip route network command at appropriate times.
Environment variables set by EEM applet action commands
“Cisco IOS Hints” blog featured in NetworkWorld
It's well worth browsing through the list. I already had most of these sites in my feed reader and I've discovered a few new nuggets.
Use all the tools you have
For example, an Internet Service Provider might want to filter incoming updates received from the customers to ensure they’re not advertising transit routes and advertise only IP prefixes they actually own. Inbound route maps might also be needed to attach BGP communities to inbound routes or set BGP attributes (for example, local preference) based on communities attached to incoming routing updates.
You can perform all these tasks with route-maps, but then you’d probably have to create a dedicated route-map for each customer (as the inbound prefix filter has to be customer-specific). Changing your routing policies or community definitions would require changing a lot of route maps.
Update 21-feb-08@15:39: distribute lists and prefix lists can't coexist (they cannot be configured in the same direction on the same neighbor)
On the other hand, if you use all the filters available in the BGP routing process, you could:- Use neighbor filter-list in to check the customer-specific AS path requirements;
- Use neighbor prefix-list in to filter customer prefixes, reject too long prefixes or prefixes not belonging to the customer;
- Use neighbor route-map in to drop prefixes belonging to your own address space, implement various routing policies and set BGP communities.
The solution scales even better if you configure common filters (route-map in and filter-list in in our scenario) in a BGP peer session template.
Differentiating between port scanners and legitimate users
“Is there a way to have a port on a router open for legitimate use while closed to port scanning software and the such. For example. I have SSL VPN configured on my IOS router. Is it possible to have the port seem stealthed to port scanners while still allowing legitimate access to the service? An example being, allowing a web browser to connect using the port but making sure that a port scanner doesn't detect it as open.”The short answer is no, unless you can differentiate legitimate users by their IP addresses. The port scanners (when using SYN scan) simply open and close a TCP session, and there is no way for a router to differentiate between the legitimate users (who would send valid HTTP GET requests) and port scanners (that would close the session as soon as it's established).
If you can distinguish between legitimate users and everyone else based on their IP address, the task becomes simpler: either you apply inbound access list on Internet-facing interface of the router or configure per-service access-list (for example, ip http access-class acl). When using the inbound access-list, the port appears filtered or stealth, when configuring per-service access-class, it's reported as closed.
Remove unwanted PPP peer route
Implement “wc -l” in Cisco IOS
First you have to define the wc Tcl procedure:
proc wc { cmd } { llength [split [exec $cmd] "\n" ] }You can define the procedure interactively in Tclsh (but then you have to do it every time you start Tclsh) or you could store the code in a flash file and execute the file every time the Tclsh is started with the scripting tcl init filename global configuration command.
Once the wc procedure is defined, execute wc { IOS command } in Tclsh and you'll get the line count. For example, to get the number of directly connected routes use
wc { show ip route ¦ include ^C }
The include ^C filter includes all lines that start with letter C; in our case all directly connected routes
Obviously you could turn this idea into a full-blown Tclsh script that would accept CLI arguments … but I'll leave this as an exercise for the readers (you can probably tell I've been reading some academic literature lately :). However, if you find the time to write a more complete wc implementation on IOS, please do post the URL here.
Common Sense Prevails Over RFC 2328
When trying to extract the OSPF route selection rules from RFC 2328, I've stumbled across a very weird rule (section 16.4.1): if an ASBR within a non-backbone area advertises an external route (or if the forwarding address is within the non-backbone area), it's preferred over external routes advertised by ASBRs in other areas regardless of its metric. I simply had to test this on Cisco IOS … and found out that Cisco engineers prefer common sense to OSPF RFC.
AS-path Based Filter of Customer BGP Routes
Any serious (or at least security-aware) ISP should not blindly accept BGP routes from its customers but at the very minimum do some sanity checks on them. For example, if a multi-homed customer is clumsy enough to advertise BGP routes between service providers, it’s nice if you still stop him from turning into a transit AS. The required filter is conceptually quite simple: all the BGP routes from the customer should contain only his AS number in the AS-path.
The initial non-scalable approach is obvious: accept only the AS paths that have exactly the customer’s AS number in the AS path. For example, if your customer’s AS number is 65001, you could use this filter: ip as-path access-list 100 permit ^65001$.
Configure OSPF on Unnumbered Interfaces
When we’ve been assigning router interfaces in OSPF areas with the network router configuration command, it was impossible to start OSPF only on some unnumbered interfaces and not on others (or place the unnumbered interfaces in different areas). These restrictions are removed if you use the ip ospf area interface configuration command.
Fix bugs in EEM action cli implementation
BGP Essentials: AS-path Prepending
Enterprise networks primarily use BGP with their Internet Service Providers if they want to be multi-homed (connected to more than one ISP). A very common requirement in a multi-homed design is the primary/backup setup where the lower speed (or sometimes lower quality) link should only be used when the primary link fails.
Competent ISPs help their customers reach this goal by using BGP local preference within their network and giving the customers the ability to indicate the desired value of BGP local preference through BGP communities: if the route received directly from the customer has low local preference, all other routes are preferred, resulting in the desired traffic flow that avoids the backup link if at all possible as shown in the next diagram:
Interesting QoS problem on Catalyst 3750
Mohammad Faraz Rehan has encountered an interesting problem when using IP access-list based class/policy maps on Catalyst 3750:
When I try to apply the same service-policy to more than 15 interfaces, the configuration command fails and the switch generates the following syslog message:
%QOSMGR-4-POLICER_PLATFORM_NOT_SUPPORTED: Policer configuration has exceeded hardware limitation for policymap …
I've tried to help him with various TCAM-related information and in the end he found an interesting solution to the problem:
It looks like there is a limit related to using the same access-list/class-map/policy-map on multiple interfaces.
The first time I was applying the same policy-map (19 classes/19 ACLs/46 ACL lines) on all interfaces, but the switch would not accept it on more than 15 interfaces. Another test scenario had 18 classes/18 ACLs/52 ACL entries and the same policy-map would only work on 13 interfaces.
Now we implemented 24 different policy-maps, class-maps and ACLs remained the same, and the switch is happy.
Use Slow IGP Startup in LDP-only MPLS Environments
If you use LDP-based MPLS as the only means of transporting data across your network core (for example, in MPLS VPN networks or in BGP-free ISP core), a router startup might disrupt your Label Switched Paths (remember: they are always based on IGP best paths) leading to a temporary disruption in service.
For example, when the router P1 in the network shown in the following diagram is powered on, and its IGP advertises its presence, the IGP-derived path from PE1 to PE2 will go over P1. If the LDP on P1 has not exchanged labels with PE1 and PE2, there will be no LSP on the shortest path between PE1 and PE2, resulting in a loss of traffic until the labels are exchanged and LSP is built.
BGP Essentials: BGP Communities
BGP communities are extra attributes you can attach to an IP route carried by BGP. You can use communities to indicate which routes should be propagated or filtered (for example, the well-known NO_EXPORT community signifies that the route it’s attached to shall not be sent outside of the local AS), to influence route selection on remote routers or to trigger other BGP-dependent IOS features (for example, quality-of-service marking based on BGP).
Each BGP community is a 32-bit value. The best practice dictates that the top 16 bits should be the AS number of the network defining the community meaning and the bottom 16 bits are defined by the network administrator.