Výběr Cisco ISG VRF (9)

Tento obvod byl sestaven v laboratoři, ale byl navržen pro reálný projekt, tzn. – žádné kulové ISG ve vakuu.

Оборудование

• Úroveň přístupu (fyzické připojení účastníků): katalyzátor 3550.
• Úroveň agregace (kombinující několik přepínačů přístupové úrovně plus ukončení účastníků přes L3): katalyzátor 3550, s následným nahrazením 3560, jak se síť rozrůstá.
• Jádro sítě: katalyzátor 6509 (WS-SUP720-3BXL)
• BRAS (ISG): ASR1002-ESP5

Připojte účastníka přes IPoE (bez dodatečného zapouzdření PPPoE nebo PPTP), zadejte adresu přes DHCP, autorizujte účastníka číslem portu na odpovídajícím katalyzátoru přístupové úrovně, omezte přístup k internetu v souladu se zůstatkem smlouvy.

Nevýhody schématu a jeho realizace

• Jedna IP na účastníka (pro připojení více zařízení si účastník musí zakoupit CPE – libovolný ethernetový router s NAT), protože implementace Cisco ISG vytváří relaci na základě jedinečnosti zdrojové IP.
• Složitější mechanismus škálování BRAS ve srovnání s PPPoE.
• Doma neexistuje žádná místní síť – veškerý provoz jde přes jádro.

• V nejjednodušším případě (jeden PC) nemusí účastník vůbec nic konfigurovat, stačí zasunout kabel.
• Transportní síť není zahlcena MAC adresami účastníků (při počtech větších než 8-12 tisíc MAC je nutné přejít na výrazně dražší hardware)
• Vysoká bezpečnost sítě a účastníka (izolace VLAN-per-user, „fyzická“ autorizace účastníka pomocí dhcp-snooping, anti-spoofing díky ip source guard, dynamické /32 trasy na SVI vytvořené až po úspěšné autorizaci, izolace od zbytku sítě uvnitř VRF).
• Žádné další zapouzdření v protokolu PPP, které uvolňuje BRAS.

Implementační funkce

• Získání IP adresy účastníkem a získání přístupu do sítě (jakási analogie „online“) jsou odděleny (i když jsou na sobě závislé). Výsledkem je, že v monitoru modulu Inet vidíme dvě relace na smlouvu: z jedné chápeme, že účastník obdržel IP adresu, z druhé chápeme, že používá síť (se správně vybraným Idle-Timeout). Pokud je na monitoru pouze jedna (dhcp) relace, znamená to, že účastník úspěšně prošel autorizací (tj. sedí na povoleném portu), ale v tuto chvíli nepotřebuje internet (nebo provoz nedosahuje BRAS). To je velmi výhodné pro analýzu. ISG session-restart funguje bez problémů, protože ISG session je autorizována zdrojovou-IP, kterou již účastník má (při autorizaci ISG session přímo volbou82 by bylo nutné znovu zažádat o IP, aby se požadavek dhcp dostal do BRAS). V důsledku toho můžete svou relaci na Cisco bezpečně resetovat a být si jisti, že se okamžitě znovu zvýší s prvním paketem. Velmi pohodlné pro jakékoli řešení problémů. IMHO.
• Pokud je zůstatek ISG záporný, relace se resetuje a vytvoří se nová (neautorizovaná) relace s časovačem a místními službami, které omezují přístup k účastníkovi. Tato relace je znovu autorizována na BGBilling každých N minut v naději, že předplatitel již dobil zůstatek. A – pokud je zůstatek opraven – začíná jako obvykle (se službami z vyúčtování, v souladu s tarifem). Pro ISG to není úplně ta pravá cesta. Správně – bez resetování relace z ní odebrat (přes CoA) aktuální tarifní služby ISG a přiřadit jiné (omezení přístupu) a při doplňování zůstatku – naopak. BGBilling to dokáže. Proč jsem to udělal jinak? Protože je vhodné vidět na Cisco předplatitele se záporným zůstatkem (jejich relace jsou neautorizované) a je vhodné sledovat opakované rádiusové požadavky na autorizaci. To je opět velmi výhodné pro rychlou analýzu a odstraňování problémů (proč tomuto předplatiteli nic nefunguje? Zde jsou protokoly). Opět IMHO.
• IP adresa pro účastníka může být přidělena staticky a/nebo dynamicky.

