Dit document beschrijft het pad dat door een IP-pakket wordt gebruikt wanneer het door een MPLS-enabled-ATM-kern reist en beschrijft de belangrijkste show-opdrachten.
Opmerking: de routers in dit document zijn afkomstig van de Cisco 3600-serie die Cisco IOS mobiele versie 12.0(7)T uitvoeren en OC-3 interfaces gebruiken. De ATM LSR is een 8540MSR.
Er zijn geen specifieke vereisten van toepassing op dit document.
De scenario's in dit document zijn gebaseerd op deze installatie. Zie deze voorbeeldconfiguratie om de configuraties voor deze apparaten te bekijken.
Leider is een interessante router in deze opstelling aangezien het etiketten aan de IP pakketten oplegt die van Ethernet komen. Omdat we werken aan een ATM-interface die is aangesloten op een ATM-kern die met MPLS is ingeschakeld, betekent het opgelegde label een doorgestuurd IP-pakket op een Tag VC (TVC).
In dit scenario, stuurt Pound IP pakketten naar Lira. Bijvoorbeeld, als u 125.125.0.2 van Pound pingt, werkt het zoals verwacht:
Pound#ping 125.125.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 125.125.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Vanuit de routingtabel van Guilder kunnen we eenvoudig zien dat de bestemming via de ATM-cloud kan worden bereikt:
Guilder#show ip route 125.125.0.2 Routing entry for 125.125.0.0/16 Known via "ospf 1", distance 110, metric 12, type inter area Redistributing via ospf 1 Last update from 129.129.0.2 on ATM1/0.1, 01:15:26 ago Routing Descriptor Blocks: * 129.129.0.2, from 120.120.0.1, 01:15:26 ago, via ATM1/0.1 Route metric is 12, traffic share count is 1
We hebben de ATM subinterface 1/0.1 ingesteld om de uitgaande IP-pakketten te labelen, zodat we meer informatie kunnen ontvangen in de Base Forkeing-tabel:
Guilder#show tag-switching forwarding-table 125.125.0.2 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 30 2/36 125.125.0.0/16 0 AT1/0.1 point2point MAC/Encaps=4/8, MTU=4470, Tag Stack{2/36(vcd=299)} 012B0900 0012B000
We zien nu dat Guilder de uitstroom van TVC VPI 2, VCI 36, die overeenkomt met VCD 299, oplegt. Deze informatie wordt opgeslagen in de CEF-verzendingstabel:
Guilder#show ip cef 125.125.0.2 detail 125.125.0.0/16, version 143, cached adjacency to ATM1/0.1 0 packets, 0 bytes tag information set local tag: 30 fast tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)} via 129.129.0.2, ATM1/0.1, 0 dependencies next hop 129.129.0.2, ATM1/0.1 valid cached adjacency tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)}
De IP-pakketten worden inderdaad op de juiste VC verzonden:
Guilder#show atm vc 299 ATM1/0.1: VCD: 299, VPI: 2, VCI: 36 UBR, PeakRate: 155000 AAL5-MUX, etype:0x8847, Flags: 0x40C84, VCmode: 0x0 OAM frequency: 0 second(s) InARP DISABLED Transmit priority 0 InPkts: 0, OutPkts: 5, InBytes: 0, OutBytes: 540 InPRoc: 0, OutPRoc: 0 InFast: 0, OutFast: 5, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0OAM cells received: 0OAM cells sent: 0 Status: UP Tag VC: local tag: 0
Zoals u ziet, zijn er slechts vijf IP-pakketten verzonden. Dit is gesynchroniseerd met het simpele pingelen dat we begonnen. Tegelijkertijd kun je je afvragen waarom we geen vijf ingangspakketten zien. Met andere woorden, waarom zijn de uitgaande en inkomende paden anders? Dit is normaal omdat er één VC per route-ingang is (per prefix), en als gevolg daarvan zijn de TVC’s in één richting.
Verrassend genoeg is er niet veel dat we van de switch kunnen krijgen als alle routes/VC's stabiel zijn; het switch alleen ATM-cellen. Zie dit voorbeeld:
Capri#show tag atm-tdp bindings 125.125.0.0 16 Destination: 125.125.0.0/16 Transit ATM3/0/3 2/36 Active -> ATM3/0/0 2/38 Active
Er moet op een aantal details worden gewezen. Onderzoek dit resultaat:
Capri#show atm vc conn-type tvc int atm 3/0/3 Interface VPI VCI Type X-Interface X-VPI X-VCI Encap Status ATM3/0/3 2 33 TVC(I) ATM3/0/0 2 36 UP ATM3/0/3 2 33 TVC(O) ATM3/0/0 2 53 UP ATM3/0/3 2 34 TVC(I) ATM0 0 317 MUX UP ATM3/0/3 2 34 TVC(O) ATM3/0/0 2 54 UP ATM3/0/3 2 35 TVC(I) ATM3/0/0 2 37 UP ATM3/0/3 2 35 TVC(O) ATM3/0/0 2 55 UP ATM3/0/3 2 36 TVC(I) ATM3/0/0 2 38 UP ATM3/0/3 2 37 TVC(I) ATM0 0 318 MUX UP
Zoals we kunnen zien, eindigen sommige TVC’s op de interface-ATM0. Op een 8540MSR komt de interface-ATM0 overeen met de CPU. Deze TVC’s komen overeen met IP-adressen die plaatselijk aan de 8540MSR zijn gericht, zoals een lokale loopback.
We weten dat Guilder IP-pakketten met bestemming 125.125.0.2 op TVC 2/36 stuurt. Aan de LSR kant is deze TVC alleen een inkomende (I) TVC.
Om 125.125.0.2 te bereiken, verwachten we dat de IP pakketten naar Fast Ethernet interface 0/0 in overeenstemming met het netwerkdiagram worden verzonden. We weten dat we geen Label Switching op deze Fast Ethernet-interface hebben ingesteld. Dit is het resultaat:
damme#show tag-switching forwarding-table 125.125.0.2 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface damme#
Als gevolg daarvan is er geen etiket om toe te voegen. Alleen de informatie in de routingtabel wordt gebruikt:
damme#show ip route 125.125.0.2 Routing entry for 125.125.0.0/16 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via ospf 1 Routing Descriptor Blocks: * directly connected, via FastEthernet0/0 Route metric is 0, traffic share count is 1
Deze informatie wordt opnieuw opgeslagen in de CEF-switchingtabel:
damme#show ip cef 125.125.0.2 detail 125.125.0.2/32, version 62, connected, cached adjacency 125.125.0.2 0 packets, 0 bytes via 125.125.0.2, FastEthernet0/0, 0 dependencies next hop 125.125.0.2, FastEthernet0/0 valid cached adjacency
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
05-Jun-2005 |
Eerste vrijgave |