The MPLS WG Archive

["Rohit Gupta" <rohitgupta416@indiatimes.com>]

Hi Rajesh,

Please find my comments inlined in RG>>

 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets, but the

 same Route Distinguisher,  would not the old VPNv4 route be implicitly  removed from

 all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created

 and imported into all the new VRFs, as per the new set of RTs.

 

RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked.

 

RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc)

 

RG>> Hope I was clear.

 

 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE

 for the new Route Target?

 

RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route.

 

Cheers,

Rohit

 

Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended

 Communities matter in an UPDATE. Implementations do send Extended

 community first (type code = 16), followed by MP_REACH_NLRI (14) and then

 MP_UNREACH_NLRI (15)

 

 If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?

Does it depend on the order in which the Path Attributes are present in the UPDATE?

 

Thanks,

Roger

Robert Raszuk <raszuk@cisco.com> wrote:

Hi Roger,

> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
> interpreted as, for those VRFs which are importing those route
> targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

> Roger Pottier wrote:
>
> Hi! ! ! ,
>
> RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
> and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
> UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
>
> - Enter today

---

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today

---

Indiatimes Email now powered by APIC Advantage. Help!

Help

Click on the image to chat with me