pirority group damn it [7:38084]

2002-03-13 Thread Cisco Breaker
Hi all, I have a question regarding priority groups. We have 2 firewalls. 10.1.1.2 and 10.1.1.3. I am using 10.1.1.2 . But even if I am using 10.1.1.2 the connection is slow as before. What is wrong with my config? Any answer will be highly appreciated. Best regards, Ciscobreaker, CCNP,CCDP R

Re: pirority group damn it [7:38084]

2002-03-13 Thread Tshon
I'm not sure but your config says that anything ip with a source add 10.1.1.2 to any place gets high priority. But anything else ip gets low priority arp and so on. Is that what you are trying to accomplish? what about other traffic not originating from the firewall, all user traffic gets pla

Re: pirority group damn it [7:38084]

2002-03-13 Thread Priscilla Oppenheimer
Your access-list 150 and priority list say to make traffic from the firewall be highest priority. All other IP traffic appears to be the lowest priority. But what traffic does your firewall actually send? The term firewall gets used to mean all sorts of things including proxy servers. But if y

Re: pirority group damn it [7:38084]

2002-03-15 Thread Cisco Breaker
Excuse me for the configuration mistyping but before I had change my config my access list was different than that . It belongs to another network ip like 172.16.1.2. Anyway thanks for the correction. I want to make sure that these priority or custom queuing methods are only used when congestion

Re: pirority group damn it [7:38084]

2002-03-15 Thread Priscilla Oppenheimer
At 03:42 AM 3/15/02, Cisco Breaker wrote: >Excuse me for the configuration mistyping but before I had change my config >my access list was different than that . It belongs to another network ip >like 172.16.1.2. Anyway thanks for the correction. I want to make sure that >these priority or custom q

Re: pirority group damn it [7:38084]

2002-03-15 Thread MADMAN
Priscilla Oppenheimer wrote: > > > I think Cisco recommends not using fancy queuing unless you are already > experiencing congestion. Your best solution to avoid the slowness you > mentioned may be to remove the priority queuing statements. > Absolutley, remember features kill, just becaus