Did you want to use private IP addresses in a public network? The short recommendation is: “don't”. If you use them in the network core, your customers might have problems with network troubleshooting; if you assign them to your customers and use NAT or PAT, you've just created serious security issues. You can find more details in the Avoiding private IP security risks in public networks article I wrote for SearchTelecom.com.
Shahid has sent me an interesting observation: he was running RIP in partially-meshed Frame Relay network and wanted to use static host routes to fix next-hop problems, but somehow they didn't work as expected. I ran a series of scenarios testing RIP, OSPF, EIGRP and BGP and found that some of the old tricks don't work any more. Furthermore, it's almost impossible to run RIP over partially-meshed NBMA network, as the default RIP next-hop processing messes up your routing table. The details are explained in the Next-hop fixup in partially-meshed NBMA networks article in the CT3 wiki.
Whenever I start digging into technical details, I learn something new. A few days ago I've stumbled across the term anycast, which is a very interesting way to solve scalability issues:
A while ago I’ve read a post about the potential Internet meltdown by Michael Morris. He provided an amazingly accurate analysis of the facts … and ended with a wrong conclusion. To understand the whole issue, please thoroughly read his text in its entirety before proceeding.
Back? OK. As I said, his analysis was great, but the conclusions were wrong. Regardless of whether we use IPv4 (and advertise smaller and smaller prefixes) or IPv6, the problem is the same: everyone wants to have chunks of non-aggregatable provider-independent public address space (so you can freely move between Service Providers) and everyone advertises these PI prefixes to multiple service providers (because multihoming is so cheap these days). Even networks that are not multihomed today use their own PI address space and private AS numbers to connect to a single ISP, so they could get multi-homed in a second if they feel like it.
The growth of the Internet routing tables thus has nothing to do with the prefix sizes and version of IP, but with the requirements of the end-customers to have immediate capability to switch service providers at will. As long as this trend persists (and I cannot see it stopping, as Internet is considered a commodity these days), the routing tables will grow, regardless of whether we use IPv4 or IPv6 or CLNS or something not invented yet.
If you want to deploy high-availability public servers within your network, you should implement proper multi-homing solution including BGP routing with the Service Providers. If you don't have your own public IP address space and your own AS number, you should try to become multihomed to one ISP (or change your ISP if they don't know what you're talking about). If you want to be multi-homed to two ISPs using techniques similar to the ones I've described in the Small-Site Multi-Homing article, you should be using a hosted service (they're probably cheaper than your time), not your own public server.
But if you still insist (like numerous readers of my articles) to deploy public servers on a site multi-homed via NAT, you'll find the design and implementation guidelines in my latest IP Corner article Servers in Small Site Multi-homing.
This article is part of You've asked for it series.
Our developers have just released the BGP Policy Routing E-Lesson that accompanies the Scalable Policy Routing IP Corner article. The lesson contains an instructor-led presentation that explains the concepts and a remote lab where you configure and test the solution without endangering the operations of your live network.
If you'd like to review the e-lesson and write/blog about it and the concept of short e-learning modules covering very specific technologies or design scenarios, send me a message describing what you'd like to do and I'll organize the access to the e-lesson for you.
I'm positive the IP prefixes reserved for private use by RFC 1918 are well-known to anyone building private IP networks. Likewise, you should be familiar with reserved AS numbers documented in RFC 1930 if you're building private networks running BGP. But if you know there are reserved DNS domains that can be used to write sample configurations and test code, you're smarter than I was a few weeks ago.
I was writing the June IP Corner article and needed to set up DNS servers within the lab. I used example.com as the domain name and decided to check what would happen if you'd visit the actual www.example.com web site (try it out). It politely referenced me to RFC 2606, which documents the reserved domain names you can use.
As a rule, you should use private IP addresses, AS numbers and domain names in all technical documentation you're producing (unless, of course, you're describing an actual network). If you're forced to use public addresses or AS numbers (for example, to illustrate how the neighbor remote-private-as command works), you should clearly state that the AS numbers are imaginary.
The inability of Control Plane host interface to detect inbound OSPF packets (and the flurry of comments that followed my blog post) has prompted Sebastian and myself to search for more documentation and conduct further tests. Sebastian already had a working configuration from which he could infer most of the configuration rules and he also found the well-written Understanding CPPr document on CCO. Together with the tests I ran in my router lab, we're pretty confident the CPPr inbound packet classification rules are (approximately) as follows:
Use the latest 12.4T software (at least 12.4(15)T5) if you want reliable CPPr operation.
The TTL-related rules explain why the router classifies IBGP packets as host packets and EBGP packets as transit packets. As soon as you configure neighbor ebgp-multihop on the router router, inbound EBGP packets become host packets.
Years ago EIGRP and OSPF had strong presence in large enterprise networks, BGP was used solely by Internet Service providers and IS-IS was a rarity (and there were people using Banyan Vines).
The situation has probably changed over the last years, I would (sadly) expect EIGRP to decline and (happily) BGP to grow. Let's figure it out; please respond to this week's readers' poll. Of course you can choose more than one routing protocol.
One of the comments to my Sunday post mentioned RTBH. Obviously I'm not geeky enough, as I had to ask uncle Google for help (but don't worry, I'll work on my geekiness factor :).
The search results produced a few very interesting links, among them a well-structured presentation on RTBH that refers to a paper describing how you can detect remote DoS attacks with the backscatter analysis (assuming the attackers are randomly spoofing source IP addresses).
We've always been trying to minimize asymmetric routing, in both design and implementation phase, as it impacts a number of IP services/features, including:
If “policy routing” reminds you of nightmarish spaghetti solutions of hop-by-hop route-maps, read my latest IP Corner article, Scalable Policy Routing. It describes how you can use a distance vector routing protocol (BGP is used in the article, but you could do the same with EIGRP or even RIP) to solve common policy routing problems in a highly scalable way.
According to the results of the recent “Do you use CLNS?” poll, around 10% of my readers use CLNS in their network, while 36% of them wonder what that acronym stands for.
Let's start with the acronyms. CLNS (Connection-Less Network Service) in combination with CLNP (Connection-Less Network Protocol) is the ISO (International Standards Organization) equivalent to IP.
ISO makes a fine semantic distinction between the service offered to higher layers (CLNS) and the protocol used to implement it (CLNP). There is no such distinction in the IP world.
CLNS (and CLNP) uses long variable-length addresses, making it a viable successor to IPv4. At the time when the IETF community started to design the next-generation IP (before IPv6 appeared on the drawing board), the proposals to use CLNS were taken pretty seriously even though they used interesting acronyms like TUBA (TCP and UDP over Big Addresses) and FOOBAR (FTP Operation Over Big Address Records).Follow the links in the previous paragraph, they point to actual RFCs.
In the end, IETF decided to invent yet another protocol (IPv6), effectively quadrupling the IPv4 address size while retaining most of the benefits and drawbacks of IPv4. If I remember correctly, the technical explanation for this decision was the variable-length of the CLNS addresses (which make the hardware implementation of layer 3 forwarding pretty complex), while one of the real reasons was probably also the "not-invented-here" syndrome (and the lack of total control over a new protocol inherited from another organization).Recently I had to implement Internet access using ADSL as the primary link and ISDN as the backup link. Obviously the most versatile solution would use the techniques described in my IP Corner article Small Site Multi-homing, but the peculiarities of Cisco IOS implementation of the ADSL technology resulted in a much simpler solution.
IOS implementation of PPPoE links uses dialer interfaces. However, the “dialing” on these interfaces is activated as soon as the underlying PPPoE session is active (before the first interesting packet is routed to the interface). When the simulated dial-out occurs, the router starts PPP negotiations including the IPCP handshake, which usually results in an IP address assigned to the dialer interface. Net result: if the dialer interface has an IP address, the PPPoE session is obviously active (and vice versa).
As my ADSL link and the ISDN backup used the same service provider (and very probably the same Radius servers), it made no sense to define additional IP SLA measurements to figure out if the service provider's network is operational; the IP route to the primary dialer interface is installed as soon as the interface is ready to route IP packets. The relevant parts of the router's configuration are included below.
interface FastEthernet0
description outside LAN
no ip address
ip virtual-reassembly
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 3
!
interface BRI0
description ISDN line
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-net3
!
interface Dialer0
description ADSL primary uplink
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
dialer pool 3
!
interface Dialer1
description ISDN backup
ip address negotiated
ip nat outside
dialer pool 1
!
track 100 interface Dialer0 ip routing
delay down 10 up 10
!
ip route 0.0.0.0 0.0.0.0 Dialer0 10 track 100
ip route 0.0.0.0 0.0.0.0 Dialer1 250
In the IP Corner article The Never-Ending Story of IP Fragmentation, I've described the various challenges posed by IP fragmentation in modern IP networks. If you want a more in-depth look at that topic, check the new IP fragmentation e-lesson. It includes a recorded presentation and a remote lab exercise where you can test various fragmentation scenarios, including MPLS VPN backbone, GRE tunnels and GRE+IPSec combination.
E-lessons are subscription-based; you can repeat each module in the lesson (including the lab) as many times as needed.
Cisco has recently published a series of documents describing how you can connect a SOHO site to two ISPs. According to the timestamps on the documents, it took them a few days more than a year to publish a configuration that's almost identical to the one I've described in the IP Corner article “Small-site multihoming” … which can only mean that my configuration was close to optimal :)
Their configuration also includes a nice trick: the ip dhcp client route track number command is a convenient replacement for a static default route with the track option if one of the upstream interfaces uses DHCP and the router generates the default route based on DHCP replies.
Routing protocol redistribution is one of those tough Cisco IOS topics that everyone struggles with sooner or later. To ease your path to mastering the redistribution issues, Petr Lapuhkov wrote two articles: the theory of route redistribution and a simple case study.
When IOS started supporting dynamic allocation of IPCP (IP over PPP) addresses, it also got the mechanism to insert a dynamic host route toward the neighbor's IP address once the IP addresses were negotiated. This mechanism makes perfect sense in dynamic address allocation environments, as the subnet mask is not negotiated with IPCP. Without a host route toward the other end of the PPP link, there would be no easy way to reach the IP prefixes reachable via the PPP link.However, the PPP code got way too aggressive in the recent IOS releases. For example, in the 12.4T train, you get a connected host route toward the IP address of the PPP peer even on a leased line where both addresses are in the same IP subnet. Here's a sample printout from my lab router that illustrates this behavior:
R1#show run interface serial 1/0
Current configuration : 107 bytes
!
interface Serial1/0
ip address 10.1.0.1 255.255.255.252
encapsulation ppp
serial restart-delay 0
end
R1#show ip route 10.1.0.0 255.255.255.252 longer | begin Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.0.2/32 is directly connected, Serial1/0
C 10.1.0.0/30 is directly connected, Serial1/0
To disable the automatic insertion of the connected host route, use the no peer neighbor-route interface configuration command.
You have to clear the IP routing table or flap the interface to remove the PPP-generated host route
I'm often promoting the idea of separating customer routing from core routing in the design articles I write. The only viable solution (unless you want to implement MPLS VPN and migrate customer routing into VPNv4) is to carry customer routes in BGP, redistributing them into BGP from other routing sources. On the other hand, I’m telling you that you should advertise only static IP prefixes into the public Internet. Obviously there’s a seeming disconnect between the two advices.
However, the dilemma is easily solved with the no-export BGP community that prevents an IP prefix from being advertised over EBGP sessions. Whenever you redistribute customer routes into BGP, you should attach the no-export community to them, ensuring that only the statically advertised IP prefixes will be propagated outside of your AS boundaries.
Important: for this design to work, you have to configure BGP community propagation with the neighbor send-community router configuration command on all IBGP sessions in your network, preferably with a peer template. Otherwise, the BGP communities will be lost on IBGP updates and the IP prefixes will leak to your EBGP neighbors.
For example, if you use static routing with your customers and want to redistribute the static routes into BGP, use the following configuration (I’ve used tag 123 to tag static routes that should get inserted into BGP).
router bgp 65001
redistribute static route-map StaticToBGP
!
route-map StaticToBGP permit 10
match tag 123
set community no-export additive
When you configure a static route toward the IP subnet 10.1.2.0/24 …
ip route 10.1.2.0 255.255.255.0 Null0 tag 123
… it’s automatically inserted in the BGP table and marked with the no-export community:
R1#show ip bgp 10.1.2.0
BGP routing table entry for 10.1.2.0/24, version 3
Advertised to update-groups:
1
Local
0.0.0.0 from 0.0.0.0 (10.0.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Community: no-export
If you're looking for more in-depth BGP knowledge, try our Configuring BGP on Cisco Routers e-learning solution. If you just need to enhance your hands-on skill, the BGP Remote Lab Bundle is the perfect choice.
Brian Dennis wrote a long post about the unexpected side effects of the ip default-network command. The Cisco documentation describes the “side effects” but in an even more obscure manner.
What's really happening is this:
In any case, it's an obscure leftover from the classful days that should probably never be used today outside of a CCIE lab.