1. ISG, schéma se spuštěním relace a její autorizací IP, vydávání adres na základě volby82 (konfigurace sítě)
2. ISG, schéma se zahájením relace a její autorizací IP, vydávání adres na základě volby82 (konfigurace BGBilling)

«Výběr Cisco ISG + VRF»

Dobré odpoledne Existuje netriviální úkol, doufám, že uslyším vaše myšlenky.
Vzhledem k:
Cisco ISG s autentizací pomocí IP adresy a jedním rozhraním, za kterým se v routované síti nachází několik firemních účastníků.
Firemní předplatitelé musí mít svou vlastní osobní výchozí trasu, a proto bylo rozhodnuto umístit každého z nich do vlastního VRF.
Problém, že veškerý provoz přichází na jedno rozhraní, lze vyřešit pomocí výběru vrf, jako je: rozhraní GigabitEthernet0/0/1.125
popis TO_SUBSCRIBERS
zapouzdření dot1Q 125
ip vrf přijímat Subscriber1
ip vrf přijímat Subscriber2
ip vrf přijímat Subscriber3
Adresa IP 192.168.16.17 255.255.255.248
ip policy route-map ASTRA-3-VPN . ale funkce ISG na takovém rozhraní s PBR nefunguje. Po chvíli přemýšlení jsem nastavil dynamický výběr VRF vydáním atributu VRF prostřednictvím požadavku na poloměr a dostal jsem:
rozhraní GigabitEthernet0/0/1.125
popis TO_SUBSCRIBERS
zapouzdření dot1Q 125
Adresa IP 192.168.16.17 255.255.255.248
service-policy type control CUSTOMES-POLICY #Parametry jiné než IP jsou požadovány z okruhu
ip předplatitel směrován
iniciátor nezařazená ip adresa

rozhraní multiservice1
přesměrování ip vrf Předplatitel1
Adresa IP 10.10.100.1 255.255.255.252
žádné keepalive rozhraní multiservice2
přesměrování ip vrf Předplatitel2
Adresa IP 10.10.100.1 255.255.255.252
žádné keepalive rozhraní multiservice3
přesměrování ip vrf Předplatitel3
Adresa IP 10.10.100.1 255.255.255.252
žádné udržování naživu
Z okruhu vydávám něco takového: Sub1 Cleartext-Password := «xxx»
Typ služby = odchozí uživatel,
Framed-IP-Netmask = 255.255.255.0,
Cisco-AVPair += ‚ip:vrf-id=Subscriber1‘ #Takto umístíme předplatitele do VRF
A vše funguje až na jedno důležité ‚ALE‘ – instaluje se pouze relace IP, nikoli relace IP Subnet. Jinými slovy, nemohu vyvolat relaci s maskou podsítě účastníka vydáním atributu Framed-IP-Netmask přes stejný okruh. Po přečtení cisco.com jsem našel odpověď – buď dynamický výběr VRF, nebo relace IP podsítě 🙁
A štěstí bylo tak blízko. Tak si říkám, možná kopám na špatném místě? Jak jinak mohu zvládnout několik účastníků s jejich nepřekrývajícími se rozsahy podsítí, jejichž provoz je kvůli specifikům ukončen na jednom rozhraní. Předem děkuji za vaše myšlenky!

