Routing Protocols 101 2

[rpast]

Hello all,

I’m sure you’ve heard this one before – but my searches aren’t coming up with anything. It’s a basic question that I’d like to be sure about before going further -- certainly would appreciate any help.

I’m trying to design a failover scheme for a site-to-site vpn in the simplest way – i.e. using an interior routing protocol on the gateway router, instead of BGP, if possible. The basic question is about how interior routing protocols work. I know that they will advertise directly connected subnets. The question is, what determines whether that subnet has ‘failed’?

To illustrate the problem, if I have stub networks at SiteA and SiteB connected over a WAN, both configured for EIGRP, and the network 172.16.30.0 out E0 on SiteB has only one PC connected to it, what will make EIGRP at SiteB conclude that 172.16.30.0 has failed? Must it be the E0 interface itself that has failed? Or can it be the Ethernet cable or NIC on the connected PC?

My guess is that only a malfunction of the router’s E0 interface will cause EIGRP to conclude that the subnet is ‘down’. Because even if the cable and connected PC NIC fails, the router E0 address itself is still in the subnet. So technically, the subnet can still be reached, and EIGRP will advertise this. But I’m not sure.

If the above is true, then my plan to use EIGRP, etc. on the gateway router is foiled. My hope has been to perhaps avoid getting the ISP routers involved at all – instead, just have our own gateway router (terminating a T1, etc.) advertise to others on the inside that it’s directly connected link to the ISP is down, not necessarily because its interface has gone bad, but also when something at the ISP side has gone down. Then, with this information, another interior router can use a floating static route, etc. to direct traffic to a failover Internet link.

Is this off the wall, or is something like BGP the only answer? Thank you very much for any help you can provide.

 

[Jsteve]

The EIGRP routes are calculated by hello messages. This hello protocol works like this:

RouterA---RouterB----RouterC

-Router B knows about both router A&C
- RouterB advertises to RouterC that he knows about a route to router A. If router B does not get the continuous hello messages from router A, it will let router C know that its route to RouterA is dead and Router C will pull that route from its route table.
-This also works the reverse way, Router B lets RouterA know it has a route to routerC

Other Q:
your NIC or ethernet line will not cause any changes to your routing tables. The routing table only cares about routes from router to router, it does no concern it self with LAN segments.

Here are a couple of articles you need to read to help with your decisions.

BGP

http://www.netcraftsmen.net/welcher/papers/bgp1.htm

EIGRP

http://www.cisco.com/warp/public/103/1.html

 

[rpast]

JSteve,

Thank you for your response. In the interest of clarifying for myself, please allow me to explain my current WAN setup, which happens to use EIGRP, but we’ll say it uses RIP, for simplicity. This takes the whole VPN/ISP/Internet components and EIGRP out of the picture for the purpose of illustration.

SiteA (RIP) =====> SiteB (RIP)
E0 (172.16.30.0)

Basically we have frame-relay connecting the SiteA and SiteB routers specified in my previous note(there’s more, but that’s not important). Again, SiteB’s router has a private LAN on E0. On SiteB, I have RIP configured with a "network 172.16.0.0” command, which includes E0. From my CCNA days, I remember that the ‘network’ command will a) broadcast routing updates out E0 (not important), b) process updates as they enter E0 (not important), and c) advertise the subnet directly connected to E0 (IMPORTANT).

SiteA currently receives the route info for 172.16.30.0 from SiteB, because SiteB is advertising that subnet (directly connected to the E0 interface enabled with RIP). Again, referring to CCNA days, there were illustrations of split horizon and routing loops, with examples of a connected subnet failing, thus forcing triggered updates, holddown timers, etc. to force the (SiteB) router to advertise an infinite metric route to the failed subnet (172.16.30.0), telling everyone ‘you can’t get there from here.’

