คำนำหน้าด้วยป้ายกำกับการรวมที่ไม่ได้ติดตามอย่างเต็มที่ในแกนหลัก MPLS

ฉันมีเราเตอร์สองตัวคือ A (Cat6500 w / SUP720-3BXL, IOS 12.2 (33) SXH4) และ B (Nexus 7K w / SUP1, NX-OS 5.2 (4)) แยกจากกันโดยมีกระโดดหลายแกนใน MPLS แต่ละตัวมี VRF ABC เราเตอร์ A มีเส้นทางเชื่อมต่อโดยตรงสองเส้นทางและเส้นทางคงที่สี่เส้นทางภายใน VRF นี้

RouterA# show ip bgp vpnv4 vrf ABC labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 65000:123 (ABC)
   10.30.10.0/24    10.30.200.1     154/nolabel
   10.30.20.0/24    10.30.200.1     88/nolabel
   10.30.30.0/24    10.30.200.1     38/nolabel
   10.30.40.0/24    10.30.200.1     147/nolabel
   10.30.200.0/24   0.0.0.0         IPv4 VRF Aggr:95/nolabel(ABC)
   10.90.90.0/24    0.0.0.0         IPv4 VRF Aggr:95/nolabel(ABC)
   10.133.242.0/25  192.168.255.3   nolabel/17
   10.133.242.128/26
                    192.168.255.3   nolabel/18
   10.255.255.224/29
                    192.168.255.3   nolabel/492474

การติดป้ายกำกับคำนำหน้าใช้สำหรับ VRF นี้กับเราเตอร์ทั้งสอง ขอให้สังเกตว่าทั้งสองเส้นทางที่เชื่อมต่อโดยตรงจะได้รับป้ายกำกับรวมที่ใช้ร่วมกัน (95) ในขณะที่เส้นทางแบบคงที่ทั้งสี่จะได้รับป้ายกำกับที่ไม่ซ้ำกัน

เราเตอร์ B เห็นด้วยกับฉลาก VPN ที่จะใช้:

RouterB# show bgp vpnv4 unicast labels vrf ABC
BGP routing table information for VRF default, address family VPNv4 Unicast
BGP table version is 17042469, local router ID is 192.168.255.3
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath

   Network            Next Hop            In label/Out label
Route Distinguisher: 65000:123     (VRF ABC)
*>i10.30.10.0/24      172.26.64.1         nolabel/154
*>i10.30.20.0/24      172.26.64.1         nolabel/88
*>i10.30.30.0/24      172.26.64.1         nolabel/38
*>i10.30.40.0/24      172.26.64.1         nolabel/147
*>i10.30.200.0/24     172.26.64.1         nolabel/95
*>i10.90.90.0/24      172.26.64.1         nolabel/95
*>l10.255.255.224/29  0.0.0.0             492474/nolabel (ABC)

จากเราเตอร์ B ฉันสามารถติดตามไปยังเครือข่ายทั้งสองที่เชื่อมต่อโดยตรงบนเราเตอร์ A โดยไม่มีปัญหา:

RouterB# traceroute 10.30.200.10 vrf ABC
traceroute to 10.30.200.10 (10.30.200.10), 30 hops max, 40 byte packets
 1  192.168.254.97 (192.168.254.97) (AS 65000)  19.226 ms  19.369 ms  19.079 ms
      [Label=63 E=0 TTL=1 S=0, Label=95 E=0 TTL=1 S=1]
 2  192.0.2.151 (192.0.2.151) (AS 65000)  23.309 ms  28.027 ms  18.977 ms
      [Label=39 E=0 TTL=1 S=0, Label=95 E=0 TTL=2 S=1]
 3  192.168.251.62 (192.168.251.62) (AS 65000)  21.576 ms  24.265 ms  21.503 ms
      [Label=59 E=0 TTL=1 S=0, Label=95 E=0 TTL=1 S=1]
 4  10.30.200.10 (10.30.200.10) (AS 65000)  19.155 ms *  19.414 ms

อย่างไรก็ตาม traceroutes ไปยังเส้นทางการเรียนรู้แบบคงที่หมดเวลาผ่านเส้นทาง MPLS และรับกลับเฉพาะที่กระโดดครั้งสุดท้ายของพวกเขาเท่านั้น:

RouterB# traceroute 10.30.10.10 vrf ABC
traceroute to 10.30.10.10 (10.30.10.10), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  10.30.200.10 (10.30.200.10) (AS 65000)  19.065 ms  19.281 ms  18.68 ms
      [Label=154 E=0 TTL=1 S=1]
 5  10.30.10.10 (10.30.10.10) (AS 65000)  19.420 ms  19.377 ms  19.73 ms

traceroutes ทั้งสองข้างต้นควรเป็นไปตามเส้นทางเดียวกันและไม่มีกลไกการกรองพร้อม สิ่งเดียวกันเกิดขึ้นในทิศทางตรงกันข้ามเช่นกัน ฉันพลาดอะไรไป ความแตกต่างระหว่างเส้นทาง BGP ที่เรียนรู้จากการเชื่อมต่อโดยตรงกับการกำหนดค่าคงที่เกี่ยวกับ MPLS / การส่งต่อฉลากคืออะไร

