Both implicit and explicit null labels are generated by last hop router to its neighbors.
Implicit null is by default which means penultimate router should only send IP packet thus it pops the label (popping the label known as PHP and this is done to reduce the load on last hop router). The one disadvantage in implicit null approach is if the network is configured for QoS based on MPLS EXP bits, then QoS is lost between penultimate router and last hop router.
In this case, we can make use of Explicit null which means penultimate hop router does not pop the label. It sends with label value of 0 but with other fileds including EXP bits intact. This way QoS treatment is preserved between penultimate router and last hop router. Explicit null should be configured manually in last hop router.
Consider the following topology where all the routers are running an IGP (eg OSPF)
10.x.x.x/24 --- Router A --- Router B -- Router C -- Router D -- Router E --- 11.x.x.x/24
Consider MPLS is enabled only between Router A and Router D.
Link between Router D and E are not MPLS enabled. Router D learns about 11.x.x.x prefix by some protocol from Router E. But there is no way that Router D decides by itself that it is the egress LSR for this prefix as there are some possible reasons because MPLS could be disabled by manual error between Router D and E. Or Router E belongs to a customer.
I think this is one of the reason that by default implicit nulls are not generated for prefixes in RIB learned apart from connected and aggregate, because the router knows it for sure that it is the egress point for connected and aggregate.
If an LSR for example has a directly connected prefix 10.1.1.x, it would assign implicit mull label to this prefix and would keep it in its local binding database (can be viewed by sh mpls ldp binding 10.1.1.x), it would then populate these binding to the PHP router to inform it to pop the label when forwarding the Packet to the egress LSR. This will eleminate the egress LSR to perform additional lookups.
Command: LAB-NPEG1-R4-TOP-PE1(config)#mpls ldp explicit-null ?
for Access-list specifying controls on destination prefixes
to Access-list specifying controls on LDP peers
for Access-list specifying controls on destination prefixes
to Access-list specifying controls on LDP peers
Note An explicit NULL label is not needed when the penultimate hop receives MPLS packets with a label stack that contains at least two labels and penultimate hop popping is performed. In that case, the inner label can still carry the QoS value needed by the penultimate and edge LSR to implement their QoS policy.
No comments:
Post a Comment