What I’ve never understood is what can make that subnet ‘fail’(it's never actually failed). Is it only the interface card? (for the reasons specified in my last submission). Or stated differently, if the E0 NIC (address 172.16.30.1) is OK, does RIP (IGRP, etc.) consider the 172.16.30.0 subnet ‘reachable’ – and not ‘failed’ – even if the cable attached to E0 and every other device on that subnet has been blown up by a disgruntled employee? (I hope I’m not putting ideas into anyone’s head).

That’s essentially my question. I shouldn’t have mentioned Internet links, fancy IGPs, etc. It’s really a basic routing question. Thank you very much again for taking the time.

 

[pmesjar]

If the interface belonging to the subnet is considered "up, up", then the subnet is considered reachable and included in routing table and outgoing updates. For you that is - as long as your interface E0, configured with IP address 172.16.30.1, is in state "Ethernet 0 is up, line protocol is up", your router will listen for routing updates on it and also advertise Ethernet 0 subnet, 172.16.30.0 (via command network 172.16.0.0) to other routers. When the interface moves to any of the following states:
Ethernet 0 is up, line protocol is down
Ethernet 0 is down, line protocol is down
or you manually shutdown the interface, the subnet associated with this interface is automatically removed from routing table and neighbors are notified about this change.

Jsteve, two BIG corrections:
1.) EIGRP does not calculate routes based on Hello protocol. This protocol is merely for informing whether my neighbor, which I want to exchange routing updates with, is "alive". DUAL calculates routes from topological database.
2.) You are completely wrong in your statement:
"your NIC or ethernet line will not cause any changes to your routing tables"
Advertising of local subnets that a router has direct connections to depend on whether the interface is operational or not.

Peter Mesjar
CCNP, A+ certified
pmesjar@centrum.sk

"The only true wisdom is in knowing you know nothing.

 

[rpast]

Thank you Mr. Mesjar -

I was afraid of that. It looks like I have a new learning curve (BGP) to climb.

 

[Jsteve]

pmesjar,

your correct on both parts but I tried to simplify it for him and not introduce DUAL, hince the link I added.

On the second point, please explain how does a PC nic card causes the router interface to go down?

 

[pmesjar]

On one special occasion, it can - direct connection of PC to router's interface. If the router can't see keepalives anymore, it will put the interface to "Ethernet 0 is up, line protocol is down" state. That is same as if you connect a switch or hub to the router and the port on that switch/hub goes down. This will cause the router no to advertise this subnet anymore.

AnotherTechie I would suggest you first read up something on RIP, EIGRP, OSPF and general routing protocol behaviour (like distance-vector vs link-state routing, classful vs classless routing) before moving to BGP

Peter Mesjar
CCNP, A+ certified
pmesjar@centrum.sk

"The only true wisdom is in knowing you know nothing.

 

[Jsteve]

You have utilized a directly connected PC in production? or is this a lab situation? If you have, what are you using it for?

 

[rpast]

Just got in.— I rushed a thank you note to you last night, Mr. Mesjar, before realizing that there was hope for a non-BGP answer in your reply. Yes, after configuring a T1 on my own gateway router, my biggest challenge may just be getting the ISP to cut off the link to test your solution. Thanks again for your help.

To answer your question Jsteve, no, I don’t have a directly connected PC in production. That scenario was mentioned for illustration. But my actual application involves a comparable situation where my gateway router will have a default next hop configured to an ISP address. I have been assured by the ISP that this is a static mapping that will not change. To my thinking, this is comparable to a 2-NIC subnet, and I can hopefully test Mr. Mesjar’s observations (Ethernet 0 is up, line protocol is down). Thank you.

 

[pmesjar]

Direct PC to router is from lab situation... anyway I was just explaining that also a NIC can be a problem - in special occasion, however... everything is a matter of router seeing keepalives on its interface.

Peter Mesjar
CCNP, A+ certified
pmesjar@centrum.sk

"The only true wisdom is in knowing you know nothing.

 

[baddos]

I would never use an IGP (RIP, OSPF, IGRP, EIGRP, etc) to connect to an ISP. Always use either BGP or static routes.

 

[lgarner]

You could perhaps tunnel an IGP between the VPN endpoints. So, when a link fails on an end point the other will know.

In other words, it makes the endpoints appear to be directly connected so they can share IGP updates.

 

[rpast]

Thanks for your replies. Yes, the EIGRP solution fell short. It might have triggered the other VPN to come up, but it didn’t do much for adjusting default routes, etc. on the other side of the tunnel. As you can see, routing is not my specialty. I did read something about tunneling through GRE. But now I’m running out of time to present an answer to management. BGP apparently has a big price tag. So as it stands, I'll probably just use the VPNs as a failover from frame-relay, still using EIGRP. Don’t think that will be a problem. Otherwise, there’s always manual failover (UGHH)

 

[lgarner]