• Můžeš podrobněji popsat, proč chceš dát VRF do raziny? tsolodov (?), 15:09, 14. června 12, (1)
  • Chci to dát do různých VRF, aby provoz každého z firemních předplatitelů, Mom14 (ok), 16:03, 18. června, (12)
  • Rozuměl jsem správně, že VRF-ID mohu zadat nikoli v profilu předplatitele, ale ve službě? Mom14 (ok), 16:53, 18. června, (12)
    • gt přetaktování odstraněno PBR na Interface multiservice fungovalo, nefungovalo n, tsolodov (ok), 18:12, 18. června, (12)
      • gt přetaktování odstraněno Vytvořil podobnou konstrukční politiku-map typu se, Mom14 (ok), 11:01, 22. června, ( 6 )
      • Podařilo se vám vyřešit tento problém přetaktování gt odstraněno, Alexander (??), 11:09, 29. listopadu, ( 8 )
        • gt přetaktování odstraněno Ne, VRF Transfer funguje pouze s PPP nebo s IP relací, sansa82 (ok), 11:30, 29. listopadu-21, ( 9 )

        Můžeš podrobněji popsat, proč chceš dát VRF do raziny?

        > Můžete podrobněji popsat, proč chcete dát VRF do razinu?

        Chci je umístit do různých VRF, aby provoz každého firemního účastníka šel do jeho vlastního výstupního rozhraní a neprocházel obecným výchozím nastavením. Tzn., že by šlo udělat klasické PBR se zdrojovým routováním, pokud by to šlo.

        Udělal jsem podobné schéma, zde je moje konfigurace:
        http://tsolodov.blogspot.com/2011/09/bras-cisco-asr-1002-isg.

        Pro šedou síť ano, byl to průšvih, ale pro skutečné zákazníky jsem udělal síťovou relaci.

        Můžete se obejít bez VRF, jednoduše vytvořit politiku-route na dalším skoku, a i tak, kdybych měl vaši situaci, obešel bych se bez VRF vůbec, i když možná úplně nerozumím vašemu úkolu a schématu připojení.

        > Vytvořil jsem podobné schéma, zde je moje konfigurace:
        > http://tsolodov.blogspot.com/2011/09/bras-cisco-asr-1002-isg.
        > Pro šedou síť ano, byl to průšvih, ale udělal jsem to pro skutečné zákazníky
        > síťová relace.
        > Můžete se obejít bez VRF, stačí si na dalším skoku vytvořit politickou cestu,
        > a i kdybych měl vaši situaci, udělal bych to
        > Zvládl jsem to úplně bez VRF, i když tomu možná úplně nerozumím
        > váš úkol a schéma zapojení.

        Rozuměl jsem správně, že VRF-ID mohu uvést nikoli v profilu předplatitele, ale v zásadách služby, které také přidělím předplatiteli? Pokud ano, pak je to dobrá volba.
        Co nefungovalo s „šedou sítí“, nefungovalo PBR na multiservice Interface?

        Policy routing na next-hopu mi už částečně pomáhá, ale jen částečně, protože výstupní účastnická rozhraní nejsou vždy v dosahu next-hopu, jsou ta na druhé straně mpls cloudu a směrování takového provozu do MPLS L3VPN je ideální varianta.

        >[přehnané citace odstraněny]
        >> váš úkol a schéma zapojení.
        > Rozuměl jsem správně, že mohu zadat VRF-ID mimo profil předplatitele?
        > a v politice služby, kterou také přiřadím předplatiteli? pokud ano,
        > pak je to dobrá volba.
        > Směrování zásad na dalším skoku mi již částečně pomáhá, ale pouze
        > částečně proto, že výstupní účastnická rozhraní nejsou vždy v mezích
        > next-hop reach, tam jsou ti na druhé straně mpls cloudu a
        > směrování takového provozu do MPLS L3VPN je ideální.
        > Co nefungovalo u „šedé sítě“, nefungovalo PBR na rozhraní
        > multiservisní?

        PBR on Interface multiservice fungoval, síťová relace nefungovala.

        > Rozuměl jsem správně, že mohu zadat VRF-ID mimo profil předplatitele?
        > a v politice služby, kterou také přiřadím předplatiteli?

        Jaký to má smysl, když VRF ID pochází z okruhu?

        >[přehnané citace odstraněny]
        >> Směrování politik na dalším skoku mi již částečně pomáhá, ale pouze
        >> částečně proto, že výstupní účastnická rozhraní nejsou vždy v mezích
        >> next-hop reach, tam jsou ti na druhé straně mpls cloudu a
        >> směrování takového provozu do MPLS L3VPN je ideální.
        >> A co nefungovalo u „šedé sítě“, nefungovalo PBR na rozhraní
        >> multiservis?
        > PBR on Interface multiservice fungoval, síťová relace nefungovala.
        >> Rozuměl jsem správně, že mohu zadat VRF-ID mimo profil předplatitele?
        >> a v zásadě služby, kterou také přiřadím předplatiteli?
        > Jaký to má smysl, když VRF ID pochází z okruhu?

        Udělal jsem podobný design:

        služba VPN typu policy-map
        ip vrf předávání vpn
        sg-service-type-primary

        Služba VPN je registrována v profilu předplatitele. Vidím stejný obrázek. Relace předplatitele je vyvolána pouze pro hostitele, ale nikoli pro podsíť. Pokus o zadání masky podsítě předplatitele má za následek, že se služba jednoduše nepoužívá 🙁

        Vítejte
        Nastavil jsem to takto:

        rozhraní GigabitEthernet1 / 0.501
        popis TO_SUBSCRIBERS
        zapouzdření dot1Q 501
        Adresa IP 10.200.100.1 255.255.255.252
        kontrola typu zásady služby IPOE_COSTUMERS
        ip předplatitel směrován
        iniciátor nezařazená ip adresa

        rozhraní multiservice1
        ip vrf forwarding beeline
        Adresa IP 10.10.100.1 255.255.255.252
        žádné udržování naživu

        rozhraní GigabitEthernet2 / 0.401
        popis Beeline
        zapouzdření dot1Q 401
        ip vrf forwarding beeline
        Adresa IP 213.33.186.134 255.255.255.252

        ip trasa vrf beeline 0.0.0.0 0.0.0.0 213.33.186.133

        Poloměr:

        Cisco-AVPair += ‚ip:vrf-id=beeline‘

        vše funguje, ale provoz z internetu se nevrací přes rozhraní multiservice1 k účastníkovi.

        tento příkaz funguje:

        ping vrf beeline „IP účastníka“. (provoz opouští IP adresu rozhraní multiservice1)

        co jsem udělal špatně?

        Díky

        Podařilo se vám tento problém vyřešit?

        >[přehnané citace odstraněny]
        > IP adresa 213.33.186.134 255.255.255.252
        > ip trasa vrf beeline 0.0.0.0 0.0.0.0 213.33.186.133
        > Poloměr:
        > Cisco-AVPair += ‚ip:vrf-id=beeline‘
        > vše funguje, ale provoz z internetu se nevrací přes rozhraní multiservice1 do
        > předplatiteli.
        > tento příkaz funguje:
        > ping vrf beeline „IP účastníka“. (provoz opouští IP adresu rozhraní multiservice1)
        > co jsem udělal špatně?
        >Děkuji

        >[přehnané citace odstraněny]
        >> IP adresa 213.33.186.134 255.255.255.252
        >> ip trasa vrf beeline 0.0.0.0 0.0.0.0 213.33.186.133
        >> Poloměr:
        >> Cisco-AVPair += ‚ip:vrf-id=beeline‘
        >> vše funguje, ale provoz z internetu se nevrací přes rozhraní multiservice1 do
        >> předplatiteli.
        >> tento příkaz funguje:
        >> ping vrf beeline „IP účastníka“. (provoz opouští IP adresu rozhraní multiservice1)
        >> co jsem udělal špatně?
        >> Děkuji

        Ne,

        VRF Transfer funguje pouze s PPP nebo IP relací/DHCP.
        Nepoužívám dhcp.

        Vyřešil jsem to statickými VRF