RE: policy based routing and backup [7:71482]
I think the results may depend on the rev of IOS and line card you're running. I did some lab testing with a 2610 running 12.2(4)T6 and it looks like this will work via the route-map (PBR) mechanism. It looks like, in this rev of code, that if the next-hop is not directly connected, then it will drop back to normal L3 forwarding. Further, it looks like if the match is not met, one can avoid the second stage in the route-map. If one falls off the end of the route-map, it looks like standard L3 forward is performed (at least in the testing I did) Below's the route-map I used in my testing: route-map dink permit 10 match ip address 10! access-list 10 permit a.a.a.a log set ip next-hop 192.168.0.14 ! equiv to your T1 interface Here's the message I get when the 192.168.0.14 interface is down or the match for a.a.a.a is not met: 01:57:04: IP: s=192.168.20.2 (Serial1/0), d=192.168.100.14 (Serial1/3), len 100, policy rejected -- normal forwarding Not sure about the verify-availability command. It looks like it requires your ISP to run CDP on the T1 to you. Wouldn't expect that to be typical. One other item you need to be aware of is if your router A is used as transit from a.a.a.a to other internal destinations. COnsider a packet from a.a.a.a going to some destintion c.c.c.c that is reached via some interface on router A. Since the policy gets applied first, the a.a.a.a packets will get forwarded out the T1 interface to the ISP, who will route them back to router A. One could configure all local destinations in the route-map before the test to match for a.a.a.a, but that's a real mess. If you move to VRFs, you should be able to leak your IGP routes into the VRF. [EMAIL PROTECTED] wrote: > > Hi "P", > > > Thanks for taking the time to respond to my email. The way the > network is > setup (right now) is that PBR is setup on the incoming > interface into RtrA > which will only get network traffic from a.a.a.a and never see > any traffic > from the incoming interface belonging to b.b.b.b. > > a.a.a.a is our lab traffic and I would like for it to use a > different T1 > (through RtrA) than what our real network is using which is a > T1 on RtrB. > > I thought about implementing VRFs but I want to make sure that > I cant do it > any other way. > > In regards to the example you gave: > > route-map dink permit 10 > match ip address 10! match the target src IPs > set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1. > ! > route-map dink permit 20 > set ip next-hop 10.100.0.1 ! for all other traffic, route > ! to loopback interface > > I went ahead and tried this. I setup a second route-map and > pointed the > next-hop to the internal loopback interface. I then shut down > the T1 on the > router and enabled debug to see what happend. The "failover" > failed. Here > is what the debug is showing: > > 1d01h: IP: s=a.a.a.a (FastEthernet0/0), d=198.6.1.1, len 92, > FIB policy > match > 1d01h: CEF-IP-POLICY: fib for addr 10.0.0.2 is default; Nexthop > rejected > > So as you can see, the second route-map failed to be used. > When the packet > came in, it matched the first route-map regardless of whether > the next-hop > was reachable or not. > > > What about using the command "ip next-hop > verify-availability". I was > reading up on this feature but I am not sure if I understand > its use. > Perhaps someone can fill me in. > > > > > > Thanks, > > Mario Puras > SoluNet Technical Support > Mailto: [EMAIL PROTECTED] > Direct: (321) 309-1410 > 888.449.5766 (USA) / 888.SOLUNET (Canada) > > > > -Original Message- > From: p b [mailto:[EMAIL PROTECTED] > Sent: Friday, June 27, 2003 2:45 PM > To: [EMAIL PROTECTED] > Subject: RE: policy based routing and backup [7:71482] > > > I'm not sure I understand completely why you want to do > this, and it's been a while since I've dinked with PBR, > but here's some thoughts on one might get this to work. > I've done something similar, but not exactly what's below, > so YMMV. Note, VRFs might fit better and I've listed some > details on a VRF approach below. > > As I recall, one of the issues with PBR is that once > you enable policy routing on an interface, normal L3 > forwarding is completely bypassed.Thus, you can > perform policy for the identified packets, but for any > packets that you want handled "normally", you're hosed > or have to use the hack below. > > Also, the approach below requires that normal L3 forwarding > is applied to the IP provided
RE: policy based routing and backup [7:71482]
Hi "P", Thanks for taking the time to respond to my email. The way the network is setup (right now) is that PBR is setup on the incoming interface into RtrA which will only get network traffic from a.a.a.a and never see any traffic from the incoming interface belonging to b.b.b.b. a.a.a.a is our lab traffic and I would like for it to use a different T1 (through RtrA) than what our real network is using which is a T1 on RtrB. I thought about implementing VRFs but I want to make sure that I cant do it any other way. In regards to the example you gave: route-map dink permit 10 match ip address 10! match the target src IPs set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1. ! route-map dink permit 20 set ip next-hop 10.100.0.1 ! for all other traffic, route ! to loopback interface I went ahead and tried this. I setup a second route-map and pointed the next-hop to the internal loopback interface. I then shut down the T1 on the router and enabled debug to see what happend. The "failover" failed. Here is what the debug is showing: 1d01h: IP: s=a.a.a.a (FastEthernet0/0), d=198.6.1.1, len 92, FIB policy match 1d01h: CEF-IP-POLICY: fib for addr 10.0.0.2 is default; Nexthop rejected So as you can see, the second route-map failed to be used. When the packet came in, it matched the first route-map regardless of whether the next-hop was reachable or not. What about using the command "ip next-hop verify-availability". I was reading up on this feature but I am not sure if I understand its use. Perhaps someone can fill me in. Thanks, Mario Puras SoluNet Technical Support Mailto: [EMAIL PROTECTED] Direct: (321) 309-1410 888.449.5766 (USA) / 888.SOLUNET (Canada) -Original Message- From: p b [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 2:45 PM To: [EMAIL PROTECTED] Subject: RE: policy based routing and backup [7:71482] I'm not sure I understand completely why you want to do this, and it's been a while since I've dinked with PBR, but here's some thoughts on one might get this to work. I've done something similar, but not exactly what's below, so YMMV. Note, VRFs might fit better and I've listed some details on a VRF approach below. As I recall, one of the issues with PBR is that once you enable policy routing on an interface, normal L3 forwarding is completely bypassed.Thus, you can perform policy for the identified packets, but for any packets that you want handled "normally", you're hosed or have to use the hack below. Also, the approach below requires that normal L3 forwarding is applied to the IP provided in the "next-hop" statement. I think some earlier IOS revs (12.0) would not perform a L3 lookup on the next-hop IP. Instead, it was assumed that the "next-hop" was an end-point to a locally connected interface. Config background: Assume that the subnet for the T1 between router A and the ISP's router is 10.0.0.0/30. Assume your router has the .1 address and the remote has the .2 address (10.0.0.2). Assume that you have a loopback define and its IP address is 10.100.0.1. Config snipets: On all of A's internal interfaces, you'll need to configured "ip policy route-map dink". The route-map would look something like this: route-map dink permit 10 match ip address 10! match the target src IPs set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1. ! route-map dink permit 20 set ip next-hop 10.100.0.1 ! for all other traffic, route ! to loopback interface Discussion: Ok, how does this work. Assume a packet arrives on an interface with PBR enabled and processed by the "dink" route-map. If the packet's source is in the target range, set the next-hop to 10.0.0.2. The router then does a L3 lookup on 10.0.0.2. If the T1 is up, 10.0.0.0/30 will be in the route table pointing to the T1 and thus the packet gets sent out the local T1. When this T1 is down, there won't be a route entry for 10.0.0.0/30. So when the router does the L3 lookup on 10.0.0.2, it matches the default and the packet is sent to router B. (Recall that the poster indicate defaults were sent from both ISPs). Note that this approach requires the router to perform a L3 lookup on the next-hop. This is required in order to get the failure scenario to work correctly. You'll need to confirm whether your IOS supports this functionality. Now, what about packets whose sources don't match the first part of the route-map and drop to the route-map's second stage? Presumably we want this packet to follow the standard L3 routing policy defined via LOCAL_PREF, etc. To do this, we need to get the packet processed by L3 as if it just arrived on an interface. One way to do this is to set the "next-hop
RE: policy based routing and backup [7:71482]
I'm not sure I understand completely why you want to do this, and it's been a while since I've dinked with PBR, but here's some thoughts on one might get this to work. I've done something similar, but not exactly what's below, so YMMV. Note, VRFs might fit better and I've listed some details on a VRF approach below. As I recall, one of the issues with PBR is that once you enable policy routing on an interface, normal L3 forwarding is completely bypassed.Thus, you can perform policy for the identified packets, but for any packets that you want handled "normally", you're hosed or have to use the hack below. Also, the approach below requires that normal L3 forwarding is applied to the IP provided in the "next-hop" statement. I think some earlier IOS revs (12.0) would not perform a L3 lookup on the next-hop IP. Instead, it was assumed that the "next-hop" was an end-point to a locally connected interface. Config background: Assume that the subnet for the T1 between router A and the ISP's router is 10.0.0.0/30. Assume your router has the .1 address and the remote has the .2 address (10.0.0.2). Assume that you have a loopback define and its IP address is 10.100.0.1. Config snipets: On all of A's internal interfaces, you'll need to configured "ip policy route-map dink". The route-map would look something like this: route-map dink permit 10 match ip address 10! match the target src IPs set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1. ! route-map dink permit 20 set ip next-hop 10.100.0.1 ! for all other traffic, route ! to loopback interface Discussion: Ok, how does this work. Assume a packet arrives on an interface with PBR enabled and processed by the "dink" route-map. If the packet's source is in the target range, set the next-hop to 10.0.0.2. The router then does a L3 lookup on 10.0.0.2. If the T1 is up, 10.0.0.0/30 will be in the route table pointing to the T1 and thus the packet gets sent out the local T1. When this T1 is down, there won't be a route entry for 10.0.0.0/30. So when the router does the L3 lookup on 10.0.0.2, it matches the default and the packet is sent to router B. (Recall that the poster indicate defaults were sent from both ISPs). Note that this approach requires the router to perform a L3 lookup on the next-hop. This is required in order to get the failure scenario to work correctly. You'll need to confirm whether your IOS supports this functionality. Now, what about packets whose sources don't match the first part of the route-map and drop to the route-map's second stage? Presumably we want this packet to follow the standard L3 routing policy defined via LOCAL_PREF, etc. To do this, we need to get the packet processed by L3 as if it just arrived on an interface. One way to do this is to set the "next-hop" to the local loopback interface IP. The packet is queueed on that logical interface, and then gets processed via normal L3 forwarding. So the router forwards the packet to itself, L3 processes the packet, and then sends it out the desired interface. Note, I think all packets L3 forwarded by the loopback are process switched (you'll need to confirm if this is the case and whether the router has the horsepower to handle this.) In order to deal with the process switching overhead, one could instead forward the packet to a "lollipop" interface. This is basically a port which is wired back to another port on the same router. Suppose you have two FE ports free. You wire them together with a crossed cable, configure the interface as unnumbered, and then set the second stage of the "dink" route-map to set the next-hop the the FE interface. This eliminates the process switching problem, but leaves you with another single point of failure. I've never tried this lollipop interface stuff, but had heard it proposed a few times. You might want to look at VRFs instead and map packets with those certain sources into one VRF and all other packets into the global routing table. In the VRF, define two static defaults with different metrics. The lower metric default points to the local T1 and the second default with higher metric points to router B's enet IP. When the T1 is up, the lower metric default is in the VRF routing table and traffic goes over the T1. If the T1 fails, only the higher metric default pointing to B is in the VRF. Probably cleaner to do it this way... Hopefully, this will give ya some options to consider [EMAIL PROTECTED] wrote: > > Hi all. I have a question that I would like your opinion on. > I have 2 > routers each with a T1 to the upstream provider. Both routers > are running > eBGP to each provider only accepting partial routes and a > default from each. > In additon, each router is peering with each other via iBGP > through a > directly connected ethernet link which is also running ospf. > > > ISPA ISPB > | | > |
