Hi Alexandr, You config should work. We have the same config in our network working fine without any issues. HTH Arun ... View more

Hi Kevin, I presume you want to use only one ISP peer for both forward and reverse traffic. If that peer fails the traffic should fall back to other peer. If this is correct, then there are ways you can achieve: 1. For outbound, you can influence the traffic by manipulating BGP attributes as you said weight, local preference. You have to set the peer where you want your traffic to flow by configuring higher value of weight and local preference. These attributes can be set to group of prefixes or for all prefixes received by that peero. By this the outbound traffic prefers the peer. router bgp xxx neighbor a.b.c.d weight --- for all prefrixes received neighbor a.b.c.d route-map test in -- for specific prefixes with acl testacl route-map test permit 10 match ip address testacl set weight /set local-preference 2. For inbound, it depends how you advertise the prefixes to both peers. One common way people do is to prepend your own as number while you advertise the prefix to your secondary peers. To primary peers you can advertise without any your own as prepending. router bgp xxx neighbor a.b.c.d route-map test out ----- secondary peer neighbor e.f.g.h remote-as yyy ------- primary peer route-map test permit 10 match ip address testacl set as-path prepend 3. The drawback of the above method is when the internet chooses the best path to your prefixes they usually choose the shortest as path. Though you prepend you AS many times to your secondary peer, chances are there that your secondary peer can be preferred from some ISP. This all depends from that particular ISP point of view as internet is interconnection of ISP's. There is a feature where you can advertise your prefixes only to one ISP. Only if that ISP fails you can advertise the prefixes to your secondary ISP. In this way, secondary ISP only receive when your primary ISP goes down.  This feature is called "BGP Conditional Advertisement'. Please refer the below link: http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080094309.shtml Hope this helps Arun ... View more

Hi, (edited as i misunderstood the question previously, i try my best to explain) 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 someone has better explanation and any other reason, pls post. HTH Arun ... View more

Hi, 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. HTH. Arun ... View more