AUF DIESER SEITE
Teil 3: Konfigurieren der Anwendungsqualität mit SD-WAN
Übersicht
In diesem Abschnitt konfigurieren Sie AppQoE (Application Quality Experience) auf der SRX. AppQoE verbessert die Benutzererfahrung auf Anwendungsebene. Leistungssonden überwachen ständig Die Quality of Service Parameter und die Einhaltung der Service Level Agreement (SLA) des Anwendungsdatenverkehrs. Das Ergebnis ist, dass der Anwendungsdatenverkehr immer den SLA-konformsten Link verwendet, der verfügbar ist.
Betrachten wir die in Tabelle 1 aufgeführten Anwendungen. In diesem Beispiel gelten die Anwendungen Office365, Salesforce und Zoom als geschäftskritisch für das Unternehmen. Alle kritischen Anwendungen sollten über den privaten WAN-Link geroutet werden, wenn dieser die SLA-Anforderungen der Anwendung erfüllt. Kritische Anwendungen nutzen auch den LTE-Link, wenn alle anderen Verbindungen ausfallen.
Die restlichen Anwendungen nutzen den Breitband-Internetzugangslink als primäre Verbindung. Da nur geschäftskritische Anwendungen den LTE-Backup-Link verwenden können, sind die nichtkritischen Anwendungen nicht zugänglich, wenn nur die LTE-Verbindung verfügbar ist.
Anwendung |
Primäre Verbindung |
Sekundäre Verbindung |
Geschäftskritisch? |
---|---|---|---|
Office365 |
Privates WAN |
Breitband-Internet |
Ja |
Salesforce |
Privates WAN |
Breitband-Internet |
Ja |
Zoom |
Privates WAN |
Breitband-Internet |
Ja |
Slack |
Breitband-Internet |
Privates WAN |
Nein |
Gotomeeting |
Breitband-Internet |
Privates WAN |
Nein |
Dropbox |
Breitband-Internet |
Privates WAN |
Nein |
Skype |
Breitband-Internet |
Privates WAN |
Nein |
Youtube |
Breitband-Internet |
Privates WAN |
Nein |
Sie konfigurieren AppQoE für eine geschäftskritische und eine nichtkritische Anwendung, um den Fokus auf das Beispiel zu behalten. Sie können die Konfiguration einfach anpassen, um zusätzliche Anwendungen zu unterstützen, indem Sie den gewünschten Sondierungstyp und den gewünschten Zieldomänennamen oder -ip-Adresse angeben.
Schritt-für-Schritt-Prozedur
-
Erstellen Sie Zeitleistungsüberwachungssonden für Office 365. Office 365 ist eine wichtige Anwendung gemäß Tabelle 1. Wir haben eine Probe eingerichtet, um die Konnektivität zu der von Office365 verwendeten IP-Adresse, insbesondere 40.97.223.114, zu testen. Die Probe ist so konfiguriert, dass 5 Ping-basierte Sondierungen im Abstand von 6 Sekunden auf der privaten WAN-Verbindung gesendet werden. Wir konfigurieren auch die Schwellenwerte, die nicht verletzt werden sollten, wie z. B. den Verlust von 5 aufeinanderfolgenden Sondierungen oder eine Probe Round Trip Transit Time (RTT) über 300000 Mikrosekunden. Die IP-Adresse des Gateways auf der Schnittstelle ge-0/0/3 lautet 192.168.220.1.
set services rpm probe office365_rpm_primary test office365_test_primary probe-type icmp-ping set services rpm probe office365_rpm_primary test office365_test_primary target address 40.97.223.114 set services rpm probe office365_rpm_primary test office365_test_primary probe-count 5 set services rpm probe office365_rpm_primary test office365_test_primary probe-interval 6 set services rpm probe office365_rpm_primary test office365_test_primary thresholds successive-loss 5 set services rpm probe office365_rpm_primary test office365_test_primary thresholds rtt 300000 set services rpm probe office365_rpm_primary test office365_test_primary destination-interface ge-0/0/3.0 set services rpm probe office365_rpm_primary test office365_test_primary next-hop 192.168.220.1
Tipp:Sie können das Probeziel als IP-Adresse oder mit einem Domänennamen eingeben. Wenn ein Name angegeben wird, löst die Junos Software diesen automatisch auf die entsprechende IP-Adresse in der Konfiguration auf. Dieses Beispiel zeigt ICMP-basierte Sondierungen. Es gibt andere Probetypen, z. B. http-get. Nicht alle Standorte reagieren auf ICMP Echo Request (Ping)-Nachrichten. Achten Sie darauf, einen Probetyp zu verwenden, der vom Anwendungsanbieter unterstützt wird.
-
Erstellen Sie die zweite Probe für dieselbe Anwendung, um die sekundäre Verbindung mithilfe der sekundären Schnittstelle zu untersuchen. Die IP-Adresse des Standard-Gateways auf dem Breitband-Internet-Link ist 172.16.1.1.
set services rpm probe office365_rpm_secondary test office365_test_secondary probe-type icmp-ping set services rpm probe office365_rpm_secondary test office365_test_secondary target address 40.97.223.114 set services rpm probe office365_rpm_secondary test office365_test_secondary probe-count 5 set services rpm probe office365_rpm_secondary test office365_test_secondary probe-interval 6 set services rpm probe office365_rpm_secondary test office365_test_secondary thresholds successive-loss 5 set services rpm probe office365_rpm_secondary test office365_test_secondary thresholds rtt 300000 set services rpm probe office365_rpm_secondary test office365_test_secondary destination-interface ge-0/0/2.0 set services rpm probe office365_rpm_secondary test office365_test_secondary next-hop 172.16.1.1
-
In ähnlicher Weise erstellen Sie zwei Sondierungen für die Skype-Anwendung. Skype ist gemäß Tabelle 1 keine geschäftskritische Anwendung. Wir benötigen eine strengere Servicelevel-Garantie für diese (aber nicht kritische) Echtzeitanwendung. Insbesondere konfigurieren Sie ein kürzeres Probe-Intervall von 1 Sekunde und einen kürzeren RTT-Schwellenwert von 6.000 Mikrosekunden.
Hinweis:Wir richten die primären und sekundären Sondierungen auf der Schnittstelle basierend darauf ein, ob die Anwendung geschäftskritisch ist. Die Schnittstelle und die IP-Adresse für die primäre Probe für nichtkritische Anwendungen (Skype) unterscheiden sich von der Probe für die kritische Anwendung (Office365).
set services rpm probe skype_rpm_primary test skype_test_primary probe-type icmp-ping set services rpm probe skype_rpm_primary test skype_test_primary target address 13.107.8.2 set services rpm probe skype_rpm_primary test skype_test_primary probe-count 5 set services rpm probe skype_rpm_primary test skype_test_primary probe-interval 1 set services rpm probe skype_rpm_primary test skype_test_primary thresholds successive-loss 5 set services rpm probe skype_rpm_primary test skype_test_primary thresholds rtt 60000 set services rpm probe skype_rpm_primary test skype_test_primary destination-interface ge-0/0/2.0 set services rpm probe skype_rpm_primary test skype_test_primary next-hop 172.16.1.1 set services rpm probe skype_rpm_secondary test skype_test_secondary probe-type icmp-ping set services rpm probe skype_rpm_secondary test skype_test_secondary target address 13.107.8.2 set services rpm probe skype_rpm_secondary test skype_test_secondary probe-count 5 set services rpm probe skype_rpm_secondary test skype_test_secondary probe-interval 1 set services rpm probe skype_rpm_secondary test skype_test_secondary thresholds successive-loss 5 set services rpm probe skype_rpm_secondary test skype_test_secondary thresholds rtt 60000 set services rpm probe skype_rpm_secondary test skype_test_secondary destination-interface ge-0/0/3.0 set services rpm probe skype_rpm_secondary test skype_test_secondary next-hop 192.168.220.1
-
Erstellen Sie für jede Anwendung eine Routing-Instanz. Wir konfigurieren die Route einer Anwendung für den primären Link mit einem niedrigeren Präferenzwert als der Backup-Link. Routen mit einem niedrigeren Präferenzwert haben vorrang vor Routen mit höherem Wert. Sie schließen die LTE-Backup-Schnittstelle nur für geschäftskritische Anwendungen ein.
Die Routing-Instanz für Office365 legt einen Routeneinstellungswert von 10 für das private WAN-Gateway (bevorzugte Route) fest. Ein Bevorzugter Wert von 20 für den Breitband-Internet-Link (nächste bevorzugte Route). Und ein Bevorzugter Wert von 30 für den LTE-Backup-Link (die am wenigsten bevorzugte Route).
set routing-instances office365_RInstance instance-type forwarding set routing-instances office365_RInstance routing-options static route 0/0 qualified-next-hop 192.168.220.1 preference 10 set routing-instances office365_RInstance routing-options static route 0/0 qualified-next-hop 172.16.1.1 preference 20 set routing-instances office365_RInstance routing-options static route 0/0 qualified-next-hop dl0.0 preference 30
-
Konfigurieren Sie die Routing-Instanzen für die Slack-Anwendung in einem ähnlichen Muster. Diese nichtkritische Anwendung umfasst nicht die LTE-Schnittstelle in der Routing-Instanz. Das Weglassen der LTE-Schnittstelle verhindert, dass nichtkritische Anwendungen den LTE-Backup-Link verwenden. Beachten Sie auch, wie die statischen Routeneinstellungen dazu führen, dass diese Anwendung das Breitband-Internet als primäre Verbindung verwendet.
set routing-instances slack_RInstance instance-type forwarding set routing-instances slack_RInstance routing-options static route 0/0 qualified-next-hop 172.16.1.1 preference 10 set routing-instances slack_RInstance routing-options static route 0/0 qualified-next-hop 192.168.220.1 preference 20
-
Konfigurieren Sie IP-Überwachungsrichtlinien für die Anwendungen. Ziel der Richtlinien ist es, die Metrik der Standardrouten in den Routing-Instanzen dynamisch zu ändern. Die Richtlinien werden pro Probe ausgeführt.
In diesem Schritt erstellen wir die IP-Überwachungsrichtlinie für die Office365-Anwendung. Für Office365 konfigurieren wir zwei Sondierungen und erstellen zwei Richtlinien – eine für jeden Test. Wenn die Probe feststellt, dass der Anwendungsdatenverkehr den konfigurierten Schwellenwert für eine Verbindung überschritten hat, ändert die Richtlinie die Präferenz der Routen. Die Richtlinie reduziert die Metrik für den zweitbeste Link auf 2. Diese Änderung leitet den Datenverkehr in der Routing-Instanz an den Backup-Link.
Wenn beispielsweise die Probe feststellt, dass die primäre Verbindung für Office365, der private WAN-Link, die Anforderungen für RTT und Verlust nicht erfüllt, ändert die Richtlinie die Kennzahl des Gateways für die Breitband-Internetverbindung (nächste bevorzugte Route) in einen Wert von 2.
set services ip-monitoring policy office365_ipm_primary match rpm-probe office365_rpm_primary set services ip-monitoring policy office365_ipm_primary then preferred-route routing-instances office365_RInstance route 0/0 next-hop 172.16.1.1 set services ip-monitoring policy office365_ipm_primary then preferred-route routing-instances office365_RInstance route 0/0 preferred-metric 2
-
Konfigurieren Sie die IP-Überwachungsrichtlinie für die sekundäre Probe für Office365.
Hinweis:Die Next-Hop-Adresse ist die IP-Adresse für den primären privaten WAN-Link.
set services ip-monitoring policy office365_ipm_secondary match rpm-probe office365_rpm_secondary set services ip-monitoring policy office365_ipm_secondary then preferred-route routing-instances office365_RInstance route 0/0 next-hop 192.168.220.1 set services ip-monitoring policy office365_ipm_secondary then preferred-route routing-instances office365_RInstance route 0/0 preferred-metric 2
-
Konfigurieren Sie die IP-Überwachungsrichtlinie für die Slack-Anwendung.
set services ip-monitoring policy slack_ipm_primary match rpm-probe slack_rpm_primary set services ip-monitoring policy slack_ipm_primary then preferred-route routing-instances slack_RInstance route 0/0 next-hop 192.168.220.1 set services ip-monitoring policy slack_ipm_primary then preferred-route routing-instances slack_RInstance route 0/0 preferred-metric 2 set services ip-monitoring policy slack_ipm_secondary match rpm-probe slack_rpm_secondary set services ip-monitoring policy slack_ipm_secondary then preferred-route routing-instances slack_RInstance route 0/0 next-hop 172.16.1.1 set services ip-monitoring policy slack_ipm_secondary then preferred-route routing-instances slack_RInstance route 0/0 preferred-metric 2
-
Konfigurieren Sie ein erweitertes richtlinienbasiertes Routing (APBR)-Profil. Ihr APBR-Profil entspricht beiden Anwendungen, die in diesem Beispiel verwendet werden. Das Profil leitet den abgleichenden Datenverkehr an die jeweilige Routing-Instanz weiter. Das Profil verwendet Regeln, wobei jede Regel eine Anwendung und eine Routing-Instanz abdeckt. In diesem Beispiel konfigurieren wir eine Regel namens office365_rule, die den gesamten Datenverkehr für die Anwendung mit dem Namen "junos:OFFICE365-CREATE-CONVERSATION" entspricht, und leiten den Datenverkehr an die Routing-Instanz mit dem Namen office365_RInstance. Die Slack-Anwendung wird wie in der Mode eingereicht.
Hinweis:APBR erfordert eine appid-sig-Lizenz. Ohne die Lizenz erhalten Sie einen Commit-Fehler. Weitere Informationen finden Sie im Abschnitt "Anforderungen".
set security advance-policy-based-routing tunables max-route-change 0 set security advance-policy-based-routing profile apbr_profile rule office365_rule match dynamic-application junos:OFFICE365-CREATE-CONVERSATION set security advance-policy-based-routing profile apbr_profile rule office365_rule then routing-instance office365_RInstance set security advance-policy-based-routing profile apbr_profile rule slack_rule match dynamic-application junos:SLACK set security advance-policy-based-routing profile apbr_profile rule slack_rule then routing-instance slack_RInstance
Hinweis:Um die Anwendungskontinuität zu gewährleisten und die Benutzer nicht zu beeinträchtigen, möchten wir Änderungen des Pfads in der Mittleren Sitzung für etablierte Sitzungen ablehnen. Sie setzen den
max-route-change
Parameter auf 0, um Änderungen an etablierten Sitzungen zu verhindern.Tipp:Die Junos-Software unterstützt eine umfangreiche Liste dynamisch erkannter Anwendungen. Die Anwendungsidentifizierung bietet Einen Überblick über die Anwendungen in Ihrem Netzwerk und zeigt Ihnen die Funktionsweise der Anwendung, ihre Verhaltenseigenschaften und ihr relatives Risiko. App ID nutzt zahlreiche Mechanismen, um die Anwendungen in Ihrem Netzwerk zu erkennen. App-ID funktioniert unabhängig von Port, Protokoll, Verschlüsselung (TLS/SSL oder SSH) oder anderen Ausweichmanövern. Weitere Informationen finden Sie unter Anwendungsidentifizierung.
-
Konfigurieren Sie eine protokollunabhängige Gruppe von Routing-Tabellen. Diese Konfiguration kopiert die Schnittstellenrouten zu den verschiedenen Anwendungs-Routing-Instanzen. Kopien dieser Route ermöglichen einer bestimmten Instanz die Nutzung des privaten WAN oder der Breitband-Internetverbindungen. Denken Sie daran, dass Sie beide Schnittstellen in der Hauptroutinginstanz definiert haben.
set routing-options interface-routes rib-group inet apbr_rib_group set routing-options rib-groups apbr_rib_group import-rib inet.0 set routing-options rib-groups apbr_rib_group import-rib office365_RInstance.inet.0 set routing-options rib-groups apbr_rib_group import-rib slack_RInstance.inet.0
-
Fügen Sie das neu erstellte Profil apbr_profile der Sicherheitszonen-Vertrauensstellung hinzu. Diese Konfiguration wendet das Profil auf den Datenverkehr in der Zone an.
set security zones security-zone trust advance-policy-based-routing-profile apbr_profile
-
Commit der Konfiguration und Rückkehr in den Betriebsmodus.
commit and quit
Überprüfung der Anwendungsqualität
Zweck
Bestätigen Sie, dass APBR gemäß den Zielen dieses Beispiels funktioniert.
Aktion
Generieren Sie eine Mischung aus geschäftskritischem und nicht kritischem Datenverkehr von einem kabelgebundenen oder drahtlosen Client. Führen Sie dann die Befehle in diesem Abschnitt aus, um zu überprüfen, ob ABPR ordnungsgemäß funktioniert.
Beginnen Sie mit der Bestätigung, dass die RPM-Probes sowohl auf primären als auch auf sekundären Verbindungen erfolgreich sind. Um Platz zu sparen, zeigen wir nur die Sondierungen für die kritische Anwendung. Alle Sondierungen sollten zu diesem Zeitpunkt erfolgreich sein. Zeigen Sie die Ergebnisse der RPM-Probes mit den show services rpm probe-results owner office365_rpm_primary
(und sekundären) Befehlen an.
root@Mist-SRX-GW# show services rpm probe-results owner office365_rpm_primary Owner: office365_rpm_primary, Test: office365_test_primary Target address: 40.97.223.114, Probe type: icmp-ping, Icmp-id: 79 Destination interface name: ge-0/0/3.0 Test size: 5 probes Probe results: Response received Probe sent time: Mon Jun 7 15:58:28 2021 Probe rcvd/timeout time: Mon Jun 7 15:58:28 2021, No hardware timestamps Rtt: 3321 usec, Round trip jitter: -185 usec Round trip interarrival jitter: 1026 usec . . . root@Mist-SRX-GW# show services rpm probe-results owner office365_rpm_secondary Owner: office365_rpm_secondary, Test: office365_test_secondary Target address: 40.97.223.114, Probe type: icmp-ping, Icmp-id: 79 Destination interface name: ge-0/0/2.0 Test size: 5 probes Probe results: Response received Probe sent time: Mon Jun 7 15:58:37 2021 Probe rcvd/timeout time: Mon Jun 7 15:58:37 2021, No hardware timestamps Rtt: 3402 usec, Round trip jitter: 73 usec Round trip interarrival jitter: 424 usec . . .
Die Ausgabe bestätigt, dass die kritischen Sondierungen für Geschäftsanwendungen derzeit sowohl auf den primären als auch auf den sekundären Verbindungen erfolgreich sind. Sie erwarten ähnliche Ergebnisse für die nichtkritischen Anwendungssonden, wobei die primären und sekundären Schnittstellen umgekehrt sind.
Zeigen Sie als Nächstes eine Routing-Instanz an, um den Weiterleitungsstatus zu überprüfen, wenn sowohl primäre als auch sekundäre Schnittstellen in Betrieb sind. Gibt den show route table <instance-name>
Befehl sowohl für kritische als auch für nichtkritische Anwendungen aus.
root@Mist-SRX-GW# show route table office365_RInstance office365_RInstance.inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/10] 03:34:36 > to 192.168.220.1 via ge-0/0/3.0 [Static/20] 03:11:34 > to 172.16.1.1 via ge-0/0/2.0 [Static/30] 03:34:36 > via dl0.0 10.10.20.0/24 *[Direct/0] 03:34:36 > via ge-0/0/4.20 10.10.20.1/32 *[Local/0] 03:34:36 Local via ge-0/0/4.20 10.10.30.0/24 *[Direct/0] 03:34:36 > via ge-0/0/4.30 . . . root@Mist-SRX-GW# show route table office365_RInstance slack_RInstance.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/10] 03:23:32 > to 172.16.1.1 via ge-0/0/2.0 [Static/20] 03:46:34 > to 192.168.220.1 via ge-0/0/3.0 10.10.20.0/24 *[Direct/0] 03:46:34 > via ge-0/0/4.20 10.10.20.1/32 *[Local/0] 03:46:34 Local via ge-0/0/4.20 10.10.30.0/24 *[Direct/0] 03:46:34 > via ge-0/0/4.30 10.10.30.1/32 *[Local/0] 03:46:34 . . .
Die Ausgabe bestätigt, dass der als Office 365 klassifizierte Datenverkehr den privaten WAN-Link verwendet. Als geschäftskritische Anwendung verfügt die Routing-Instanz sowohl über einen sekundären als auch über einen tertiären next Hop. Wenn die ersten beiden nächsten Hops nicht mehr verfügbar sind, fällt der kritische Datenverkehr an das LTE-Modem. Im Gegensatz dazu nutzt die nichtkritische Anwendung den Breitband-Internet-Link, um den Datenverkehr weiterzuleiten. Wenn dieser nächste Hop ausfällt, leitet die Instanz den Datenverkehr an das private WAN. Das LTE-Modem ist in dieser Routing-Instanz nicht aufgeführt. Diese Auslassung verhindert, dass nichtkritische Anwendungen den LTE-Link verwenden.
Erinnern Sie sich daran, dass die SLA-Überwachungs-Sondierungen über das Internet zum Anwendungsanbieter laufen. Die End-to-End-Natur der Sondierungen ermöglicht es dem SRX, die End-to-End-Leistung der Anwendung zu messen. Die Messung der "Erfahrung auf Anwendungsebene" steht im Gegensatz dazu, einfach Link- oder Next-Hop-Ausfälle anhand des Schnittstellenstatus bzw. der bidirektionalen Weiterleitungserkennung (BFD) zu erkennen.
Optional: Unterbrechung der RPM-Sondierungen zur Bestätigung kritischer Datenverkehr über den Breitband-Internet-Link. Sie können SLA-Probe-Ausfälle mit einem Firewall-Filter simulieren, der in Ausgaberichtung auf die private WAN-Schnittstelle des SRX-Geräts angewendet wird.
set interfaces ge-0/0/3 unit 0 family inet filter output block_ping set firewall filter block_ping term 1 from destination-address 40.97.223.114/32 set firewall filter block_ping term 1 from protocol icmp set firewall filter block_ping term 1 then count ping set firewall filter block_ping term 1 then discard set firewall filter block_ping term 2 then accept
Mit dem Filter auf dem privaten WAN-Link erwarten Sie, die kritische Anwendung über den Breitband-Internet-Link zu finden.
root@Mist-SRX-GW# show services rpm probe-results owner office365_rpm_primary Owner: office365_rpm_primary, Test: office365_test_primary Target address: 40.97.223.114, Probe type: icmp-ping, Icmp-id: 93 Destination interface name: ge-0/0/3.0 Test size: 5 probes Probe results: Internal error Probe sent time: Mon Jun 7 16:49:14 2021 Probe rcvd/timeout time: Mon Jun 7 16:49:14 2021 Results over current test: Probes sent: 4, Probes received: 0, Loss percentage: 100.000000 . . . root@Mist-SRX-GW# show route table office365_RInstance office365_RInstance.inet.0: 13 destinations, 16 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/2] 00:04:30, metric2 0 > to 172.16.1.1 via ge-0/0/2.0 [Static/10] 04:08:08 > to 192.168.220.1 via ge-0/0/3.0 [Static/20] 03:45:06 > to 172.16.1.1 via ge-0/0/2.0 [Static/30] 04:08:08 > via dl0.0 10.10.20.0/24 *[Direct/0] 04:08:08 > via ge-0/0/4.20 . . .
Da die primären Sondierungen nun ausfällt, hat die SLA-Überwachungsrichtlinie die statische Routenpräferenz in der kritischen Anwendungs-Routing-Instanz angepasst. Das Ergebnis sind die kritischen Datenverkehrsströme über den Breitband-Internet-Link. Dieses Verhalten bestätigt den ordnungsgemäßen Betrieb der IP SLA-Leistungsüberwachung.
Vergessen Sie nicht, die Änderung der Firewall-Filter an der SRX zurück zu setzen! Nach dem Rollback erwarten Sie, dass die kritische Anwendungs-Routing-Instanz erneut über den privaten WAN-Link weitergeleitet wird.
Sie können apBR-Datenverkehrsstatistiken mit dem show security advance-policy-based-routing statistics
Befehl überwachen.
user@host>show security advance-policy-based-routing statistics
Advance Profile Based Routing statistics:
Sessions Processed 1930640
App rule hit on cache hit 4540
App rule hit on HTTP Proxy/ALG 0
Midstream disabled rule hit on cache hit 0
URL cat rule hit on cache hit 0
DSCP rule hit on first packet 92693
App and DSCP hit on first packet 0
App rule hit midstream 0
Midstream disabled rule hit midstream 0
URL cat rule hit midstream 0
App and DSCP rule hit midstream 0
DSCP rule hit midstream 0
Route changed on cache hits 97233
Route changed on HTTP Proxy/ALG 0
Route changed midstream 0
Zone mismatch 0
Drop on zone mismatch 0
Next hop not found 0
Application services bypass 0
Die Ausgabe zeigt die statistischen Details für APBR an. Die Details umfassen die Anzahl der Sitzungen, die von der APR-Regel verarbeitet werden, und die Anzahl der Male, wie der Anwendungsdatenverkehr mit dem APBR-Profil übereinstimmt (Regeltreffer).
Bedeutung
Die in diesem Abschnitt gezeigten Befehle und Ausgaben bestätigen, dass APBR auf dem SRX Services Gateway ordnungsgemäß funktioniert. Ihre neue Zweigstelle, die über die Juniper Mist Cloud verwaltet wird, ist bereit für den Geschäftsbetrieb.