The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: MPLS VPN with very large number of routes
Hi Venko,
> Is it still possible to use MPLS VPN in this case?
Possible but you are on the edge ;). Yes we don't recommend to put
internet into vrfs for the very same reasons.
> limits on the number of routes in MPLS VPN? And why I'm getting this
> massege - %TAGCON-3-LCLTAG_ALLOC: Cannot allocate local tag. This
Oh I am sorry for not addressing this question earlier. This is just
saying that the max label range is over. You can increase the max tag
range by the following cmd:
b10-7204V(config)#mpls label range ?
<16-1048575> Minimum label value
b10-7204V(config)#mpls label range 50 ?
<50-1048575> Maximum label value
b10-7204V(config)#mpls label range 50 1000000
^^^^^^^
> I'm just curious, why the
> router needs to assign an unique tag for every prefix in VPN, while in
> global routing everything is working fine with only one tag?
There are two choices:
One to generate an aggregate label for all prefixes in the vrf and do
the lookup for each packet going back to the site
Two to generate a uniqe label for each prefix and do not do any lookup
on return traffic
Of course there are mid points where some prefixes are advertised with
an aggregate label and some with non aggregate label.
The problem happens when you have two or more CEs giving you routes and
you are using non aggregate labels. In such a case you need to allocate
labels per CE. Cisco does not do this. (I think Juniper does :). You can
still generate an bgp aggregate for your routes in the vrfs and
advertise just one but you will be doing lookup for every return packet.
In addition to this there are applications like for example: Carrier's
Carrier where you can't do lookup as you don't know in the vrf about
your customer's external routes. That's why non aggregate label for each
prefix in your vrf is a must. (Good news is that rearly a single CSC
site will have 100K PEs :). So Cisco did one label for each prefix in
the vrf to address both above scenarios.
In the global table we don't allocate any label to bgp routes as they
all go to the next hop and regular IP lookup is done there.
R.
> Venko Moyankov wrote:
>
> Robert,
>
> Thank you for fast response. While I'm not sure if Carrier's Carrier
> solution is available now and with these platforms, I have a few more
> questions.
>
> Is it still possible to use MPLS VPN in this case? What are practical
> limits on the number of routes in MPLS VPN? And why I'm getting this
> massege - %TAGCON-3-LCLTAG_ALLOC: Cannot allocate local tag. This
> should't be the correct behavior, isn't it? I'm just curious, why the
> router needs to assign an unique tag for every prefix in VPN, while in
> global routing everything is working fine with only one tag?
>
> Thanks
> Venko Moyankov
>
> Robert Raszuk wrote:
> >
> > Venko,
> >
> > Yes what you see is the correct behaviour of cisco implementation. The
> > unique tag is assinged as we don't assing a VPN tag per CE interface but
> > per each prefix in the vrf.
> >
> > For the setup like yours Carrier's Carrier should be used not MPLS-VPNs.
> >
> > R.
> >
> > > Venko Moyankov wrote:
> > >
> > > Hi all,
> > >
> > > I've searched the list achieve for last 6 months, but didn't find any
> > > discussion on this topic. Please excuse me if I missed it.
> > >
> > > I need to make MPLS VPN with very large number of prefixes received from
> > > CE (about 104k - the full internet BGP) and limited number of CEs. I'm
> > > using 3660 and 7206 VXR as PEs with 256M RAM each. To be more precise
> > > I'm using tag-switching, not MPLS. Two PE are directly connected
> > > (without P) with FE.
> > > Did anyone make something like this and is it working OK?
> > >
> > > Now on 3660 PE I have only one vrf with about 104k prefixes, it has
> > > about 80M free RAM.
> > >
> > > ==========================================================
> > > 3660#sho ip bgp vpnv4 vrf test1 summary
> > > BGP router identifier 212.5.128.239, local AS number 8795
> > > BGP table version is 211855, main routing table version 211855
> > > 104142 network entries and 104141 paths using 18849642 bytes of memory
> > > 34991 BGP path attribute entries using 2102220 bytes of memory
> > > 15308 BGP AS-PATH entries using 437108 bytes of memory
> > > 12 BGP community entries using 288 bytes of memory
> > > 1 BGP extended community entries using 24 bytes of memory
> > > 103 BGP route-map cache entries using 1648 bytes of memory
> > > 0 BGP filter-list cache entries using 0 bytes of memory
> > > BGP activity 104868/551 prefixes, 107052/1875 paths, scan interval 15
> > > secs
> > >
> > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> > > State/PfxRcd
> > > 62.176.103.246 4 8262 37636 42 211855 0 0 00:37:36
> > > 104138
> > >
> > > 3660#sho mem
> > > Head Total(b) Used(b) Free(b) Lowest(b)
> > > Largest(b)
> > > Processor 62354920 191543008 108167660 83375348 83362164
> > > 78173696
> > > I/O DA00000 39845888 3530740 36315148 35734104
> > > 33911996
> > > ==========================================================
> > >
> > > Every minite the routers says:
> > >
> > > %TAGCON-3-LCLTAG_ALLOC: Cannot allocate local tag
> > >
> > > It has assigned a unique tag for _every_ prefix it has learned!
> > >
> > > This behavior is completely different from the case with tag-switching
> > > and bgp in global routing table. In global routing table it uses one tag
> > > for every next hop and all prefixes are with the same tag:
> > >
> > > Let select two random prefixes - 63.101.83.0/24 and 63.101.128.0/24
> > >
> > > ===========================================================
> > > In global routing table:
> > > 7206#sho ip cef 63.101.83.0
> > > 63.101.83.0/24, version 331960, cached adjacency to ATM3/0.1
> > > 0 packets, 0 bytes
> > > Flow: AS 0, mask 24
> > > tag information from 146.188.0.178/32, shared, unshareable
> > > local tag: 59
> > > via 146.188.0.178, 0 dependencies, recursive
> > > next hop 146.188.0.178, ATM3/0.1 via 146.188.0.178/32
> > > valid cached adjacency
> > > tag rewrite with AT3/0.1, point2point, tags imposed: {}
> > >
> > > 7206#sho ip cef 63.101.128.0
> > > 63.101.128.0/24, version 481995, cached adjacency to ATM3/0.1
> > > 0 packets, 0 bytes
> > > Flow: AS 0, mask 24
> > > tag information from 146.188.0.178/32, shared, unshareable
> > > local tag: 59
> > > via 146.188.0.178, 0 dependencies, recursive
> > > next hop 146.188.0.178, ATM3/0.1 via 146.188.0.178/32
> > > valid cached adjacency
> > > tag rewrite with AT3/0.1, point2point, tags imposed: {}
> > > 7206#sho tag-switching forwarding-table tag 59
> > > Local Outgoing Prefix Bytes tag Outgoing Next Hop
> > > tag tag or VC or Tunnel Id switched interface
> > > 59 Untagged 146.188.0.178/32 63314075 AT3/0.1 point2point
> > > ===========================================================
> > > In vrf:
> > > 3660#sho ip cef vrf test1 63.101.83.0
> > > 63.101.83.0/24, version 5003, cached adjacency 62.176.103.246
> > > 0 packets, 0 bytes
> > > tag information set
> > > local tag: 5876
> > > via 62.176.103.246, 0 dependencies, recursive
> > > next hop 62.176.103.246, FastEthernet0/0.104 via 62.176.103.246/32
> > > valid cached adjacency
> > > tag rewrite with Fa0/0.104, 62.176.103.246, tags imposed: {}
> > > 3660#sho ip cef vrf test1 63.101.128.0
> > > 63.101.128.0/24, version 4840, cached adjacency 62.176.103.246
> > > 0 packets, 0 bytes
> > > tag information set
> > > local tag: 5689
> > > via 62.176.103.246, 0 dependencies, recursive
> > > next hop 62.176.103.246, FastEthernet0/0.104 via 62.176.103.246/32
> > > valid cached adjacency
> > > tag rewrite with Fa0/0.104, 62.176.103.246, tags imposed: {}
> > > 3660#sho tag-switching forwarding-table tags 5876
> > > Local Outgoing Prefix Bytes tag Outgoing Next Hop
> > > tag tag or VC or Tunnel Id switched interface
> > > 5876 Untagged 63.101.83.0/24[V] 0 Fa0/0.104
> > > 62.176.103.246
> > > 3660#sho tag-switching forwarding-table tags 5689
> > > Local Outgoing Prefix Bytes tag Outgoing Next Hop
> > > tag tag or VC or Tunnel Id switched interface
> > > 5689 Untagged 63.101.128.0/24[V] 0 Fa0/0.104
> > > 62.176.103.246
> > > ===========================================================
> > >
> > > Tag-switching forwarding table in VPN environment is extremely large and
> > > all tags are exactly the same - with the same next hop and outgoing
> > > interface. Why this happens? Do we really need 100k equal tags?
> > >
> > > Does anybody know if this is a bug in MPLS VPN implementation, or
> > > missing a feature, ot this is the right way?
> > > I also believe that the same number of prefixes consume much more RAM in
> > > MPLS VPN environment than in global space.
> > >
> > > Thanks in advance
> > > Venko Moyankov
> > > RTC Ltd. / Mobikom
> > >
> > > -------
> > > The MPLS-OPS Mailing List
> > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
> > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|