05-17-2012 09:41 PM - edited 03-07-2019 06:46 AM
Hi Guys,
I am facing severe issue with LAN Qos. There two C3750 switches at different locations with a 1 GBPS TRUNK from telco. This trunk carries customer Layer 2 traffic ( VLAN's including management traffic, data - voice traffic, BGP between the two etc). Customer L3 switch is connected back on one of the ports i.e. one L3 at each location. Here in this set up BGP looses session each time utilization reaches 600 - 800 Mb. I have queue set applied on the interface but I guess it needs to be further tweaked. Have you faced such issues ? Need your inputs on how can I make peering stable.
Queue set Queue set
(Sw1) ---------------1Gig Trunk ----------------------- (Sw2)
| |
| Queue set | Queue set
(L3) (L3)
Best regards,
Santosh
Solved! Go to Solution.
05-18-2012 02:42 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
3750 queue sets deal with buffer resource allocations, but bandwidth ratios are set per interface.
You need to insure your queuing model/policy "protects" your BGP traffic. On a traditional router, you might use CBWFQ and devote a special queue (with small bandwidth guarantee) for your routing protocol. On something like a 3750, since you only have 4 hardware queues to work with, you might be unable to devote one of those queue just for your routing protocol but whatever queue you do use should have enough bandwidth reservation to insure your routing protocol gets the bandwidth it requires. The latter could be done by insuring that queue has sufficient bandwidth to carry all the traffic in that queue (i.e. including other than routing protocol traffic) or you could use WTD to insure other traffic in that queue is dropped before your routing protocol traffic (i.e. leaving enough bandwidth for your routing protocol).
PS:
It's been a while since I've tuned BGP, but it might be possible to tune BGP to make it a little more robust during transient congestion.
05-18-2012 03:09 AM
if you want to use QoS to resolve this problem, you could create a class for bgp and give it a little priority over other traffic.
access-list 150 permit tcp any eq bgp any << bgp port# 179
access-list 150 permit tcp any any eq bgp
class match-all BGP
match access-group 150
!
policy-map BGP
class BGP
priority percent 10
class class-default << set your other traffic queue, bandwith or... parameters under this, if any!
fair-queue
!
interface gi0/1
service-policy out BGP
!
hope this solution with QoS helps or you could fine tune ur bgp.
pls Rate if it helped.
Soroush.
05-18-2012 09:26 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
What Soroush posted could assist BGP in keeping its connection "up", however some QoS usage notes: you wouldn't normally place BGP into LLQ as its latency requirements aren't as stringent as, for example, VoIP; you would likely find allowing BGP to participate in just class-default's FQ might be sufficient "protection"; 3750's don't support egress CBWFQ.
05-18-2012 02:42 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
3750 queue sets deal with buffer resource allocations, but bandwidth ratios are set per interface.
You need to insure your queuing model/policy "protects" your BGP traffic. On a traditional router, you might use CBWFQ and devote a special queue (with small bandwidth guarantee) for your routing protocol. On something like a 3750, since you only have 4 hardware queues to work with, you might be unable to devote one of those queue just for your routing protocol but whatever queue you do use should have enough bandwidth reservation to insure your routing protocol gets the bandwidth it requires. The latter could be done by insuring that queue has sufficient bandwidth to carry all the traffic in that queue (i.e. including other than routing protocol traffic) or you could use WTD to insure other traffic in that queue is dropped before your routing protocol traffic (i.e. leaving enough bandwidth for your routing protocol).
PS:
It's been a while since I've tuned BGP, but it might be possible to tune BGP to make it a little more robust during transient congestion.
05-18-2012 03:09 AM
if you want to use QoS to resolve this problem, you could create a class for bgp and give it a little priority over other traffic.
access-list 150 permit tcp any eq bgp any << bgp port# 179
access-list 150 permit tcp any any eq bgp
class match-all BGP
match access-group 150
!
policy-map BGP
class BGP
priority percent 10
class class-default << set your other traffic queue, bandwith or... parameters under this, if any!
fair-queue
!
interface gi0/1
service-policy out BGP
!
hope this solution with QoS helps or you could fine tune ur bgp.
pls Rate if it helped.
Soroush.
05-18-2012 09:26 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
What Soroush posted could assist BGP in keeping its connection "up", however some QoS usage notes: you wouldn't normally place BGP into LLQ as its latency requirements aren't as stringent as, for example, VoIP; you would likely find allowing BGP to participate in just class-default's FQ might be sufficient "protection"; 3750's don't support egress CBWFQ.
06-07-2012 06:20 AM
Hi Joseph, Techies,
Can we use CPP (control plane policing)? I am not sure but just a guess.
Regards,
Santosh
06-07-2012 09:41 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
CoPP might be useful if the problem was consumption of CPU, such that your BGP couldn't be maintained. However, from your description, it would seem more likely the BGP packets might be lost during congestion.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide