6PE/6VPE over IPv4-MPLS backbone
(2011-04-17 17:48:58)
下一个
Resolving the IPv6 prefixes (advertised by BGP) to the IPv4-next-hop address.
Each protocol update thread proceeds independently in a lock-free manner, allow more parallelism, less contention and make it more future proof.
System Flow
==========
BGP VPN6 prefix update
BGP VPN6 prefix delete
IGP next-hop prefix is resolved/added
IGP next-hop prefix goes away
IGP next-hop prefix is modified
BGP VPN6 prefix update
--------------------------------
VPN6 prefixes are downloaded from BGP to RIB and then to FIB with v4-in-v6 address (::ffff:A.B.C.D) as next-hop. The outgoing label is also downloaded from BGP to RIB and then to FIB.
The path in the route update will be
{recursive | FIB_PATH_TYPE_LABELED | next-hop address is ::fffff:A.B.C.D}
This will essentially try to resolve the VPN6 pathlist to the recursive NH object in IPv6 address space. It will
1) lookup of the IPv4 next-hop address in the recursive nhinfo database in IPv6 address space
2) if recursive nhinfo is found, then the path-resolution has succeeded.
3) if recursive nhinfo is found but in reject, then the path-resolution did not succeed
put created pathlist into retry
put VPN leaf into reject
4) if recursive nhinfo is not found, the IPv6 thread will need to register with the IPv4 thread to receive notifications on the IPv4 EOS 0 next-hop leaf changes
a) A sync IPC will be sent to IPv6 thread requesting registration for the IPv4 next-hop
b) In the IPv4 thread, the received message will trigger a lookup of the EOS0 next-hop leaf
c) If it is found and ECD forwarding chain resolving to the EOS 0 leaf. If not found the ECD leaf will be put in reject and its corresponding path-list will be put in retry
d) A sync reply will be generated.
e) IPv6 thread on receving the sync reply
on success, create recursive nhinfo and resolve the VPN pathlist to this nhinfo
on failure, recursive nhinfo object will be created but put into retry, and its state as unresolved.
BGPv6 prefixes delete
-----------------------------
the route delete will remove the leaf from the dependency chain of the shared VPN pathlist. Then the reference count goes to zero the VPN pathlist will also be deleted and the loadinfo will be deleted and the corresponding PD update will be sent.
IGP prefix resolved
----------------------------
if succeeds then the pathlist corresponding to the ECD leaf will be updated to point to the EOS 0 leaf.
the ECD pathlist will be added to the dependency list of the EOS 0 leaf
ECD pulse notification to IPv6 thread
IGP prefix unresolved
----------------------------
when IGP prefix becomes unreolved, PI will backwalk its dependents. The ECD-pathlist for 6PE client is reside in the dependency chain of EOS 0 leaf.
ECD will modify the ECD pathlist and corresponding loadinfo and set it to DROP
PI ECD will trigger PD udpate for ECD loadinfo
ECD leaf will then be queued onto the notification list for pulse notification to IPv6 thread
IPv6 thread then put recursive nhinfo object into retry.
IPv6 backwalk will put its dependent pathlists into retry and the corresponding VPN leaf into reject
the v4-in-v6 leaf is removed and put into its reject trie
Label Disposition
-----------------------------
No deaggregation
vpn_label_entry[1] --> eos1_lba --> unlabelled_li --> v6_nhop
With deaggregation
vpn_label_entry[1] --> eos1_lbal --> unlabelled_lu --> lookup ipv6 in vrf for v6 nhop
Batched 6VPE Next-Hop Updates
---------------------------------------------
BGP will download/remove its next-hops explicited to RIB ahead of VPN6 prefixes.
1) RIB 6VPE-NH downdown in IPv6-update thread will initiate a batched registration of these IPv4-nexthops with the IPv4 thread, expressing interest in, and requesting notifications for IPv4 next-hops using the FIB ECD API.
2) On successful registration, IPv6 thread will create recursive nhinfo. The recursive nhinfo will reside in a recursive nhinfo table in the IPv6 address-space
3) PD update
IPv6 thread
VPN6 prefix | IP pathlist | IMP LDI | BGP LI | Recursive NH
IPv4 thread
ECD leaf for IGP | ECD pathlist | ECD LDI | EOS 0 leaf | EOS 0 LDI | LI | MPLS NH
PD Forwarding Chain
VPN6 leaf --> PD ECD LDI -->