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
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
|
|