daking

Hi zusammen,

 

nur mal so nebenbei - es gibt nicht mehr ganz aktuelle änderungen des TKG und BDSG - diese wirken sich auf VoIP analysen aus:

 

Analyse von VoIP Sprachverbindungen:

 

TKG § 100 Störungen von Telekommunikationsanlagen und Missbrauch von Telekommunikationsdiensten

 

(1) Soweit erforderlich, darf der Diensteanbieter zum Erkennen, Eingrenzen oder Beseitigen von Störungen oder Fehlern an Telekommunikationsanlagen die Bestandsdaten und Verkehrsdaten der Teilnehmer und Nutzer erheben und verwenden.

 

(2) Zur Durchführung von Umschaltungen sowie zum Erkennen und Eingrenzen von Störungen im Netz ist dem Betreiber der Telekommunikationsanlage oder seinem Beauftragten das Aufschalten auf bestehende Verbindungen erlaubt, soweit dies betrieblich erforderlich ist. Das Aufschalten muss den betroffenen Gesprächsteilnehmern durch ein akustisches Signal angezeigt und ausdrücklich mitgeteilt werden.

 

==> akustisches Signal oder vorheriger Genehmigung

 

--> Ergebnis:

 

§ 201 Verletzung der Vertraulichkeit des Wortes

(1) Mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe wird bestraft, wer unbefugt

 

1. das nicht öffentlich gesprochene Wort eines anderen auf einen Tonträger aufnimmt oder

==> tonträger kann hier ebenfalls eine festplatte sein (oder anderes speichermedium)

2. eine so hergestellte Aufnahme gebraucht oder einem Dritten zugänglich macht.

==> via wireshark abgespielt.

 

also have a nice weekend

 

P.S. natürlich handelt es sich hier nur um Teststellungen die analysiert werden.

Hi,

 

zwischen den VLANs kannst du wie gesagt den IPX Traffic via Fallback Bridging weiterleiten:

 

bridge 1 protocol vlan-bridge

!

int vlan 10

ip add x.x.x.x

bridge-group 1

!

int vlan 20

ip add x.x.x.x

bridge-group 1

!

6k#sh bridge 1

 

Total of 300 station blocks, 298 free

Codes: P - permanent, S - self

 

Bridge Group 1:

 

Address Action Interface Age RX count TX count

ca01.0b58.001c forward Vlan20 0 1 0

ca00.0b58.001c forward Vlan10 0 1 0

-------------

1#ping ipx

Target IPX address: AA.ca01.0b58.001c

Repeat count [5]: 1000000000

Datagram size [100]:

Timeout in seconds [2]:

Verbose [n]:

Type escape sequence to abort.

Sending 1000000000, 100-byte IPX Novell Echoes to AA.ca01.0b58.001c, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................... --> Bridge raus

............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --> Bridge rein

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.

Success rate is 89 percent (305/340), round-trip min/avg/max = 12/38/-1 ms

 

Das ist also technisch möglich. Aber Vorsicht: der Traffic wird im Software Pfad weitergeleitet. Wenn es sich hier um sehr sehr viel Traffic handelt könnte das eher suboptimal sein. Um wie viele IPX Clients handelt es sich?

 

cheers

 

//

Hi,

 

unter dem Port solltest du noch switchport mode access setzten

[ebenfalls switchport nonegotiate]

 

Wie sieht die Config der BG für IPX auf dem 3550 aus?

==> sollte via fallback bridging realisierbar sein. denke ich :-)

 

ciao

Hi,

 

um DHCP mit vrf spezifischen Pools zu aktivieren:

 

ip dhcp use vrf connected

 

Zum Weiterleiten der via IPCP empfangenen DNS Server Adresse (die wird in der vrf empfangen und nicht in der globalen Routinginstanz - siehe oben) sollte die Config passen.

 

ciao

Hi,

 

ja der Signalling Traffic muss ebenfalls transparent durchgereicht werden - also mit dem definierten Wert für die SIG Klasse ankommen. Es gibt zwar Modelle in denen dies nicht passiert - sprich die Markierung im Backbone geändert werden kann - ist aber hier denke ich nicht im Einsatz. Scheint eine fehlerhafte Klassifizierung zu sein.

 

Ihr habt eine COS1 Klasse (interessantes naming) für VoIP geordert - Dies mit 384 kbit/s - Woher kommt diese Berechnung? Wird hier ebenfalls der Signalling Traffic transportiert oder soll der in der default Klasse laufen?

 

