The MPLS WG Archive

[Robert Raszuk <raszuk@cisco.com>]

Some implementations do only LFIB lookup and send the packet blindely to
CE11 (then it bounces back) some use the concept of aggregate VPN label
and do VRF lookup after LFIB lookup on PE2 which allows route
aggregation among multiple sites connected to the same vrf or
loadbalancing. 

I think the rfc does not mandate the behviour here.

Rgs,
R.

> Sachin Kalra wrote:
> 
> Hi Robert:
> 
> Thanks for the reply.
> 
> > PE2 should based on the information retrived from the VPN label do
> > the
> > vrf lookup which reveals that the packet is destined to itself.
> > There is
> > no need to send it to CE11.
> 
> But shouldn't PE2 do a "NHLFE lookup" instead of "VRF lookup" when it
> gets a packet from PE1, with a label.
> 
> And if PE2 only does a NHLFE lookup then all it gets is an outgoing
> interface for the label. (In this case out iface will be the one
> connecting to CE11)
> 
> Please comment.
> Thanks,
> Sachin Kalra
> 
> *********************************************************************************
> Just to be more clear, following is my VRF table at PE2. Where
> 
> 1. "192.0.5.1" is the interface on PE2 (that connects PE2 and CE11).
> 2. "192.0.5.2" is the interface on CE11 (that connects CE11 and PE2).
> 3. "192.0.25.1" is the loopback interface on CE11.
> 4. "192.0.7.1", "192.0.1.1", "192.0.19.1" are PE1, CE1 and CE2
> respectively
> 
> ======================================================
> VRF Table for VRF_A at PE2:
> 
> Destination       Subnet Mask        Next Hop      Out Iface    Bottom
> Label   Top Label
> -----------            -----------                 ------------
> ---------        ------------           ---------
> 192.0.5.0          255.255.255.0      192.0.5.1       IF0
> 31                   UNDEF
> 192.0.25.0        255.255.255.0      192.0.5.2       IF0
> 32                   UNDEF
> 192.0.1.0          255.255.255.0      192.0.7.1       IF2
> 31                   31
> 192.0.19.0        255.255.255.0      192.0.7.1      IF2
> 32                   31
> ======================================================
> 
> At 11:09 PM 1/15/03 +0100, Robert Raszuk wrote:
> 
> > Hi Sachin,
> >
> > > Because it just look at the bottom label of the packet,
> > > and as per the entries into its VRF table, PE2 just sends out the
> > packet to
> > > CE11.
> >
> > PE2 should based on the information retrived from the VPN label do
> > the
> > vrf lookup which reveals that the packet is destined to itself.
> > There is
> > no need to send it to CE11.
> >
> > R.
> >
> > > Sachin Kalra wrote:
> > >
> > > Dear MPLS Community:
> > >
> > > I would appreciate if someone can answer the following question
> > about
> > > BGP-MPLS VPNs.
> > >
> > > Lets say we have the following topology:
> > >
> > > [CE1]
> > [CE11]
> > >
> > \                                                           /
> > >          [PE1]-----------------[Rtr1]-------------------[PE2]
> > >
> > /                                                           \
> > > [CE2]
> > [CE22]
> > >
> > > 1. PE and CEs have static routes configured between each other.
> > i.e. no
> > > routing protocol running on the interfaces connecting PEs and CEs.
> > >
> > > Question. How will a packet going from CE1 and destined to
> > interface on PE2
> > > (that connects PE2 and CE11) reach its destination?
> > >
> > > The problem is that when PE2 receives a packet destined to its out
> > > interface connecting "PE2->CE11". PE2 does not know that the
> > packet is
> > > destined to itself. Because it just look at the bottom label of
> > the packet,
> > > and as per the entries into its VRF table, PE2 just sends out the
> > packet to
> > > CE11.
> > >
> > > Is this the correct behavior?
> > >
> > > I appreciate your response.
> > > Thanks,
> > > Sachin Kalra
> 
> ===========================================================
> Sachin Kalra
> Modeling Engineer
> OPNET Technologies, Inc.
> (240)-497-3000 x2796
> ===========================================================
> Register for OPNET's Online Technology Workshops
> (http://www.opnet.com/TechWorkshops/)
> ===========================================================