Dalawang bridge-domain sa isang IOS XR group ay hindi isang LAN
Ang paglalagay ng dalawang bridge-domain sa ilalim ng isang bridge-group ay hindi nagsasama ng kanilang forwarding. Basahin ang group, ang domain at ang bawat attachment bilang magkahiwalay na patong.
Dalawang host sa parehong IOS XR router ay hindi makapag-ping sa isa't isa, at ang configuration ay mukhang dapat nila. Parehong subinterface ay lumilitaw sa ilalim ng parehong bridge-group, isang letra lang ang pagkakaiba ng mga pangalan, at ang commit ay dumaan nang walang reklamo. Ang kulang ay isang antas ng hierarchy: ang bridge-group ay isang lalagyan, at ang bawat bridge-domain sa loob nito ay sarili nitong broadcast domain na may sariling pagiging kasapi. Magdagdag ng ikatlong host at kadalasan ay lumalala ang larawan sa halip na luminaw.
| Object | Owns | Does not own |
|---|---|---|
| Bridge group | a named container for domains | any forwarding or MAC learning |
| Bridge domain | one broadcast domain, MAC table, flooding scope | the VLAN match on an ingress port |
| Attachment | which frames from which interface and tag enter the domain | which other domains they can reach |
Magsimula sa sintomas at magbasa pataas
Ang mga host na nabibigo sa loob ng isang subnet habang ang mga interface ay nag-uulat ng up at ang mga ARP entry ay hindi kailanman napupuno ay tanda ng problema sa pagiging kasapi sa domain, hindi ng problema sa routing. Ang mga problema sa routing ay karaniwang nagbibigay ng ICMP unreachable o next hop na umiiral; ang nawawalang broadcast domain ay nagbibigay ng katahimikan sa ikalawang antas. Suriin kung ang dalawang attachment ay nasa parehong bridge-domain bago tingnan ang kahit isang IP address. Kung wala, walang dami ng trabaho sa addressing ang mag-uugnay sa kanila.
Ang bridge-group ay isang lalagyan lamang, wala nang iba
Sa IOS XR hierarchy ng layer 2 VPN, ang isang bridge-group ay may hawak na isa o higit pang bridge-domain, at ang group mismo ay hindi nagsi-switch ng anuman. Dalawang domain sa ilalim ng isang group ay magkakapatid, hindi kasapi ng isang LAN, kahit ang configuration ay parang naka-nest sila. Ang layout na iyon ay sinasadya: ang group ang lugar kung saan inoorganisa mo ang mga serbisyo, at ang domain ang lugar kung saan talagang nangyayari ang forwarding.
Inilalarawan ng gabay ng Cisco para sa multipoint na serbisyo sa layer 2 ang bridge-domain bilang isang broadcast domain na may hawak na pisikal o virtual na port, nagsi-switch ayon sa destination MAC, nag-aaral ng source address at nagbabaha ng hindi kilalang unicast, broadcast at multicast sa loob lamang ng domain na iyon. Basahin ang hierarchy sa gabay na iyon bago basahin ang sarili mong configuration.
Pagmamay-ari ng bridge-domain ang forwarding at pagkatuto
Ang pagkatuto ng MAC ay saklaw lamang ng domain, kaya ang istasyong natutunan sa isang domain ay hindi nakikita sa kapatid na domain. Ang pagbaha ay sumusunod sa parehong hangganan, kaya ang broadcast na ipinadala ng isang host ay hindi kailanman umabot sa host sa kabilang domain. Ang mga split-horizon group sa loob ng isang domain, estado ng kasapi at anumang naka-configure na kontrol sa forwarding ay lalong nagpapakitid sa mga karapat-dapat na output.
Ang pseudowire o virtual forwarding instance ay isang attachment ng serbisyo sa isang domain. Hindi ito kasingkahulugan ng magulang na bridge-group, at ang ituring itong gayon ay kung paano nauuwi ang isang provider edge na may dalawang serbisyong dapat sanay nakahiwalay at hindi naman.
Ang attachment ang nagpapasya kung aling mga frame ang darating
Sa ilalim ng domain ay ang attachment: ang interface o subinterface, ang encapsulation na tinutugma nito, anumang operasyon sa tag, at ang domain na sinasamahan nito. Ang subinterface na ang numero ay nagkataong mukhang VLAN ay hindi kontrata ng frame, at ang parehong pisikal na port ay makapagpapakain ng dalawang domain na may dalawang magkaibang tugma. Isulat ang ingress interface, tugmang tag, aksyon sa tag at target na domain, pagkatapos ay isulat nang hiwalay ang egress side.
Ihambing ang kontratang iyon sa pagitan ng dalawang serbisyo bago ilipat ang configuration. Kapag ang dalawang domain ay nasa ilalim ng isang group at isa lamang sa kanila ang may dala ng trapiko, ang pagkakaiba ay halos palaging nasa attachment at hindi sa domain.
Kung ang disenyo ay nagra-route rin sa pagitan ng subnet, ang attachment sa layer 3 ay isa pang bagay na may sariling gateway address at patakaran. Walang ipinapaliwanag ang pangalan ng bridge-domain tungkol sa kung aling gateway ang naglilingkod dito.
I-verify gamit ang naka-deploy na release bago muling ayusin
Gamitin ang sariling operational command ng release upang tingnan ang domain sa halip na ang tumatakbong configuration. show l2vpn bridge-domain detail ay nag-uulat ng mga domain at estado ng kanilang attachment, at ang show l2vpn forwarding bridge-domain na may mga opsyon sa MAC ay nagpapakita kung ano ang natutunan at saan. Kung ang isang MAC address ay lumitaw sa isang domain at hindi sa kapatid nito, ginagawa ng hierarchy ang eksaktong itinakda para gawin.
Pagkatapos ay iimbentaryo ang bawat domain at attachment sa ilalim ng group bago magbago ng anuman, at panatilihin ang umiiral na configuration para sa paghahambing. Ang isang pamilyar na pangalan ng bagay ay hindi ebidensya na ang bawat naka-nest na serbisyo ay nagbabahagi ng saklaw nito.