Na ja erst mal das Marking hinkriegen - 128M interessant - eigentlich reicht hier doch ein einfacher Call.

 

Ja mit MPLS habe ich schon mal was gemacht :-).

 

cheers

Hi,

 

sind beide ports gleich konfiguriert? wenn nein auf der monitor dest ebenfalls dot1q aktivieren. ebenfalls mal testen mit

monitor session 1 destination interface gigabitEthernet <ifid> encapsulation replicate versuchen.

Mit Boardmitteln kannst du ebenfalls testen falls mls qos aktiviert ist --> sh mls qos int <foo> statistics.

 

Ihr habt eine 802.1q Verbindung zum Provider?

Ebenfalls sollte der Provider sehr schnell sagen können, ob er matches in der RT Klasse hat..

 

hope this helps

cheers

Hi,

 

ok - die Frage ist nun wo die MAC gelernt wird oder ob diese gelernt wurde. Also für die gefluteten mac addr mal sh mac-addr <x.x.x.x> vlan x. Auf der SUP2 sollte es ebenfalls sh mac-add unicast-flo geben, dann sollte im log jedoch ebenfalls eine meldung ausgegeben werden. Ist dies ein permanentes flooding oder tritt es in intervallen auf? Mehr Info über das Setup macht immer Sinn - also kurze skizze.

 

ciao

Hi Otaku,

 

welche tec session haste am Mo gebucht?

 

bei wird wohl nun leider auch nichts..

 

ciao

Hi,

 

komisches Capture File. Mit welchem Tool haste das File erzeugt und mit welchen Einstellungen. CapLen begrenzt? (und auf dem testlaptop facebook offen - :-))

 

Wenn du diesen Traffic an jeden Port siehst - ist das def nicht ok.

 

Nun zur Analyse

- welche Module/SUP sind im Einsatz (DFC/CFC)

- welche Aufgaben hat hier der 6k? (rein l2/l3 - services)

- was sagt sh spann det für dieses vlan (werden hier die tc hochgezählt)

- was sagt sh mac-address detail|all für die gefluteten mac adressen?

- was sagt sh mac-address count ?

- was sagt sh vlan virt slot x (alle slots)

 

@Otaku: hier wird max 10kbit/s und max 10pps generiert. Sollte kein Problem sein.

 

ciao

Hi,

 

switchport oder routed port sollte da recht egal sein. Mit den ip flow kommandos können pakete die zur MSFC weitergeleitet via netflow ausgewertet werden. Wenn du Pakete die durch die HW (PFC) weitergeleitet werden analysieren willst, wird dies via mls kommandos realisiert.

 

Das sollte helfen:

 

https://supportforums.cisco.com/thread/1003948

 

 

--> per interface netflow wird erst ab Withney-1 (SXH) unterstützt

 

btw - egress netflow wird nicht unterstützt

 

ciao

Hi,

 

mit DFC's oder ohne?

 

ciao

Hi,

 

mit dieser config kannst du netflow auf dem rp aktivieren - also nicht auf dem hw fwd. solltest da eher mal in der ecke mls nde und mls netflow suchen.

 

ciao

Hallo,

 

//

Unfortunately, egress NetFlow is not supported in hardware on any PFC3*

system

\\

 

im default werden auf dem 65er alle ingress HW Flows accounted. Egress ist auf EARL7 in HW nicht supported (kommt mit EARL8). Mit mls nde können die HW Switched Flows exportiert werden. ip flow Kommandos accounten nur punt-to-cpu traffic, sprich software switched flows. Für egress netflow sollte es eine Ausnahme geben - egress multicast accounting.

Die Suche in den Release Notes wird vergeblich sein ;-(. Falls du eine Herstelleraussage willst --> Case bei Cisco --> Viel Spass

 

ciao

Hi,

 

egress netflow wird nicht in unterstützt.

 

ciao

Hola Otaku,

 

die constellation+ platform lebt :-) - wird wohl noch ein wenig dauern, bis wir hier die schwarzen anzüge anziehen müssen und alle auf junos logik migrieren (aka XR) - aber "set xx" ist schon irgendwie kätzerei!

 

 

:-)

 

p.s. I'm allready migrated

p.p.s: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf ==> input

Hi,

 

