[j-nsp] FPC/PFE route scaling
Hello list, I'm having a hard time understanding route scaling on the bigger M and MX boxes. In a CFEB based box maximum FIB is around 500k due to the limited SRAM on the CFEB holding the FIB. On a CFEB-E this is increased. Now looking at the M320 or MX240 the FIB is present on all FPC boards in each PFE, correct? What is the architectural difference when using a distributed setup, and how does it affect maximum FIB size? Eg. On an FPC3-E2 in an M320 what can be expected to be the limit? Regards, Rutger ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Smallest size IPv6 allocation typically advertised?
Morgan McLean wrx...@gmail.com writes: Just curious what the smallest v6 advertisement providers will accept is these days? I've seen no smaller than /48 mentioned on various boards, but I see arin will allocate all the way down to /32. We currently have a /48, and I advertise the whole thing but I'm considering splitting it up among multiple sites. Please do not split up smaller than /48. You will be heavily filtered. If you have reasonable connectivity between sites, get something larger than /48, perhaps /44 or even /32 if you are a hosting provider. Announce /48 for each site and announce each /48 plus a covering /44 or /32 or whatever you were given. That way you will be reachable even from those providers who filter by database objects. On the other hand, if the sites each live in their own world, consider whether you can live with PA space from whichever provider you have at each site. If you must have PI, get a separate /48 for each site if possible. Akamai can get away with taking a /32 and splitting it to deaggregated /48's, because any ISP which cannot reach Akamai is going to get complaints from its customers. If you have that kind of clout, you can do whatever you want. For the rest of us, being strict in what you send and liberal in what you accept is the only -- and strict means no deaggregation without covering routes or separate database objects. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Smallest size IPv6 allocation typically advertised?
On (2013-01-23 01:30 +), Michael Ahladianakis wrote: Typically a /48 is suppose to be the smallest block advertised out as ARIN and I believe all other registrars recommend a /48 per site. However looking at my tables I am seeing /64's from multiple upstream AS'. ACK. Unfortunately due to some personal crusades there are semi popular 'strict filters' found on Internet which cause quite large networks to be dropped, like /36 (I'm guessing between 1-3% of ASN will filter like this today) But these will be fixed in due time, when enough people complain to those. But it has bitten one of my customers already. In IPv4 we almost always could live without more-specifics as network were small and it was easy to justify new block. So when you do have disconnected DCs, it usually just worked. In IPv6 you won't get second block in RIPE area, so deaggregation is must. I think in ARIN area this is different and two DCs would mean you could get two blocks. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Smallest size IPv6 allocation typically advertised?
On Wed, Jan 23, 2013 at 5:50 AM, Saku Ytti s...@ytti.fi wrote: block in RIPE area, so deaggregation is must. I think in ARIN area this is different and two DCs would mean you could get two blocks. ARIN rules effectively allow you to manage a /32 (or more) per POP, with every POP getting the same sized block, rounded up to nibble-boundary based on your plans. You then take your number of POPs and round that up to nibble-boundary. This means many networks can effectively go to ARIN and get a /28 or /24 today with no problem; some networks even bigger. It also means for ISPs there is going to be much less need to announce any routes smaller than /32. For PI end-users, though, the waters remain murky. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 6PE + mpls no-propagate-ttl
Hello Did somebody have got trouble with no-propagate-ttl on 6PE environment ? It seems that it doesn't work for me in 11.4 Many thanks David David Roy IP/MPLS Support engineer - Orange France Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13 david@orange.commailto:david@orange.com JNCIE-MT/SP #703 - JNCIE-ENT #305 - JNCIP-SEC _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE + mpls no-propagate-ttl
On (2013-01-23 16:07 +0100), david@orange.com wrote: Did somebody have got trouble with no-propagate-ttl on 6PE environment ? It seems that it doesn't work for me in 11.4 Running mostly 11.4R3, R5, R6 here and it works for me. I.e. when I traceroute I see ingress PE, egress PE. Can you elaborate how it does not work? You see whole path? You're missing ingress/egress PE? IIRC no-propagate-ttl only takes affect after LSPs are recreated in JunOS, so enabling it runtime and you won't see it being on. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE + mpls no-propagate-ttl
Sorry I sent a mail too fast. Actually it works, my test was wrong. FYI : We used LDP for transport labels Thank you for the tip with RSVP. Best regards David David Roy IP/MPLS Support engineer - Orange France Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13 david@orange.com JNCIE-MT/SP #703 - JNCIE-ENT #305 - JNCIP-SEC -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de Saku Ytti Envoyé : mercredi 23 janvier 2013 16:39 À : juniper-nsp@puck.nether.net Objet : Re: [j-nsp] 6PE + mpls no-propagate-ttl On (2013-01-23 16:07 +0100), david@orange.com wrote: Did somebody have got trouble with no-propagate-ttl on 6PE environment ? It seems that it doesn't work for me in 11.4 Running mostly 11.4R3, R5, R6 here and it works for me. I.e. when I traceroute I see ingress PE, egress PE. Can you elaborate how it does not work? You see whole path? You're missing ingress/egress PE? IIRC no-propagate-ttl only takes affect after LSPs are recreated in JunOS, so enabling it runtime and you won't see it being on. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
On 1/21/13 11:44 PM, Saku Ytti wrote: On (2013-01-21 21:40 +0100), Markus H wrote: I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. a) 2xMX80 b) 1xMX240/480 with redundant SCB and RE a) no question. As long as you can live with modest RE performance of MX80. Routing separated two units always better than stateful single unit. Frankly, I'm not sure if dual RE even delivers better MTBF, since it does expose you to new issues, even outside HW failures. It probably does deliver you better MTTR though. I would always take two routers over one router with two RE's I have Lost RE's or crashed them in ways that a second RE helped enough to consider them worthwhile, and sometimes they make upgrading easier, but sometimes they make it harder, and it's pretty easy to justify trading lower cost and less complexity for modularity. The original poster I think raised the issue of load balancing between upstream(s). realistically that isn't that hard if you're architecture is designed to account for it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
