PBR on 1841 (no NAT, no ACLs, dual ADSL)

Hi,

I'm having a problem trying to set up policy based routing on an 1841 with Advanced IP Services 12.4(24)T3.

It's a no-NAT setup, and I've tried removing all the ACLs for test purposes, since firewalling is done on a separate box.

Two ADSL cards connect my 1841 to the Internet. The ISP shares out my ingress packets in proportion to the speed of each ADSL line. It all seems to work OK out of the box.

I'd just like to do some crude QoS for VOIP egress traffic. That is, when both ADSL lines are up, I'd like to force the VOIP egress traffic up one line, and force all other egress traffic up the other line. This should preserve VOIP call quality when I'm uploading files to the Internet. Also it would avoid the possibility of out-of-order VOIP packet delivery due to asymmetrical routing. The ISP already does QoS for VOIP on the downlink side, so protecting VOIP uplink traffic is the missing piece of the puzzle for me.

I was hoping this would work :-

access-list 110 permit ip host 81.187.151.42 any access-list 110 permit icmp host 81.187.151.42 any

route-map voip permit 10 match ip address 110 set interface dialer0

route-map voip permit 20 set interface dialer1

interface fa0/0 ip policy route-map voip

As far as I can tell, the egress traffic is indeed being forced up line

1 or line 2, depending on source IP within my network.

However, whenever the route-map is applied to the Ethernet interface, my webserver 81.187.151.35 is unable to reply to incoming HTTP requests from the Internet. Tcpdump shows that the webserver receives the TCP SYN packets and responds to them, but the 1841 fails to route them to back to the Internet. For test purposes, there are no ACLs applied to the interfaces.

Am I missing something fundamental to making this work?

Or, is there an alternative way to provide QoS for VOIP? The egress traffic from the VOIP box is flagged at layer 3 with DIFFSRV IP TOS flags: 'EF' (expedited forwarding) for RTP audio frames, 'CS3' (Class 3 Assured Forwarding) for SIP signalling frames.

Grateful for any help!

Mildly sanitized config follows.

Thanks,

- Martin.

==========================================

version 12.4 no service pad service tcp-keepalives-in service tcp-keepalives-out ! ! no aaa new-model dot11 syslog no ip source-route ! ip cef no ip bootp server ip name-server 8.8.8.8 ipv6 unicast-routing ipv6 cef ! multilink bundle-name authenticated ! ip tcp selective-ack ip tcp timestamp ! interface FastEthernet0/0 ip address 81.187.61.217 255.255.255.248 ipv6 address 2001:dead:beef:3::1/64 ipv6 enable no mop enabled ip policy route-map voip ! interface FastEthernet0/1 no ip address shutdown ! interface ATM0/0/0 no ip address no ip redirects no ip unreachables no ip proxy-arp load-interval 30 no atm ilmi-keepalive ! interface ATM0/0/0.1 point-to-point no ip redirects no ip unreachables no ip proxy-arp ip virtual-reassembly pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 1 ! interface ATM0/1/0 no ip address no ip redirects no ip unreachables no ip proxy-arp load-interval 30 no atm ilmi-keepalive ! interface ATM0/1/0.1 point-to-point no ip redirects no ip unreachables no ip proxy-arp ip virtual-reassembly pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 2 ! interface Dialer0 ip address negotiated no ip redirects no ip unreachables no ip proxy-arp encapsulation ppp tx-ring-limit 3 tx-queue-limit 3 dialer pool 1 dialer-group 1 ipv6 address autoconfig ipv6 enable ppp authentication chap pap callin ppp chap hostname xxxx@a.1 ! interface Dialer1 ip address negotiated no ip redirects no ip unreachables no ip proxy-arp encapsulation ppp tx-ring-limit 3 tx-queue-limit 3 dialer pool 2 dialer-group 1 ipv6 address autoconfig ipv6 enable ppp authentication chap pap callin ppp chap hostname xxxx@a.4 ! access-list 110 permit ip host 81.187.151.42 any access-list 110 permit icmp host 81.187.151.42 any

route-map voip permit 10 match ip address 110 set interface dialer0

route-map voip permit 20 set interface dialer1