ja mit 80 für IP und 100 für ETH bist du für ein Gespräch falls g.711 auf dem richtigen Weg. Bei ADSL würde ich da noch auf 120 gehen (Cell Padding und Co.). Zur Markierung der RTP Packete könntest du Eingangsseitig folgende policy verwenden:

 

ip access ext AVM_RTP

permit udp host <AVM IP> range 10000 11000 any (vielleicht auch range wie vorher)

!

class-map RTP

match ip address AVM_RTP

[vielleicht klappt auch match protocol rtp - braucht jedoch mehr ress]

!

policy-map MARK

class RTP

set ip dscp ef

 

!

int x/y

desc da ist die Box

service-policy in MARK

!

 

ciao

Hi,

 

also dann wieder das übliche - Du musst am Cisco die Überlast erkennen, d.h. du musst den Flaschenhals von 2mbit/s dort am Ausgangsport simulieren. Das Bandwidth kommando ist nur ein hilfsmittel für routingprotokolle und für prozentuale Bandbreitenangaben in policy-maps. Hierfür kannst du nested policies verwenden:

 

!

policy-map Q

class VoIP

priority percent xx | priority <rate>

class class-default

fair-queue

!

policy-map 2M

class class-default

shape average 1900000

service-policy Q

!

 

Die policy-map 2M shaped auf 2M (mit def 25ms TC) bei Überlast regelt Q das Queueing - VoIP bekommt eine bestimmte Bandbreite mit LLQ Eigenschaften.

 

Beachten solltest du, dass du keine 2048 mbit/s Nutzbandbreite hast und wieviel du für RTP/VoIP Calls reservieren willst - Ebenfalls solltest du nicht nach der BOX IP matchen sondern die RTP Pakete mit einem DSCP Wert versehen - das sollte die AVM Fritzbox können.

 

Hope this helps

 

ciao

Hi,

 

die IP SLA Messung an sich funktioniert ja - Es wurde halt Packet Loss festgestellt. Die Messung geht auf != OK wenn der Responder nicht erreichbar ist oder sonstige Fehler auftreten. Die reaction-configuration Funktion sollte mit dieser Config funktionieren - du siehts im Moment nur nichts - Also:

--

ip sla logging traps

--

und sicherstellen, dass der action-type auf traponly steht:

--

ip sla reaction-configuration 3 react packetLoss threshold-value 2 1 threshold-type immediate action-type trapOnly

--

Dann sollte nun im Log für auftretenden Packetloss folgende Meldung kommen

 

'1248: 000823: Jun 35 13:11:24.600: %RTT-4-<Packetlos..>: condition occurred,

 

Bei der nächsten Messung die ohne PKT Loss ist:

'1248: 000823: Jun 35 13:11:28.600: %RTT-4-<Packetlos..>: condition cleared.

 

Diesen Trap kannst du extern auswerten und dann via snmp die letzte Messung abfragen --> Prozent bestimmen --> Aktion definieren.

 

Oder lokal auf dem Router via EEM

 

hope this helps

 

cheers

das sollte mit einem mix aus NAT,static route-leaking und BGP funzen (dann kann man das auch auf weiter Kunden erweitern) - das inter vrf routing ist mit gleichen p2p interface adressen ein wenig strange - das sollte man nochmal überdenken.

Hier die Config des Core Routers (warum sind da keine Routernamen in der Grafik - ok next time). Also der Router in der Mitte.

---snip

ip vrf vrf11

rd 1:1

export map TAG

route-target export 1:1

route-target import 1:1

route-target import 99:99 !e-comm für inter-vrf

!

ip vrf vrf12

rd 2:2

export map TAG

route-target export 2:2

route-target import 2:2

route-target import 99:99 !e-comm für inter-vrf

!

router bgp 64000

no bgp default ipv4-unicast

bgp log-neighbor-changes

!

address-family ipv4 vrf vrf11

no synchronization

redistribute ospf 1000 vrf A metric 100 route-map INTER_VRF !IGP oder was immer in der VRF

exit-address-family

!

address-family ipv4 vrf vrf12

no synchronization

redistribute ospf 2000 vrf B metric 100 route-map INTER_VRF !IGP oder was immer in der VRF

exit-address-family

!

ip nat pool VRF_A 9.9.1.0 9.9.1.254 netmask 255.255.255.0 !was auch immer Richtung Global

ip nat pool VRF_B 9.9.2.0 9.9.2.254 netmask 255.255.255.0 !was auch immer Richtung Global

