The MPLS-OPS Archive

["Gopal@Yahoo" <gnaganab@yahoo.com>]

--- alok <alok.dube@apara.com> wrote:
> > >
> > > > Egress LER: L3 lookup not necessary (exception
> for
> > > > aggregate prefix). 'tag forwaridng engine' can
> do
> > > the
> > > > job with the Label lookup.
> > >
> > > on the egress FT entry to match on looks like :
> > >
> > > "incoming interface--label--destn-subnet-1(to be
> > > matched)--outgoing
> > > interface"
> > > "incoming interface--label--destn-subnet-2(to be
> > > matched)--outgoing
> > > interface"
> > >
> > >
> > > if your saying i have a supernet advertised via
> > > MiBGP to the remote end
> > > hence traffic for both come in with 1 label, i
> need
> > > to do a specific network
> > > route lookup, after i get the packet on
> > > egress.....right? if the table looks
> > > like above, why do u say that this would be a
> > > problem? (be it hash or trees
> > > or whatever algo)
> > >
> > > am i missing something?
> > >
> > > i actually dont know how typical ASICs split
> that
> > > functionality (i mean how
> > > do u represent interface--and ip and label part
> etc"
> > > in the FT...but
> > > assuming u even make a simple hash on that
> combo..i
> > > think its close enuf to
> > > assume each entry wud be unique, even if
> different
> > > parameters are
> > > involved...
> > >
> > > not too sure abt that bit, wud be great if
> someone
> > > could clarify...
> >
> > On the Egrees, there won't be a 'outgoing intf'
> for
> > the aggregate prefixes in the FT. For all other
> > prefixes, 'outgoing intf' and 'tag/mac rewrite'
> exist
> > in the FT. So, for non-aggregate prefixes, pkt can
> be
> > tag switched without looking at L3 header. But for
> > aggregate prefixes, the egress needs to look at
> the L3
> > to forward the pkt.
> >
> 
> hi gopal,
> 
> this is my doubt:
> 
> why would u put an aggregate route into the FT of
> the "point where it
> splits"? ...i dont think this makes sense..and
> logically shudnt be done....
> 
> even when IGP aggregates stuff in "non-MPLS"
> scenario, the aggregates are
> what is "passed on" to others..not inserted in the
> aggregating router's
> local forwarding table..is it? if yes......uh oh!

I don't know if there is a standard for this. But
cisco will indeed install the summerised route in the
routing table but next-hop it to null. This shd be ok
becoz the routing table also will have the more
specific routes that were summerized. 

cisco will adv the aggregate route, install aggr entry
in the FT. But this will not be used as the more
specific entries(longest match) will be used. 

It is more appropriate to say for the 'connected'
vpnv4 prefixes, there won't be 'outgoing intf' in the
Tfib table. This is because router need to look
complete L3 addr and the corresponding Arp entry
before forwarding. 
just like this:
R1#sho run int e0/0
!
interface Ethernet0/0
 ip vrf forwarding Red
 ip address 10.10.112.1 255.255.255.0
end

R1#sho tag for vrf Red
Local  Outgoing    Prefix            Bytes tag 
Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched  
interface
109    Untagged    10.10.10.12/32[V] 0          Et0/0 
    10.10.112.12
110    Aggregate   10.10.112.0/24[V] 0
R1#


> 
> what is the limitation? the fact that we cant index
> on such a long
> entry....or store "incoming label+ label+destn ip +
> out going interface" etc
> in the FT?

Not a limitation but desireable.


> 
> logically,
> 
> you would put specific routes in the FT there but
> pass on "aggregate routes"
> to your peers via the route -advertisement...
> 
> so the aggregates is what others know, what your
> node knows is the subnetted
> stuff and "switches" on that based on FT...
> 
> would appreciate if you could clarify.....
> 
> thanks and rgds
> Alok
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: 
> http://www.mplsrc.com/mplsops.shtml
> Archive:
http://www.mplsrc.com/mpls-ops_archive.shtml


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml