Jump to content

Wordo

Members
  • Gesamte Inhalte

    3.213
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Wordo

  1. dialer-list permit blabla fehlt.

    Dann ist auch der dialer pool im dialer IF unnoetig.

     

    Ausserdem wuerde ich noch ein int vlan 2 machen, darauf die pppoe-client dialer-pool blabla

    setzen und dann die physikalischen switchports in vlan 2 legen.

     

    So mach ichs, und so funktionierts bei mir :D

  2. Mal noch eine Frage. Klappt eigentlich QoS genauso auf einem Interface auf dem ein crypto map ist? Kann ich da ganz normal drauf schapen oder CBWFQ einrichten wie auf einem "normal" interface?

     

    Fu

     

    Ja, bei VTI einfach die service-policy ans tunnel IF haenge, bei crypto maps musste qos-preclassify anfuegen. Aber VPN und QoS .. da kaempf ich jetzt schon ne Woche dran. :(

  3. So, es geht weiter. Nachdem ich auch unter Linux jetzt der absolute QoS-Checker bin hab ich mich an IPSec mit QoS und VoIP rangetraut.

     

    Szenario:

     

    Telefon - 871 mit QoS - 876 ADSL und Ipsec --- *Wolke* *Internetz* *boese* --- Linux mit IPSec - VoIP-Server

     

    So, wenn ich IPSec deaktiviere und den Traffic einfach natte (aber QoS aktiv) klappt alles wunderbar, ich strapazier den Upload und hab trotzdem super Laufzeiten.

     

    Sobald ich aber das VPN aktiviere knallt alles runter. Hab mal die MTU auf 1300 gedreht, witzlos. Schau mir die CPU der Router an, langweilig. Ja, sag mal, was gibts denn da noch? Das bisschen UDP???

     

    Jemand ne Idee?

     

    Merci

  4. Ich hab mit Multicast leider noch nicht wirklich was zu tun gehabt. Hier mal paar Ausschnitte vom aktuellen ASA Handbook (Aug. 2007):

     

    Forwarding Multicast Traffic

    IP multicast traffic must be forwarded from one network interface to another, just like any other

    Layer 3 packets are handled. The difference is in knowing where to forward the packets. For

    example, unicast IP packets have only one destination interface on a router or firewall (even if

    multiple paths exist). Multicast IP packets, however, can have many destination interfaces,

    depending on where the recipients are located.

    Cisco firewalls running PIX 6.2 or 6.3 have a limited multicast capability. They can act only as a

    multicast forwarding proxy, also known as a stub multicast router (SMR), depending on other

    routers in the network to actually route the multicast packets. The firewalls can determine where

    the multicast recipients are located on their own interfaces. They must be statically configured to

    forward the multicast traffic between a source and the recipients.

    Beginning with ASA 7.0 and FWSM 3.1(1), Cisco firewalls can participate in multicast routing

    by using the PIM routing protocol. This lets a firewall communicate with other PIM routers to

    distribute multicast traffic dynamically and along the best paths.

     

     

    Vielleicht kanns ja nur die ASA, aber die PIX eben nicht.

×
×
  • Neu erstellen...