Zum Inhalt wechseln


Foto

876 Router


  • Bitte melde dich an um zu Antworten
46 Antworten in diesem Thema

#31 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 07. Mai 2008 - 10:07

@ wordo:

ok, glück gehabt, aber was mach ich falsch? ich bin davon ausgegangen, dass ich die atm schnittstelle anpassen muss, siehe:

routername(config-if)#dsl operating-mode ?
adsl2 adsl2 mode
adsl2+ adsl2+ mode
auto auto detect mode
etsi etsi mode
itu-dmt ITU full rate mode


oder bin ich hier total falsch? benötige hilfe :-)

#32 Wordo

Wordo

    Board Veteran

  • 3.213 Beiträge

 

Geschrieben 07. Mai 2008 - 10:11

Mach einfach auto. Sieht bei mir genauso aus ...

#33 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 07. Mai 2008 - 10:16

Es steht auf auto, das ist ja das schlimme :-(


oh...man! ich habs hinbekommen! das atm interface war down! unglaublich, heute ist nicht mein tag, haha!

#34 Wordo

Wordo

    Board Veteran

  • 3.213 Beiträge

 

Geschrieben 07. Mai 2008 - 10:29

Poste mal bitte:

sh run int atm0

und

sh dsl int atm0

#35 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 07. Mai 2008 - 10:32

Poste mal bitte:

sh run int atm0

und

sh dsl int atm0


Vergiss es einfach! Ich habs ja schon hinbekommen, das ATM Interface war einfach nur down, haha. geil! heute ist nicht mein tag :-)

aber trotzdem danke für die Hilfe!

gruss.

#36 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 14. Mai 2008 - 08:08

Hallo,

was verbirg sich eigentlich hinter

match qos-group 111 bzw. match access-group 111 ??

Ich versuch das gerade zu herauszufinden.

Gruss.

#37 Wordo

Wordo

    Board Veteran

  • 3.213 Beiträge

 

Geschrieben 14. Mai 2008 - 08:11

Die ACL 111?

#38 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 14. Mai 2008 - 08:39

ja genau, den aufruf über access-group kannte ich, aber qos-group ist mir neu, ruft er damit die selbe acl auf?

#39 daking

daking

    Board Veteran

  • 595 Beiträge

 

Geschrieben 14. Mai 2008 - 08:49

Hallo,

in meinem Fall "markiere" ich am eingangsinterface bestimmten Traffic, den ich nicht via DSCP Remarken will über die QOS Group. Diese "Markierung ist Router intern. Am Ausgangsinterface (hier NAT + IPSEC) kann ich die verschlüsselten Daten dan wieder finden und priorisieren.

Ist für die DSL QOS Funktion jedoch uninteressant.


ciao

#40 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 14. Mai 2008 - 09:05

@ daking:

kannst du mir das etwas näher bringen? :-)

In meinem Fall ist das evtl. auch interesant, da ich über ipsec ne verbindung zum firmencallmanager herstelle. hier am standort hängen mehrere Cisco IP Phones dran.

gruss.

#41 daking

daking

    Board Veteran

  • 595 Beiträge

 

Geschrieben 14. Mai 2008 - 14:24

Hallo,

am Eingangsinterface setzt du via service-policy die QOS Group:

class meine
set qos-group 500

==> am Ausgangsinterface kannst du dann das Queueing nach qos-group 500 machen. (Kann man sich wie einen IOS internen DSCP Wert vorstellen)

In deinem Fall sollten die relevanten Pakete schon mit den richtigen DSCP Werten versehen sein (falls CCM richtig konfiguriert). Da nach IPSEC Standard der DSCP Wert in den nächsten Header übernommen (falls tunnel mode) wird ,musst du dir keinen Stress machen. Ein Klassifizieren nach DSCP Werte sollte in dieser Konstellation reichen. Falls du natürlich nach IP Adressen + DSCP Werte am Ausgangsinterface klassifizierst, sollte man sich gedanken machen wann QOS passiert und ob die richtigen IP Adressen für das CBWFQ noch sichtbar sind...

ciao

#42 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 14. Mai 2008 - 14:52

Hi Daking!

aktuell habe ich die Config mal so aufgestellt:

class-map match-any VoIP
match dscp ef
match access-group name VOICE
class-map match-any VPN
match protocol citrix
match protocol pcanywhere
match dscp af31
!
policy-map QOS
description CE QOS Policy
class VPN
bandwidth 150
set dscp af31
class VoIP
priority 150
set dscp ef
class class-default
fair-queue
set dscp default
police cir 300000 bc 5000
conform-action transmit
exceed-action drop
!

match access-group name VOICE

Die oben genannte VOICE ACL bezieht sich auf die IP Phones. Die sind in einem separaten IP Netz und haben nur Zugriff auf entferntes Voice Gate und CCM.

Eine Ausgabe von sh policy-map int at0 zeigt mir, dass match access-group VOICE greift aber der rest nicht. die service-policy ist zurzeit NUR am atm0 definert:

ATM0: VC 1/32 -

Service-policy output: QOS

