ccna reviewer pdf

ccna reviewer pdf

PDU header Length : The number of bytes in the data header field (the total number of bytes includes the number of bytes of the additional header field) Oper: up Targeted Hello 2.2.2.2 -> 4.4.4.4, active Interface eth 0/0 Network 10.1.34.4 0.0.0.0 area 0 Mpls traffic-eng router-id loopback0 mpls traffic-eng area 0 In this way, first R2 will prefer from the tunnel port to R5 , metric=1+1=2 . There are two options for R1 to R5 : Traditional IP routing only considers metric when routing . For example, if we are running OSPF in the above figure , then R1 to 1.0/24 and 2.0/24 will preferably be from R2 to R3 . Path because the metric is small. Then this directly causes the idle of another optional path and the excessive congestion of the main path. R1#show ip cef 4.4.4.4 [115/10] via 10.1.123.2, FastEthernet0/0 Ip address 10.1.12.1 255.255.255.0 !! activation level1 of MPLS TE 102 Then R1 and R3 receive a label mapping with a prefix of 2.2.2.0/24 and a label of 3 . At the same time, they also received the R2 updated route. Since the loopback interface route is updated by OSPF by default, it is updated in /32 mode. Therefore , the route learned on R1 and R3 about 2.2.2.2 is /32 bit. of. Then this is a problem, my routing entry is 2.2.2.2/32 , but the label message you sent me is 2.2.2.0/24 , it doesn't match, so R1 thinks that the label is going to Not 2.2.2.2 , just give an untagged , just like the LFIB table we saw for R1 . In this way, when R1 receives the label package and goes to 2.2.2.2 ,ccna reviewer pdf,R1 will pop up the label stack of the label package, then find its own FIB table and forward the message out. This seems to be no problem in this topology, but in many environments, there will be problems, such as MPLS VPN . So how to solve it? Very good, R2 loopback port to an ip ospf network point-2-point , or change the mask.