Re: ARIN's RPKI Relying agreement
i run rtconfig to take irr data and auto-install the fiter in my router i run rpki-rtr to take rpki date and auto-install the fiter in my router and the difference is? you ean we made the second easier and more automatable? well then run the rpki data into the handy dandy roa to irr filter and stuff it up rtconfig. randy
Re: ARIN's RPKI Relying agreement
On 05/12/2014 11:38, Randy Bush wrote: and the difference is? rpki might work at scale. Nick
Re: ARIN's RPKI Relying agreement
On Fri, 5 Dec 2014, Randy Bush wrote: and the difference is? rpki might work at scale. ohhh noo! fwiw, we had a script set running which took a route views dump, created an ersatz roa set covering the whole table, and fetched it into a small router or two. which implementation? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
CAs with dual stacked CRL/OCSP servers
At $DAYJOB, we have some applications that we would like to be all hipster and *actually check* for certificate revocation. I know this is way out there in terms of trendiness and may offend some folks. Difficulty: the clients are running on single stacked IPv6. We have recently been advised by our existing CA that they do not currently have IPv6 support plan (sic). OCSP Stapling sounds like it could be a winner here. Unfortunately, the software support is not quite ready yet on the platform on either end of the connection (client or server). So... we're looking around for a vendor that's taken the time to dual stack its servers. Any leads? -r
Re: ARIN's RPKI Relying agreement
fwiw, we had a script set running which took a route views dump, created an ersatz roa set covering the whole table, and fetched it into a small router or two. which implementation? dragon labs randy
possible twtelecom routing issue
Trying to gather information on a connectivity issue between TW Telecom and a specific government web server. If one of your upstream providers is TW Telecom, could you report back whether you have connectivity to https://safe.amrdec.army.mil. Thanks. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com
Re: ARIN's RPKI Relying agreement
On Dec 5, 2014, at 6:38 AM, Randy Bush ra...@psg.com wrote: i run rtconfig to take irr data and auto-install the fiter in my router i run rpki-rtr to take rpki date and auto-install the fiter in my router and the difference is? Not much - that's very likely why RIPE's IRR terms and conditions require the user to hold harmless, indemnify and defend the RIPE NCC; why registering for RADb requires agreeing to indemnify Merit, etc. Thanks, /John John Curran President and CEO ARIN
Re: CAs with dual stacked CRL/OCSP servers
Comodo's the only one I know off the top of my head. records on both the OCSP and CRL domains. On Fri, Dec 5, 2014 at 6:06 AM, Rob Seastrom r...@seastrom.com wrote: At $DAYJOB, we have some applications that we would like to be all hipster and *actually check* for certificate revocation. I know this is way out there in terms of trendiness and may offend some folks. Difficulty: the clients are running on single stacked IPv6. We have recently been advised by our existing CA that they do not currently have IPv6 support plan (sic). OCSP Stapling sounds like it could be a winner here. Unfortunately, the software support is not quite ready yet on the platform on either end of the connection (client or server). So... we're looking around for a vendor that's taken the time to dual stack its servers. Any leads? -r
Juniper MX Sizing
I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: ARIN's RPKI Relying agreement
On 05/12/2014 11:47, Randy Bush wrote: and the difference is? rpki might work at scale. ohhh noo! rtconfig + prefix lists were never going to work at scale, so rpsl based filters were mostly only ever deployed on asn edges rather than dfz core inter-as bgp sessions. This meant that the damage that a bad update might cause would be relatively limited in scope. RPSL's scaling limitations do not apply to rpki, so in theory the scope for causing connectivity problems is a good deal greater. So if e.g. ARIN went offline or signed some broken data which caused Joe's Basement ISP in Lawyerville to go offline globally, you can probably see why ARIN would want to limit its liability. Nick
Re: Juniper MX Sizing
Graham, We use both the MX240 and MX480 (for 100G) 1800REs. Very happy with this hardware. Jason Bothe, Manager of Networking o +1 713 348 5500 m +1 713 703 3552 ja...@rice.edu On 5, Dec 2014, at 10:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: Juniper MX Sizing
If you are looking for small foot print I +1 the 240s. On Fri, Dec 5, 2014 at 12:08 PM, Jason Bothe ja...@rice.edu wrote: Graham, We use both the MX240 and MX480 (for 100G) 1800REs. Very happy with this hardware. Jason Bothe, Manager of Networking o +1 713 348 5500 m +1 713 703 3552 ja...@rice.edu On 5, Dec 2014, at 10:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: Juniper MX Sizing
If you're looking at scaling passed the mx104, I would consider the mx480 chassis. The price delta between the 240 vs. 480 bare chassis is negligible and you'll get more slots to grow into. Especially, if you have a need to do sampling or anything else that may require a service pic. On Dec 5, 2014 9:02 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
RE: Juniper MX Sizing
Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.com think green; don't print this email. -Original Message- From: Shawn Hsiao [mailto:phs...@tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog@nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 06 Dec, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 520622 Prefixes after maximum aggregation: 200696 Deaggregation factor: 2.59 Unique aggregates announced to Internet: 254979 Total ASes present in the Internet Routing Table: 48743 Prefixes per ASN: 10.68 Origin-only ASes present in the Internet Routing Table: 36318 Origin ASes announcing only one prefix: 16308 Transit ASes present in the Internet Routing Table:6211 Transit-only ASes present in the Internet Routing Table:173 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 115 Max AS path prepend of ASN ( 55644) 76 Prefixes from unregistered ASNs in the Routing Table: 1627 Unregistered ASNs in the Routing Table: 435 Number of 32-bit ASNs allocated by the RIRs: 8081 Number of 32-bit ASNs visible in the Routing Table:6214 Prefixes from 32-bit ASNs in the Routing Table: 22182 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:391 Number of addresses announced to Internet: 2713242532 Equivalent to 161 /8s, 184 /16s and 203 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 176926 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 128952 Total APNIC prefixes after maximum aggregation: 37453 APNIC Deaggregation factor:3.44 Prefixes being announced from the APNIC address blocks: 133506 Unique aggregates announced from the APNIC address blocks:54196 APNIC Region origin ASes present in the Internet Routing Table:4996 APNIC Prefixes per ASN: 26.72 APNIC Region origin ASes announcing only one prefix: 1206 APNIC Region transit ASes present in the Internet Routing Table:858 Average APNIC Region AS path length visible:4.7 Max APNIC Region AS path length visible:115 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1203 Number of APNIC addresses announced to Internet: 737502080 Equivalent to 43 /8s, 245 /16s and 99 /24s Percentage of available APNIC address space announced: 86.2 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:171637 Total ARIN prefixes after maximum aggregation:85626 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 173591 Unique aggregates announced from the ARIN address blocks: 82042 ARIN Region origin ASes present in the Internet Routing Table:16391 ARIN Prefixes per
Re: Juniper MX Sizing
Then you should look for something other then the MX104. In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. On Dec 5, 2014, at 11:45 AM, Graham Johnston johnst...@westmancom.com wrote: Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.com think green; don't print this email. -Original Message- From: Shawn Hsiao [mailto:phs...@tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog@nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: Juniper MX Sizing
What’s a cheaper alternative to the MX104s? We take a full BGP table and are on the AMS-IX and DE-CIX and are looking for a new router. The MX series looks a bit out of budget but we’re currently looking into the Brocade MLX series. We push under 10Gbps, but we do need 10Gbps routing due to capacity issues during attacks. Sorry for being a bit off-topic here. Ammar This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. On Dec 6, 2014, at 12:01 AM, Brad Fleming bdfle...@gmail.com wrote: Then you should look for something other then the MX104. In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. On Dec 5, 2014, at 11:45 AM, Graham Johnston johnst...@westmancom.com wrote: Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.com think green; don't print this email. -Original Message- From: Shawn Hsiao [mailto:phs...@tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog@nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: Juniper MX Sizing
We haven’t received the MX480 gear yet (POs just went in about a week ago). But we tested MX960s with the same RE-S-1800x4 w/ 16GB RAM RIB+FIB convergence time was roughly 45sec. We never worried about getting a super accurate time for the MX960 because even an “eye test” showed it was fast enough for our application and we were much more concerned with other parts of the box. Also, we had inline-flow reporting configured on the MX960. Actually, the MX960’s had a full, production-ready config while the MX104 was tested with a stripped down after we discovered the slow convergence. Once we get some MX480s on the bench I’ll report back. On Dec 5, 2014, at 2:35 PM, Shawn Hsiao phs...@tripadvisor.com wrote: MX480 is also not instantaneous, so the same problem applies. Brad, do you have the number for MX480 for comparison? What we decided was, given both models suffer the same problems, just different duration, we decided to mitigate the problem and not spending the money. Thanks. On Dec 5, 2014, at 3:01 PM, Brad Fleming bdfle...@gmail.com wrote: Then you should look for something other then the MX104. In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. On Dec 5, 2014, at 11:45 AM, Graham Johnston johnst...@westmancom.com wrote: Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.com think green; don't print this email. -Original Message- From: Shawn Hsiao [mailto:phs...@tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog@nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: Juniper MX Sizing
We have both Brocade CER and XMR (predecessor to the MLXe) in our environment today. We find both platforms attractive from a price and power consumption standpoint. They will both handle the IPv4 and IPv6 unicast routing tables today.* The MLXe with MR2 cards is quite a formidable box; lots of power and pretty light-weight OS (compared to Junos). We found our XMR nodes with original mgmt cards and Gen1 line cards converge pretty quick; we’ve never timed one officially but my gut feeling is RIB+FIB convergence is roughly 45sec assuming your peer is RTT nearby. The CER is a little slower to converge in our experience; however, we have them in non-critical portions of the network so I can’t really attest to their convergence performance. Sorry.. not much in the way of lab readings for our Brocade gear. On Dec 5, 2014, at 2:09 PM, Ammar Zuberi am...@fastreturn.net wrote: What’s a cheaper alternative to the MX104s? We take a full BGP table and are on the AMS-IX and DE-CIX and are looking for a new router. The MX series looks a bit out of budget but we’re currently looking into the Brocade MLX series. We push under 10Gbps, but we do need 10Gbps routing due to capacity issues during attacks. Sorry for being a bit off-topic here. Ammar This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. On Dec 6, 2014, at 12:01 AM, Brad Fleming bdfle...@gmail.com mailto:bdfle...@gmail.com wrote: Then you should look for something other then the MX104. In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. On Dec 5, 2014, at 11:45 AM, Graham Johnston johnst...@westmancom.com mailto:johnst...@westmancom.com wrote: Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.com mailto:johnst...@westmancom.com think green; don't print this email. -Original Message- From: Shawn Hsiao [mailto:phs...@tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog@nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs
The Cidr Report
This report has been generated at Fri Dec 5 21:14:20 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
28-11-14525097 291796
29-11-14525194 291783
30-11-14524970 291808
01-12-14525076 291759
02-12-14525080 292208
03-12-14524889 288423
04-12-14525476 289213
05-12-14525863 289628
AS Summary
49001 Number of ASes in routing system
19687 Number of ASes announcing only one prefix
3045 Largest number of prefixes announced by an AS
AS10620: Telmex Colombia S.A.,CO
120175872 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 05Dec14 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 525895 289649 23624644.9% All ASes
AS6389 2892 92 280096.8% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS17974 2832 83 274997.1% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS22773 2919 173 274694.1% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS28573 2291 301 199086.9% NET Serviços de Comunicação
S.A.,BR
AS4755 1921 238 168387.6% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS4766 2956 1298 165856.1% KIXS-AS-KR Korea Telecom,KR
AS6147 1815 168 164790.7% Telefonica del Peru S.A.A.,PE
AS7303 1780 294 148683.5% Telecom Argentina S.A.,AR
AS10620 3045 1581 146448.1% Telmex Colombia S.A.,CO
AS9808 1494 58 143696.1% CMNET-GD Guangdong Mobile
Communication Co.Ltd.,CN
AS8402 1368 26 134298.1% CORBINA-AS OJSC Vimpelcom,RU
AS20115 1830 550 128069.9% CHARTER-NET-HKY-NC - Charter
Communications,US
AS4323 1654 413 124175.0% TWTC - tw telecom holdings,
inc.,US
AS7545 2495 1254 124149.7% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS9498 1293 113 118091.3% BBIL-AP BHARTI Airtel Ltd.,IN
AS18566 2041 868 117357.5% MEGAPATH5-US - MegaPath
Corporation,US
AS6983 1632 485 114770.3% ITCDELTA - Earthlink, Inc.,US
AS7552 1169 51 111895.6% VIETEL-AS-AP Viettel
Corporation,VN
AS34984 1902 864 103854.6% TELLCOM-AS TELLCOM ILETISIM
HIZMETLERI A.S.,TR
AS22561 1310 299 101177.2% AS22561 - CenturyTel Internet
Holdings, Inc.,US
AS7738 999 83 91691.7% Telemar Norte Leste S.A.,BR
AS4538 1836 949 88748.3% ERX-CERNET-BKB China Education
and Research Network
Center,CN
AS38285 981 110 87188.8% M2TELECOMMUNICATIONS-AU M2
Telecommunications Group
Ltd,AU
AS24560 1182 365 81769.1% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services,IN
AS31148 1045 228 81778.2% FREENET-AS Freenet Ltd.,UA
AS8151 1482 679 80354.2% Uninet S.A. de C.V.,MX
AS26615 915 133 78285.5% Tim Celular S.A.,BR
AS18101 955 192 76379.9% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI,IN
AS4780 1056 294 76272.2% SEEDNET Digital United Inc.,TW
AS17908 838 93 74588.9% TCISL Tata Communications,IN
BGP Update Report
BGP Update Report Interval: 27-Nov-14 -to- 04-Dec-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS23752 294408 6.0%2247.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 289126 5.9% 157.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS381689250 1.8% 97.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 4 - AS53249 80560 1.6% 40280.0 -- LAWA-AS - Los Angeles World Airport,US 5 - AS28024 55814 1.1% 36.6 -- Nuevatel PCS de Bolivia S.A.,BO 6 - AS10620 46311 0.9% 15.1 -- Telmex Colombia S.A.,CO 7 - AS17974 36080 0.7% 12.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 8 - AS17908 31932 0.7% 38.2 -- TCISL Tata Communications,IN 9 - AS475531098 0.6% 16.1 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 10 - AS38197 30497 0.6% 26.7 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 11 - AS28573 27909 0.6% 11.1 -- NET Serviços de Comunicação S.A.,BR 12 - AS3 24558 0.5%1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 13 - AS840223690 0.5% 16.1 -- CORBINA-AS OJSC Vimpelcom,RU 14 - AS42456 22374 0.5%1721.1 -- CHMURTZ-AS CHMURTZ SARL,FR 15 - AS28642 22317 0.5% 656.4 -- Contato Internet Ltda EPP,BR 16 - AS23342 22168 0.5% 554.2 -- UNITEDLAYER - Unitedlayer, Inc.,US 17 - AS45899 20830 0.4% 38.3 -- VNPT-AS-VN VNPT Corp,VN 18 - AS14840 20808 0.4% 594.5 -- COMMCORP COMUNICACOES LTDA,BR 19 - AS60725 20449 0.4%1202.9 -- O3B-AS O3b Limited,JE 20 - AS25003 20156 0.4% 544.8 -- INTERNET_BINAT Internet Binat Ltd,IL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS53249 80560 1.6% 40280.0 -- LAWA-AS - Los Angeles World Airport,US 2 - AS493178207 0.2%8207.0 -- KSPAB Kallmyra System Produktion AB,SE 3 - AS3 24558 0.5%1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 4 - AS621745560 0.1%5560.0 -- INTERPAN-AS INTERPAN LTD.,BG 5 - AS23752 294408 6.0%2247.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 6 - AS374872218 0.0%2218.0 -- GUINEANET,GQ 7 - AS478055577 0.1%1859.0 -- MCIT Ministry of Communications and Information,SA 8 - AS42456 22374 0.5%1721.1 -- CHMURTZ-AS CHMURTZ SARL,FR 9 - AS125213411 0.1%1705.5 -- NOVA_INTERNET_AS12521 Nova Internet Network,ES 10 - AS309441468 0.0%1468.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove DKD,LT 11 - AS35798 0.1%5144.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 12 - AS476807193 0.1%1438.6 -- NHCS EOBO Limited,IE 13 - AS568181301 0.0%1301.0 -- DONGISP-AS Communal Enterprise Informatization center of local selfgovern institutions Donetsk,UA 14 - AS617081216 0.0%1216.0 -- INFOCAT INFORMÁTICA LTDA,BR 15 - AS60725 20449 0.4%1202.9 -- O3B-AS O3b Limited,JE 16 - AS456065419 0.1%1083.8 -- 17 - AS31057 0.0%1349.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 18 - AS523552056 0.0%1028.0 -- Jalasoft Corp.,BO 19 - AS469991014 0.0%1014.0 -- CREWSBANKCORP - Crews Banking Corporation,US 20 - AS49941 0.2% 871.0 -- ISI-AS - University of Southern California,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 149326 2.9% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 143681 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 198.140.115.0/24 40292 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 4 - 198.140.114.0/24 40268 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 5 - 130.0.192.0/2124553 0.5% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - 64.29.130.0/2422129 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 7 - 192.115.44.0/22 19967 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 8 - 91.226.18.0/2411142 0.2% AS42456 -- CHMURTZ-AS CHMURTZ SARL,FR 9 - 185.26.155.0/24 11023 0.2% AS60725 -- O3B-AS O3b Limited,JE 10 - 192.58.232.0/24 10526 0.2% AS6629 -- NOAA-AS - NOAA,US 11 - 91.226.18.0/2310222 0.2% AS42456 -- CHMURTZ-AS CHMURTZ SARL,FR 12 - 42.83.48.0/20 10164 0.2% AS18135 -- BTV BTV Cable
Re: Juniper MX Sizing
Hi, Running MLXe with MR2 and/or CER-RT as MPLS PEs depending on POP size. We also run the later as route reflectors. They behave beautifully when it comes to churning BGP full feeds, convergence is around 30-45s (full RAM). Routing capacity is also amazing. I'm particularly amazed by the CER-RT from a price/performance/footprint perspective. So I would advice it unless the OP has some specific technical requirements (flowspec support, etc.). Best regards. Le 5 déc. 2014 à 22:52, Brad Fleming bdfle...@gmail.com a écrit : We have both Brocade CER and XMR (predecessor to the MLXe) in our environment today. We find both platforms attractive from a price and power consumption standpoint. They will both handle the IPv4 and IPv6 unicast routing tables today.* The MLXe with MR2 cards is quite a formidable box; lots of power and pretty light-weight OS (compared to Junos). We found our XMR nodes with original mgmt cards and Gen1 line cards converge pretty quick; we’ve never timed one officially but my gut feeling is RIB+FIB convergence is roughly 45sec assuming your peer is RTT nearby. The CER is a little slower to converge in our experience; however, we have them in non-critical portions of the network so I can’t really attest to their convergence performance. Sorry.. not much in the way of lab readings for our Brocade gear. On Dec 5, 2014, at 2:09 PM, Ammar Zuberi am...@fastreturn.net wrote: What’s a cheaper alternative to the MX104s? We take a full BGP table and are on the AMS-IX and DE-CIX and are looking for a new router. The MX series looks a bit out of budget but we’re currently looking into the Brocade MLX series. We push under 10Gbps, but we do need 10Gbps routing due to capacity issues during attacks. Sorry for being a bit off-topic here. Ammar This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. On Dec 6, 2014, at 12:01 AM, Brad Fleming bdfle...@gmail.com mailto:bdfle...@gmail.com wrote: Then you should look for something other then the MX104. In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. On Dec 5, 2014, at 11:45 AM, Graham Johnston johnst...@westmancom.com mailto:johnst...@westmancom.com wrote: Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.com mailto:johnst...@westmancom.com think green; don't print this email. -Original Message- From: Shawn Hsiao [mailto:phs...@tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog@nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote:
Re: Cisco CCNA Training (Udemy Discounted Training)
I would be interested in these as well. On 12/4/14, 12:25 PM, Paul S. cont...@winterei.se wrote: Share them anyway? Juniper's certs have enough demand as well :) On 12/5/2014 午前 05:13, Eric Litvin wrote: have some juniper but not cisco. On Thu, Dec 4, 2014 at 12:08 PM, Bacon Zombie baconzom...@gmail.com wrote: Anybody got codes valid for December? On 14 Nov 2014 18:07, Wakefield, Thad M. twakefi...@stcloudstate.edu wrote: Since there was some interest in the Udemy CCNA training, I'll risk forwarding these additional discounts: Remember that this is ONLY for the month of NOVEMBER! *** CCNA Course is now $24 with coupon code: THANKS24 https://www.udemy.com/the-complete-ccna-200-120-course/?couponCode=THANK S24 *** ROUTING Course is now $14 with coupon code: THANKS14 https://www.udemy.com/routing-configuration-router-administration/?coupo nCode=THANKS14 *** SWITCHING Course is now $9 with coupon code: THANKS9 https://www.udemy.com/layer-2-switching-vlans/?couponCode=THANKS9 *** IPv4 Course is now $9 with coupon code: THANKS9 https://www.udemy.com/everything-you-need-to-know-about-ipv4-and-its-con figuration/?couponCode=THANKS9 *** IPv6 Course is now $9 with coupon code: THANKS9 https://www.udemy.com/the_abcs_of_ipv6/?couponCode=THANKS9 *** VLANs Course is now $5 with coupon code: THANKS5 https://www.udemy.com/overview-of-vlans-access-list-nat-bonus-material/? couponCode=THANKS5 *** OSPF Course is now $14 with coupon code: THANKS14 https://www.udemy.com/ospf-breakdown/?couponCode=THANKS14 *** HEX Course is FREE *** use coupon code: THANKSFREE https://www.udemy.com/learn-how-to-do-hex-conversions-in-under-30-second s/?couponCode=THANKSFREE
Re: Juniper MX Sizing
Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: Juniper MX Sizing
MX480 is also not instantaneous, so the same problem applies. Brad, do you have the number for MX480 for comparison? What we decided was, given both models suffer the same problems, just different duration, we decided to mitigate the problem and not spending the money. Thanks. On Dec 5, 2014, at 3:01 PM, Brad Fleming bdfle...@gmail.com wrote: Then you should look for something other then the MX104. In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. On Dec 5, 2014, at 11:45 AM, Graham Johnston johnst...@westmancom.com wrote: Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.com think green; don't print this email. -Original Message- From: Shawn Hsiao [mailto:phs...@tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog@nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com wrote: I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnst...@westmancom.commailto:johnst...@westmancom.com P think green; don't print this email.
Re: ARIN's RPKI Relying agreement
rpki might work at scale. ohhh noo! rtconfig + prefix lists were never going to work at scale, so rpsl based filters were mostly only ever deployed on asn edges rather than dfz core inter-as bgp sessions. This meant that the damage that a bad update might cause would be relatively limited in scope. RPSL's scaling limitations do not apply to rpki, so in theory the scope for causing connectivity problems is a good deal greater. So if e.g. ARIN went offline or signed some broken data which caused Joe's Basement ISP in Lawyerville to go offline globally, you can probably see why ARIN would want to limit its liability. if it works, it is scary and must be stopped! and arin is doing such a great job of that. randy
