[c-nsp] routed via RIB, Cisco 3640 VoIP Problem

[Saad]

I have two problems. First I did what you told me but didnt see anything unusual. In
fact tell me what should I be looking for? The main issue is the outgoing traffic.As I
mentioned that when the calls start coming in the outgoing traffic becomes double than
the inward traffic on ATM (DSL) interface. After 2-3 hours this traffic settles down
and the upload becomes equal to download. I dont know what sort of traffic is it and
so far unable to determine how to stop or monitor it. From another discussion topic
that I found on the list it might be the UDP packet size when DSL is used. I am not
sure though. Please take a look.
https://puck.nether.net/pipermail/cisco-nsp/2004-October/013902.html

The other problem I see is that I am doing radius billing for this router. Now as soon
as I configure the aaa on Cisco the traffic increases. The billing is running on SQL
server which is fully patched and updated. I have set the Cisco to send aaa packets to
port 1812 and 1813 but from a traffic monitoring tool on windows I see the source port
1645 and 1646 being sent by Cisco. All this traffic is coming on UDP ports and this is
the actual traffic causing problem. Its volume according to the traffic monitoring
tool is very high.
Now you can see I have two seperate issues. In both scenarios the outgoing traffic on
Cisco doubles causing the link to choke. Please help me out on this.


Saad



Rodney Dunn wrote:

> That simply means a packet from process level is being
> forwarded and it was sent via a RIB lookup (vs. a FIB
> lookup).  Under some conditions we can actually use the
> CEF/FIB to forwad locally generated packets.
>
> On Thu, Nov 11, 2004 at 03:52:30PM +0500, Saad wrote:
> > I am running VoIP call termination on Cisco 3640 with NM-HDV module. The
> >
> > problem I am facing is that whenever I have traffic load then I have a
> > lot of outgoing traffic on the router. I am using WIC-1ADSL card for
> > internet and the protocol used is RFC1483 Routed. From previous
> > discussion I think it might be the UDP packet size or I doubt that it
> > might be a routing loop. When I use debug ip packet detail, I get the
> > following result.
> >
> >
> > 23:45:17: IP: tableid=0, s=80.32.170.82 (local), d=213.228.199.50
> > (ATM2/0.1), routed via RIB
> > 23:45:17: IP: s=80.32.170.82 (local), d=213.228.199.50 (ATM2/0.1), len
> > 56, sending
> > 23:45:17:     ICMP type=3, code=3
>
> The above means the router sent a packet with a src of 80.32.170.82
> (which is a locally attached ip address) to a dst of d=213.228.199.50
> and routing table lookup resulted in an outbound interface of
> ATM2/0.1.  Most likely this was a ping someone originated from
> router.
>
> > 23:45:17: IP: tableid=0, s=213.228.199.50 (ATM2/0.1), d=80.32.170.82
> > (ATM2/0.1), routed via RIB
> > 23:45:17: IP: s=213.228.199.50 (ATM2/0.1), d=80.32.170.82 (ATM2/0.1),
> > len 41, rcvd 3
> > 23:45:17:     UDP src=17846, dst=17834
>
> This is a packet that was swtiching through the router and was
> punted to process level (else you would not have seen it in the
> debug here).
>
> > 23:45:17: IP: tableid=0, s=213.228.199.50 (ATM2/0.1), d=80.32.170.82
> > (ATM2/0.1), routed via RIB
> > 23:45:17: IP: s=213.228.199.50 (ATM2/0.1), d=80.32.170.82 (ATM2/0.1),
> > len 144, rcvd 3
> > 23:45:17:     UDP src=16821, dst=18515
> > 23:45:17: IP: tableid=0, s=213.228.199.50 (ATM2/0.1), d=80.32.170.82
> > (ATM2/0.1), routed via RIB
> > 23:45:17: IP: s=213.228.199.50 (ATM2/0.1), d=80.32.170.82 (ATM2/0.1),
> > len 120, rcvd 3
> > 23:45:17:     UDP src=17281, dst=18265
> >
>
> You said: > problem I am facing is that whenever I have traffic load then I have a
> > lot of outgoing traffic on the router.
>
> You need to be more clear on what load you see where.
> The best way to track the traffic is to do "ip route-cache flow"
> on all your ingress interfaces and look at "sh ip cache flow".
>
>
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/