ip nat inside source route-map NAT pool VRF_A vrf vrf11

ip nat inside source route-map NAT pool VRF_B vrf vrf12

!

ip route vrf A 10.88.0.0 255.255.0.0 <OIF_to_FW> <FW> global

ip route vrf B 10.88.0.0 255.255.0.0 <OIF_to_FE> <FW> global

!

ip access-list standard LEAK

permit 192.168.1.0 0.0.0.255

permit 192.168.2.0 0.0.0.255

!

ip access-list extended NAT-PERMIT

permit ip 192.168.0.0 0.0.255.255 10.88.0.0 0.0.255.255

!

route-map TAG permit 10

match ip address LEAK

set extcommunity rt 99:99 additive !ADD RT for INTRAVRF

!

route-map INTER_VRF permit 10

match ip address LEAK

!

!

route-map NAT permit 10

match ip address NAT-PERMIT

 

==> Routen auf der FW und CO Richtung Nat Bereich nicht vergessen

C1_A#ping 192.168.2.1 source loopback 0 repeat 1000

 

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.1.1

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 244/369/492 ms

!

C1_A#ping 10.88.2.1 source loopback 0 repeat 1000

 

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 10.88.2.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.1.1

!!!!!.

Success rate is 83 percent (5/6), round-trip min/avg/max = 268/318/408 ms

!

C2_A#ping 10.88.2.1 source lo0 repeat 1000

 

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 10.88.2.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.2.1

!!!!.

Success rate is 80 percent (4/5), round-trip min/avg/max = 272/341/416 ms

!

CORE#sh ip route vrf A | beg last

Gateway of last resort is not set

 

1.0.0.0/32 is subnetted, 1 subnets

O 1.1.1.1 [110/2] via 10.5.5.1, 01:12:30, FastEthernet1/1

10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks

O 10.1.1.0/30 [110/2] via 10.5.5.1, 01:12:30, FastEthernet1/1

C 10.5.5.0/30 is directly connected, FastEthernet1/1

L 10.5.5.2/32 is directly connected, FastEthernet1/1

S 10.88.0.0/16 [1/0] via 192.168.254.1, FastEthernet2/0

192.168.1.0/32 is subnetted, 1 subnets

O 192.168.1.1 [110/3] via 10.5.5.1, 01:12:30, FastEthernet1/1

192.168.2.0/32 is subnetted, 1 subnets

B 192.168.2.1 [20/100] via 10.5.5.1 (vrf12), 01:12:14, FastEthernet1/0

CORE#

==>5.5.5.1 (interessant)

==> hoffe ich habe nichts vergessen..

na ja mal sehen

 

 

hope this helps

 

ciao

Hi,

 

Routing zwischen VRF's ist nicht das Problem - die Frage ist was du genau machen willst? Haben die beiden Routinginstanzen die gleichen IP Ranges im Tranferbereich oder generell (wirklich?). Warum willst du in die globale RT routen?

 

cheers

Hi,

 

das solltest du auch mit sh mls qos int x/y statistics sehen.

 

ciao

Hi,

 

unter der line:

 

line con [vty] x [y]

trans pref ssh

!

dann wird falls unter router>#1.1.1.1 eingegeben wird ssh 1.1.1.1 ausgeführt. mit trans pref none ist es möglich dieses verhalten zu deaktivieren. dann muss man ssh -l ... 1.1.1.1 angeben und (1.1.1.1 geht nicht mehr)..

 

hope this helps

 

ciao

Hi,

 

na ja - für features, die man nicht benötigt muss man halt zahlen - wer weiß ob diese features nicht doch mal benötigt werden - dann ist man wenigstens auf der sicheren seite :-) [consulting modus on - nicht "ganz" ernst nehmen..]

 

cheers

Hi ShineDaStar,

 

sollte hier nicht eher ein SVI als MGMT Interface (oder Loopback :-)) definiert sein? Management wirst du ja über das LAN machen wollen, oder?

 

cheers

Der 3550 ist definitv ein L3, habe selber einen zuhause.

 

Ich würde es auch mit einem Loopbackinterface probieren.

 

mfg

 

Natürlich macht ein Loopback Interface auch sinn. Man benötigt jedoch eine weitere IP Adresse die ggf im Distri Bereich geroutet werden muss. no autostate würde das gleiche Ergebnis bringen..

 

cheers