interface fa0/0 ip policy route-map voip ! no ip forward-protocol nd ip forward-protocol spanning-tree ip route 0.0.0.0 0.0.0.0 Dialer0 ip route 0.0.0.0 0.0.0.0 Dialer1 ip route 81.187.151.32 255.255.255.240 81.187.61.218 permanent

dialer-list 1 protocol ip permit dialer-list 1 protocol ipv6 permit no cdp run

ipv6 route 2001:dead:beef:1::/64 2001:dead:beef:3::2 ipv6 route 2001:dead:beef:2::/64 2001:dead:beef:3::2 ipv6 route ::/0 Dialer0 ipv6 route ::/0 Dialer1 ! control-plane ! scheduler allocate 20000 1000

Reply to
Martin Johnson
Loading thread data ...

One thing, have you verified that both DSLs are actually working?

81.187.151.42 is a voice gateway or something like that. 81.187.151.35 - web server

Well all looks OK to me. I am tempted to suggest that there is something amiss with your testing of the web server.

One thing worth looking at might be a debug ip packet detail.

You need to turn off fast switching

no ip route-cache on the interfaces

You need to arrange to see the debug output

Say logging buffered 50000

Then sh log to view the messaegs.

might need logg buffered debug

Remember to turn fast switching back on after no ip route-cache

deb ip policy might be worth a look not sure what it does.

Reply to
bod43

My experience in the past is that the combination of PPPoA ADSL and PBR and IP CEF does not work. I no longer have that setup so I did not try with more recent IOS versions.

Try "no ip cef" to see if there is a difference.

Reply to
Rob

Thanks

No luck with "no ip cef"

Reply to
Martin Johnson

Yes - I can unplug either of them and still surf the web, make VOIP calls, and receive inbound traffic to my servers.

I also get traffic graphs from the ISP, showing uplink and downlink traffic on each pipe.

Exactly, yes.

Hi,

That seems to have fixed it!

interface fa0/0 no ip route-cache interface dialer0 no ip route-cache interface dialer1 no ip route-cache

I turned it back on like so:-

interface fa0/0 ip route-cache interface dialer0 ip route-cache interface dialer1 ip route-cache

That didn't seem to break anything :-)

Perhaps "no ip route-cache" is necessary to flush out stale data after a route-map is installed??

The VOIP quality certainly sounds spotless, even when I saturate the links. Next thing to try is how well failover works after one or other of the ADSL lines suffers a simulated failure (i.e. being unplugged).

Many thanks!

- Martin

Reply to
Martin Johnson

As noted earlier, this worked OK after I turned fast switching off and on again. Before that, incoming requests to my servers were dropped.

The only continuing drawback with this configuration is that when one ADSL line fails, the egress traffic doesn't fail over to the surviving line. I tried switching off both fast switching and CEF, to no effect.

Is there a way of achieving fall-back routing with a route-map ?

I do have default routes, but they don't seem to fix this!

ip route 0.0.0.0 0.0.0.0 Dialer0 ip route 0.0.0.0 0.0.0.0 Dialer1

Is it worth updating from IOS 12.4 to 15.1 to see if that's any better?

Thanks,

- Martin

Reply to
Martin Johnson

Latest suggestion to get the fallback routing working, is to combine IP SLA and VRF. May need VOIP server to be moved to the spare Ethernet interface. I'll post a working config if I get it working.

Reply to
Martin Johnson

  1. the no ip route-c, ip route-c was (obviously) not suopposed to fix anything:)

Have a look to see that the interface config is the same as you had originally. Please post result of sh run int FastEthernet0/0. Maybe you have indeed turned off CEF or somehting.

  1. Depending on the failures you want to protect against there are various fallback options.

SLA is the most robust since you can detect failure anywhere in the path.

If you though are content to detect only failures that cause the dialer to go down then you should be able to use PBR with normal routing as a fallback. By default if the specified PBR interface is not available then it automatically falls back to normal routing.

I am not sure why you might need VRFs. I am quite likely missinformed:-)

Finally unless the config was changed by the route-cache stuff you must have run into a bug OR have changed something else in your network inadvertently OR of course your ISP changes something.

Reply to
bod43

Thanks for your thoughts. I'll have a further look when I can.

Reply to
Martin Johnson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.