That'll work (I do it). Set the default route, or high-cost static routes, via the VPN gateway. EIGRP will keep the routes going through the frame while it's up. If it fails, EIGRP will drop the route from the table and you'll fall back to a less-favored route.

I use the GRE tunnel in one case where I prefer the VPN over the frame- our Internet connection is higher bandwidth. Adjusting the delay downward makes the tunnel look better to EIGRP than the frame, unless the tunnel is down.

I also use BGP, but only for backup between two different ISPs.

Either of the first two methods won't cost anything, assuming you've already got the frame-relay and vpn networks in place.

 

[rpast]

OK. Now you’ve got me thinking again. Question: Knowing nothing about GRE, if I assume it does pass updates across the tunnel, couldn’t you use it for an all-VPN (redundant links) WAN too? If updates don’t make it to the other side, both sides know to bring up the alternate route.

The whole deal here is about saving money. A full T1 goes for about $500/mo. now, and a 768K SDSL is about $164/mo. And even when testing the site-to-site VPN with ADSL --- 768K up/ 1.5M down at one side and 384/1.5 at the other ---, performance was at least as good as our FR (384K and 128K pipes). There are downsides, I suppose, relying totally on the Internet, but the $$ really appeal to the honchos, as you know.

I may be missing something. But if auto-failover can be solved without spending $6-$8K per BGP router, not to mention AS numbers, etc., it seems like VPNs are the only way to go.

 

[lgarner]

Yep. There is a little overhead for the encapsulation, but I haven't really noticed it. The GRE tunnel allows two routers which are not connected (and thus can't be EIGRP neighbors) to appear connected through the "tunnel" interface. From there they behave like normal connected routers. Here's part of my setup:

Router-1:
interface Tunnel0
description Main office to remote - GRE Tunnel
bandwidth 1536
ip address 10.0.1.5 255.255.255.252
delay 1000
tunnel source Ethernet3
tunnel destination 10.2.1.1

Router-2:
interface Tunnel0
description Remote office to Main - GRE
bandwidth 1536
ip address 10.0.1.6 255.255.255.252
delay 1000
keepalive 3 2
tunnel source Ethernet0
tunnel destination 10.1.1.1

On both:
router eigrp 1
network 10.0.0.0


The "tunnel destination" is the reachable IP address of the other router via the VPN. The VPN must be working so that the routers can at least see each other. These could be public addresses, but GRE provides only encapsulation, not encryption, so that's not a real good idea.

"tunnel source" is the local interface participating in the tunnel.

The "ip address" is the tunnel address, similar to a frame PVC. The "keepalive" is set to frequently check the remote side to make failover a bit faster. (My main router is too old and doesn't support keepalives on a tunnel i/f).

The "delay" is set low so that the route is preferred. I think the default delay is something like 20000 for a tunnel, making it less attractive than almost everything else.

By the way, I use the "Cisco Cookbook" from O'Reilly a lot. It got me working on this, and is a great problem-solving guide.

 

[rpast]

Hey, thanks a lot. If they give me a green light, I'd really like to try this out. I'll let you know how it goes.

 

[rpast]

Lgarner, looking into this a little further, I see how GRE can provide redundancy for VPNs. But am I correct in concluding, as you indicated earlier (along with everyone else), that BGP is still required for redundancy in Internet links themselves?

If so, do you know of any reasonably inexpensive BGP solution?

Thank you, again, for tolerating these rookie questions.

 

[IllegalOperation]

Quick question. Since you are using VPNs between your links, I am assuming both sites are using actual DIA circuits....instead of point-to-point lines. Correct? Pretty safe assumption, but just want to make sure....

 

[rpast]

As in ‘dedicated internet access’? Yes. DSL currently.

The same links used for vpns are also used for general internet access at each site. The default gateway on the inside router at each site currently points to a particular Pix (which terminates VPN). This is the same router that will create the GRE tunnels.

The GRE tunnels sound great for failing over the vpns. I just wish there were a way for the router to use that information to change the default route too. In other words, when the GRE tunnel fails over, successfully recovering our site-to-site connections, it would be nice if somehow the same inside router might also point to the other Pix (other VPN / Internet link) for a new default gateway.

I'm assuming that when an Internet link goes down, the inside router only knows that its next hop – the Pix -- is OK. There’s no way for it to know anything beyond that, right?