Class-map: VPN (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: protocol citrix
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol pcanywhere
0 packets, 0 bytes
30 second rate 0 bps
Match: dscp af31 (26)
0 packets, 0 bytes
30 second rate 0 bps
Queueing
Output Queue: Conversation 41
Bandwidth 150 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
QoS Set
dscp af31
Packets marked 0
Class-map: VoIP (match-any)
275 packets, 57908 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
0 packets, 0 bytes
30 second rate 0 bps
Match: access-group name VOICE
275 packets, 57908 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 150 (kbps) Burst 3750 (Bytes)
(pkts matched/bytes matched) 271/57268
(total drops/bytes drops) 0/0
QoS Set
dscp ef
Packets marked 2
Class-map: class-default (match-any)
59122 packets, 11312899 bytes
30 second offered rate 25000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/0/0
QoS Set
dscp default
Packets marked 113
police:
cir 300000 bps, bc 5000 bytes
conformed 113 packets, 20508 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps


Sicherlich gibt es hier noch Fehler. Ich finde Sie nur nicht, bin ich aber seit einiger Zeit schon am reinlesen, weil ich dies und das noch nicht so ganz verstehe. Ich frag mich aktuell halt, warum dscp ef und af31 nicht matchen

#43 daking

daking

    Board Veteran

  • 595 Beiträge

 

Geschrieben 14. Mai 2008 - 15:15

Hallo,

die VoIP Klasse sollte denke ich erst mal match-all sein ==> also DSCP 46 UND die ACL und nicht match-any DSCP 46 ODER die ACL.

In der Klasse VoiP matched die ACL aber nicht die DSCP 46 regel ==> dscp 46 ist eine zeile höher als die ACL ==> d.h. falls die IPPs dscp 46 senden würden solte es umgedreht sein.

==> IP Phones checken
==> Switches checken (mls qos trust ...)

Für VoIP mit Cisco ist es sehr wichtig den Skinny Traffic in einer eigenen Klasse zu transportieren (Skinny = TCP ==> in der LLQ mit Policer = schlecht!)
==> Skinny kaputt von Normalen Traffic = schlecht

!
class match-all skinny
match dscp cs3 af31
!

wie sieht die ACL VOICE aus? wird hier verschlüsselt?

AF31(CS3) siehe DSCP 46 (switch / port trust..)
==> mit match-any klaut natürlich die ACL Zeile das Af31 von VPN

#44 DocZenith

DocZenith

    Member

  • 228 Beiträge

 

Geschrieben 14. Mai 2008 - 15:26

Hallo,

==> IP Phones checken
==> Switches checken (mls qos trust ...)

wie sieht die ACL VOICE aus? wird hier verschlüsselt?


Servus! Danke für deine Hilfe und Bemühungen!

Also Switches brauch ich nicht groß zu prüfen. Hab hier bisher nur ein Lab aufgebaut mit 876er und vier IPPs (7911er).

Wegen den ACL VOICE, die sieht so aus, keine große Kunst:

ip access-list extended VOICE
permit udp 10.161.110.0 0.0.0.255 x.x.x.x 0.0.255.255
permit tcp 10.161.110.0 0.0.0.255 x.x.x.x 0.0.255.255
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.1
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.2
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.3
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.4

Wie sieht das denn mit dem internen Interface aus? auf dem 876er habe ich ja nur diesen integrierten Mini-Switch, hier kann ich die einzelnen Ports ja nicht wirklich konfigurieren, mache das zurzeit mit einem VLAN, der den Ports zugewiesen ist. In dem Vlan habe ich noch keine Service-Police eingetragen.

Das Telefonproblem ist, dass das erste Gespräch sauper läuft, bis ein zweites IPP ein Anruf aufbaut, dann wird die Qualität schnell schlecht! Nutze im meinem Lab ganz normales DSL 3000.

Gruss.

#45 daking

daking

    Board Veteran

  • 595 Beiträge

 

Geschrieben 18. Mai 2008 - 12:55

Hola,

welchen Codec verwendest du (G.711 / G.729 / G.723) --> Coderintervall?(20ms / 30ms)
welche Upload Bandbreite hast du?

test#sh dsl int atM 0 | inc Speed
Speed (kbps): 3456 0 448 0
test#

==> 3456 kbit/s down / 448 kbit/s up
==> 448 ist hier interessant

Hier die Kalkulation der benötigten Bandbreite pro Call (Beispiel G.711a - 20ms)

Overhead:

[IP Overhead]
Voice Payload ==> 160 Byte
RTP Header ==> 12 Byte
UDP Header ==> 8 Byte
IP Header ==> 20 Byte
Ethernet Header ==> 14 Byte

[IPSEC] falls vorhanden tunnel / transport

tunnel IP Header ==> 20 Byte

ESP IV ==> 8 Byte
ESP Header ==> 8 Byte
ESP PAD
ESP Auth ==> 12 Byte
IPSEC Header ==> 20 Byte

[ATM / PPPOE]

PPPOE Header ==> 8 Byte
AAL5 Header ==> 10 Byte
AAL5 Trailer ==> 8 Byte

= 308 Byte Packet Size

==> wie viel ATM Zellen? ==> 308 / 48 Byte = 6,41 ==> let's pad ==> 7
==> 7 Zellen pro VoIP Paket
==> 7 * 53 ( 53 Byte Zellen mit overhead) ==> 371 Byte


==> Nun 20 ms Coderinterval ==> 50 pps
==> (371 *8) * 50 pps / 1000 ==> 148,4 kbit/s

Mit 448 kbit/s sollte das kein Problem sein.
Das Problem könnte unter Last das Delay sein (kleiner 784kbit/s Delay issue)

==> tune mss
==> tune per vc tx-ring (minimal 3)
==> check service-policy LLQ Bandbreite und Drops
!
int atm0
pvc x/y
tx-ring-limit 3
!

!
interf dialer 100
ip tcp adjust-mss 592
!
==> die class-maps solltest du natürlich ebenfalls anpassen (match-all)

ciao

Hola,

falls du ingress Klassifizieren willst

class-map match-all RTP
match protocol rtp
!
class-map match-all Skinny
match protocol skinny
!
policy-map MARK
class RTP
set dscp ef
clas Skinny
set dscp af31
!
interface vlan xxx
service-policy in MARK
!

==> die CCM Config muss RTP und Skinny markieren...

ciao