ความแตกต่างระหว่างป้ายกำกับรวมและป้ายกำกับปกติเป็นเช่นนั้นป้ายกำกับปกติชี้ไปที่รายละเอียดการเขียน L2 ใหม่โดยตรง (ส่วนต่อประสานและที่อยู่ L2) ซึ่งหมายความว่าป้ายกำกับปกติจะถูกเปลี่ยนฉลากโดยโหนด egress PE โดยตรงโดยไม่ต้องทำการค้นหา IP

ในทางกลับกันฉลากรวมอาจเป็นตัวแทนของตัวเลือก egress ที่แตกต่างกันมากมายดังนั้นข้อมูลการเขียนใหม่ของ L2 จึงไม่เกี่ยวข้องกับฉลาก ซึ่งหมายความว่าโหนด PE ภายนอกจะต้องทำการค้นหา IP สำหรับแพ็กเก็ตเพื่อพิจารณาข้อมูลการเขียน L2 ที่เหมาะสม

สาเหตุทั่วไปที่คุณอาจมีป้ายกำกับรวมแทนที่จะเป็นป้ายกำกับปกติคือ:

1. ต้องทำการค้นหาเพื่อนบ้าน (IPv4 ARP, IPv6 ND)
2. ต้องทำการค้นหา ACL (egress ACL ในส่วนต่อประสานลูกค้า)
3. เล่น VRF ทั้งหมดภายใต้ฉลากเดียว (ตารางป้ายกำกับ)

ข้อ จำกัด บางประการ (โดยเฉพาะอย่างยิ่ง 2) นี้ไม่สามารถใช้ได้กับทุกแพลตฟอร์ม

traceroute ได้รับผลกระทบอย่างไรในสภาพแวดล้อม MPLS VPN โดยการขนส่ง P เมื่อสร้างข้อความเกิน TTL จะไม่ทราบวิธีการส่งคืน (ไม่มีรายการตารางเส้นทางไปยังผู้ส่ง) ดังนั้นโหนดการขนส่ง P จะส่งข้อความเกิน TTL พร้อมกับป้ายชื่อสแต็คดั้งเดิมไปยังโหนด PE ออกไปข้างนอกด้วยความหวังว่าโน้ต PE ภายนอกมีความคิดว่าจะส่งข้อความ TTL เกินข้อความไปยังผู้ส่งได้อย่างไร
คุณลักษณะนี้เปิดใช้งานโดยอัตโนมัติใน Cisco IOS แต่ต้องมีการกำหนดค่า 'icmp-tunneling' ใน Juniper JunOS

จากสิ่งนี้ฉันสงสัยว่าอุปกรณ์ CE ของคุณอาจไม่ยอมรับแพ็กเก็ตเมื่อที่อยู่ต้นทางเป็นเครือข่าย P node link และเนื่องจากพวกเขาไม่ยอมรับข้อความ ICMP พวกเขาจึงไม่สามารถส่งกลับไปยังผู้ส่งได้
วิธีที่เป็นไปได้ในการทดสอบทฤษฎีนี้จะเป็นการเปิดใช้งานป้ายกำกับต่อ vrf:

• IOS: โหมดฉลาก mpls โปรโตคอล all-vrfs bgp-vpnv4 ต่อหนึ่ง vrf
• JunOS: กำหนดเส้นทาง - อินสแตนซ์ FOO vrf-table-label

โดยทั่วไปฉันไม่แนะนำให้เผยแพร่ TTL โดยเฉพาะอย่างยิ่งในสภาพแวดล้อม VPN อย่างน้อยในกรณีที่ลูกค้าของเราสับสนและกังวลเกี่ยวกับเรื่องนี้ พวกเขากังวลว่าเหตุใด VPN จึงมีที่อยู่ต่างประเทศแสดง

อีกสิ่งหนึ่งที่ทำให้ผู้คนสับสนทำให้พวกเขาเปิดตั๋วสนับสนุนคือเมื่อพวกเขากำลังเรียกใช้ traceroute จากการพูดสหราชอาณาจักรไปยังสหรัฐอเมริกาเพราะพวกเขาเห็นการหน่วงเวลา> 100ms ระหว่างสองเราเตอร์หลักในสหราชอาณาจักรโดยไม่ทราบว่าเส้นทางทั้งหมด ไปจนถึงชายฝั่งตะวันตกของสหรัฐอเมริกาเพราะแพ็คเก็ตทั้งหมดใช้ทางอ้อมจากที่นั่น

ปัญหานี้ไม่สามารถแก้ไขได้โดยการออกแบบเป็นส่วนใหญ่อย่างไรก็ตามใน IOS คุณสามารถกำหนดจำนวนป้ายกำกับที่มากที่สุดที่จะป๊อป (mpls ip ttl-expiration pop N) เมื่อคุณสร้าง TTL เกิน สิ่งนี้จะให้การประมาณที่ค่อนข้างเหมาะสมหาก INET == 1 ป้ายกำกับ, VPN ==> 1 ป้ายกำกับดังนั้นคุณสามารถกำหนดค่าเพื่อให้ทราฟฟิกของ VPN ถูกเชื่อมต่อและทราฟฟิกของ INET จะได้รับคืนโดยตรง แต่อย่างที่ฉันบอกว่านี่เป็นเพียงการประมาณฟังก์ชั่นที่ต้องการเนื่องจากคุณสมบัติเช่นการซ่อมแซมระหว่างทางอาจทำให้สแต็กฉลากของคุณไม่ต้องมีขนาดเท่ากันสำหรับบริการเดียวกัน