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

Discussion in 'Cisco' started by bod43, Dec 5, 2010.

  1. bod43

    bod43 Guest

    On Dec 4, 11:43 pm, Martin Johnson <> wrote:
    > 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.


    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.
    bod43, Dec 5, 2010
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    17
    Views:
    17,177
    Slash2007
    Sep 25, 2007
  2. -pau.fr
    Replies:
    0
    Views:
    698
    -pau.fr
    Oct 29, 2006
  3. StoragePartners

    1841 Dual ADSL Connection Issue

    StoragePartners, Mar 26, 2009, in forum: Cisco
    Replies:
    0
    Views:
    1,314
    StoragePartners
    Mar 26, 2009
  4. Rob
    Replies:
    0
    Views:
    499
  5. bod43
    Replies:
    0
    Views:
    797
    bod43
    Dec 7, 2010
Loading...

Share This Page