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