resolve-vpn in Junos

In the MPLS VPN network, There are different between IOS and Junos. There we are talk about the label in each OS.

In IOS, the label can be allocate from LDP/TDP(IGP), or the BGP (ipv4 or vpnv4). This is very important for Inter-AS or CSC which will swap label at border ASBR. if the label can't match the data plane is lost end to end connection.

In the Junos, It's a little complex where in inet.0 or inet.3. First we remind what's the inet.0 and inet.3. For the inet.0, in the JNCIA ebook it's is the table used to store IPv4 unicast routes(OSPF, RIP. ISIS) For the inet.3 table it contains the egress IP address of a MPLS label switched path (LSP).

In the IOS BGP table, if the next-hop is un-reachable it will not forward to the peer, as the same as ipv4 and vpnv4. How about in the vpnv4, if the next-hop not reach via mpls label ?? Well, the answer is BGP routing is work for you but the data plane isn't work. Because the packet will drop at PE router while there is no label to reach remote PE.

For the Junos, It's more technical then IOS. The rule is "If the next-hop in bgp.l3vpn.0 can reach via inet.3. It will not forward to peer" It's simple if I can't reach the peer via a MPLS label I'll not update the BGP route to perr. No black hole in the path.

So, The resolve-vpn command help you to install BGP route update with the label into the inet.3 table. In the Inter-AS and CSC the bgp update will have a label inside the update. And Junos will put BGP label into inet.3 and the BGP update can send to peer.

That's the resolve-vpnwork for you.

Cisco 224.0.0.x flood

In general, We know 2 routers in the same segment with OSPF or EIGRP, they will bcome neighbor. But how about the Layer 2 device, How does it know which port is join the EIGRP multicast group 224.0.0.10??

There is a doc in cisco.com about how switch process the reserved, destination, multicast IP addresses. It's Source-Only Networks.

Source-Only Networks

In a source-only network, switch ports are connected to multicast source ports and multicast router ports. The switch ports are not connected to hosts that send IGMP join or leave messages.

The switch learns about IP multicast groups that alias with reserved, destination, multicast IP addresses (224.0.0.x) from the IP multicast data stream by using the source-only learning method. The switch forwards traffic that aliases with these multicast addresses only to the multicast router ports.

The default learning method for traffic that aliases with reserved, destination, multicast IP addresses is IP multicast-source-only learning.Traffic that does not alias with these multicast addresses is forwarded to both the multicast source ports and multicast router ports. You cannot disable IP multicast-source-only learning for the traffic with reserved, destination, multicast IP addresses.

By default, the switch ages out forwarding-table entries that were learned by the source-only learning method and that are not in use. If the aging time is too long or is disabled, the forwarding table is filled with unused entries that the switch learned by using source-only learning or by using the IGMP join messages. When the switch receives traffic for new IP multicast groups, it floods the packet to all ports in the same VLAN. This unnecessary flooding can impact switch performance.

If aging is disabled and you want to delete multicast addresses that the switch learned by using source-only learning, re-enable aging of the forwarding-table entries. The switch can now age out the multicast addresses that were learned by the source-only learning method and are not in use.

JNCIP part 6

The tricky JNCIP ibgp requirement :

• You must configure at least three clusters and at least two route reflectors.

• You must use physical address peering in at least one of your clusters.

• The failure of any link must not break the route reflection topology.

• The route reflection topology must not impose suboptimal routing or black holes.

• Authentication and logging settings from the previous section must remain in effect.

The ebook indicate the r3, r4 will in different cluster because :

But placing both r3 and r4 in the same cluster would be a mistake in this case,

because doing so will cause r3 and r4 to ignore updates that carry their common cluster ID.

This will result in missing routes on one of the reflectors should a peering interface fail on

one of the two route reflectors that serve clients r1 or r2,

which would violate the redundancy aspects of your design requirements.


I'll show you why.

If both R3 and R4 in the same cluster 1.1.1.1 and R2 to R4 interface is down.
R4 BGP peering to r2 and r1 is gone, and both r1,r2 send BGP update to r3, then r3 will update to r4. When R4 received BGP update from R3, R4 will not accept "because r3,r4 in the same cluster"


A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 192.168.50.0/24 B 170 100 >10.0.2.9 I

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

R4 will get missing route. This result will make you score 0 point.

Half point cause rain

The 2 round of the 2009 F1 GP was stop at after 32 laps, The heavy rainning made the race stop. Brawn GP's Jenson Button won the race in first and second round. A special score report by dirver is half from regular. (10-8-7-6-5-4-3-2-1) to (5-4-3.5-3-2.5-2-0.5). In the driver standing, Button leading Barrichello 5 points.