Re: Standard for BGP community lists
On (2010-07-19 23:45 -0500), Brad Fleming wrote: Hey, : for local rtbh : for local + remote rtbh I didn't have much reason for selecting other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks. I would recommend against using other public ASNs for internal signalling, ASN part should be considered property of given ASN. AS might want to use to signal particular source where route was learned and your customer might want to do TE with it. Now you must delete them on ingress and rob your customers of this possibility. Hopefully future community (*wink*wink*blink*blink* Raszuk) standards will explicitly state that this is faux pas. -- ++ytti
[NANOG-announce] Registration open for NANOG 50 - Atlanta, GA
Registration is now open for the 50th Meeting of the North American Network Operators' Group. NANOG 50 will be held October 3-6 in the new Loews Atlanta Hotel in Midtown. The meeting will be hosted by Telx. The meeting will be back-to-back with ARIN XXVI. A joint NANOG/ARIN program will be presented on the morning of October 6, featuring IPv6 deployment experiences. ARIN XXVI will continue through October 8. See http://www.nanog.org/meetings/nanog50/index.php for complete meeting details, and follow the important links on the left to submit presentations, register, and reserve your hotel room. Please note there are tiered rates for registration, so plan to register early to take advantage of the best rate. If you need lodging you are encouraged to make your reservation early, as rooms are limited. The NANOG group rate expires on September 15 or when filled. See you in Atlanta this fall! Steve Feldman NANOG Steering Committee Chair ___ NANOG-announce mailing list nanog-annou...@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
QppB and SCU/DCU
Experts, is there a standard comprising these 2 vendor specific implementations of the ~same~ feature? Thanks, bit.
Re: Vyatta as a BRAS
If there is sufficient CPU power (and I/O to the CPU) as compared to the bandwidth, then this is doable. Tony On Jul 19, 2010, at 11:40 PM, Akyol, Bora A wrote: Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. In some systems, just the act of receiving the packet in the ISR and classifying it into a bucket is enough to overwhelm the system without proper hardware assist. Bora -Original Message- From: Mark Smith [mailto:na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Monday, July 19, 2010 2:39 AM To: Tim Durack Cc: NANOG list Subject: Re: Vyatta as a BRAS And that's the crux of the issue. Can the box survive if line rate maximum PPS is being aimed at it, either for forwarding or at the control plane? If the answer is yes, then whether it is a software router or hardware router is academic.
Re: While we worry about Vyatta and Bras.....
On Mon, Jul 19, 2010 at 05:21:31PM -0700, Jeroen van Aart wrote: Burstnet huh? Somehow I am not surprised. Currently I have the below in my blocklists. Since this company facilitates spammers and other dubious activity and doesn't look like it hosts much legitimate content. They've been doing a lot of both for a decade. Others have noticed as well: http://groups.google.com/group/news.admin.net-abuse.email/msg/fba14415f70e08c8 I strongly recommend blacklisting/null-routing anything they touch. ---Rsk
Multicast Network Monitoring
Curious if anyone has any experience with tools specifically for monitoring multicast. Finds where the trees are, paths they are on, tracks all senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast Manager, CA Spectrum? The good and the bad? Worth the effort/investment? Thanks
RE: Multicast Network Monitoring
Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree Date: Tue, 20 Jul 2010 08:59:13 -0400 Subject: Multicast Network Monitoring From: rjsa...@gmail.com To: nanog@nanog.org Curious if anyone has any experience with tools specifically for monitoring multicast. Finds where the trees are, paths they are on, tracks all senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast Manager, CA Spectrum? The good and the bad? Worth the effort/investment? Thanks
Re: Multicast Network Monitoring
On Tue, Jul 20, 2010 at 4:11 PM, Brandon Kim brandon@brandontek.comwrote: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree Shameless plug, I once developed a tool which was called multicast weathermap. You can see what remains of it here: http://netmon.grnet.gr/multicast-map.shtml (hover over the nodes and the links and you can see various useful info) (you can see the tree of a specific group by selecting from the drop down list at the bottom) and the presentation here http://tnc2004.terena.org/programme/presentations/show2c2c.html?pres_id=47 Since I too myself am into multicast, I intended to incorporate into it everything needed to know everything. But eventually it was left as it is. Apart from that, the NNM advanced used to have a multicast plugin, and it was fairly usable. You could take a look at it probably, but I don't know whether it can handle those MPLS cases you mention. Lastly, those guys at Poznan used to work on a tool called Muvi http://muvi.man.poznan.pl/ You may want to take a look, although I fear it too has been abandoned. Best Regards, Athanasios Date: Tue, 20 Jul 2010 08:59:13 -0400 Subject: Multicast Network Monitoring From: rjsa...@gmail.com To: nanog@nanog.org Curious if anyone has any experience with tools specifically for monitoring multicast. Finds where the trees are, paths they are on, tracks all senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast Manager, CA Spectrum? The good and the bad? Worth the effort/investment? Thanks
RE: Multicast Network Monitoring
Wow that looks great! The URL has an extra dot before the SHTML though when you click on it. Easy fix though. Are there no commercial applications for this kind of monitoring? I see your graphs are powered by MRTG. =) Date: Tue, 20 Jul 2010 17:39:17 +0300 Subject: Re: Multicast Network Monitoring From: aduit...@gmail.com To: brandon@brandontek.com CC: nanog@nanog.org On Tue, Jul 20, 2010 at 4:11 PM, Brandon Kim brandon@brandontek.com wrote: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree Shameless plug, I once developed a tool which was called multicast weathermap. You can see what remains of it here: http://netmon.grnet.gr/multicast-map.shtml (hover over the nodes and the links and you can see various useful info)(you can see the tree of a specific group by selecting from the drop down list at the bottom) and the presentation here http://tnc2004.terena.org/programme/presentations/show2c2c.html?pres_id=47 Since I too myself am into multicast, I intended to incorporate into it everything needed to know everything. But eventually it was left as it is. Apart from that, the NNM advanced used to have a multicast plugin, and it was fairly usable. You could take a look at it probably, but I don't know whether it can handle those MPLS cases you mention. Lastly, those guys at Poznan used to work on a tool called Muvi http://muvi.man.poznan.pl/You may want to take a look, although I fear it too has been abandoned. Best Regards,Athanasios Date: Tue, 20 Jul 2010 08:59:13 -0400 Subject: Multicast Network Monitoring From: rjsa...@gmail.com To: nanog@nanog.org Curious if anyone has any experience with tools specifically for monitoring multicast. Finds where the trees are, paths they are on, tracks all senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast Manager, CA Spectrum? The good and the bad? Worth the effort/investment? Thanks
Re: While we worry about Vyatta and Bras.....
On Mon, 19 Jul 2010 18:36:57 EDT, Marshall Eubanks said: None of this is going to help configure any routers. Most people call a network of routers run in isolation, without any care or consideration of the outside world and its potential impact on operations, a test lab. The occasional injection of external reality is useful. And I dunno - some of us may indeed configure our routers differently after being reminded that we could get a letter from the FBI similar to the one that Burstnet got. When was the last time you checked your routers to ensure that they implemented the action your corporate policy dictates for receipt of such a letter? pgpjh6tHtOqkL.pgp Description: PGP signature
Re: Standard for BGP community lists
On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote: On (2010-07-19 23:45 -0500), Brad Fleming wrote: Hey, : for local rtbh : for local + remote rtbh I didn't have much reason for selecting other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks. I would recommend against using other public ASNs for internal signalling, ASN part should be considered property of given ASN. AS might want to use to signal particular source where route was learned and your customer might want to do TE with it. Now you must delete them on ingress and rob your customers of this possibility. IMO, any reasonable routing policy would reset all BGP communities on ingress (and MEDs for that matter), whether from a customer or peer, as transiting stuff that has varying semantic interpretations, unknown propagation scope, or relying on others to act on non-mandatory not-well-known communities that may not even be propagated in some BGP configurations as a matter of default behavior, is a simple recipe for nondeterministic behavior, more senseless path attribute tuples in the global routing system, resulting in less efficient BGP update packing, and may even result in security issues. And customer ingress policy can always be crafted to accommodate the upstream special handling policies for RFC1998+ functions, as well as source and destination-based RTBH and other capabilities, across one or more ISPs, even if they vary. There have been some spirited discussions on the specification of more well-known communities for functions related to this and other applications in various IETF working groups, from IDR and GROW to OPSEC and L3VPN, for those interested in having a gander... -danny
Re: Multicast Network Monitoring
On Tue, 20 Jul 2010 08:59:13 -0400 Robert Sager rjsa...@gmail.com wrote: Curious if anyone has any experience with tools specifically for monitoring multicast. Finds where the trees are, paths they are on, tracks all senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast Manager, CA Spectrum? The good and the bad? Worth the effort/investment? I've never seen or used those vendor-specific tools so I can't comment on them. IP multicast can be extremely complex. I'd be interested in hearing if they are any good and what is good about them if so. There have been a handful of community built tools over the years, but nothing as I recall is very comprehensive. What is available now tends to be a defunct research project or simply no longer supported. CAIDA has a small list of some older tools here: http://www.caida.org/tools/taxonomy/multicast.xml Marshall Eubanks had one of the best global views of IP multicast, but it too does not appear to be supported any longer: http://www.multicasttech.com/status/ I had a very cheesey SNMP-based cli tool that grabbed some numbers of useful IP multicast-related OIDs that probably still works: http://aharp.ittns.northwestern.edu/software/mcastsum There were a couple of multicast beacon projects, which was a useful way to see how others view your IP multicast connectivity and vice versa. Doesn't look like those are running any longer I'm afraid. I've thought about reincarnating some things I've done or building on some prior work, but there seems to be so little call for IP multicast tools that I haven't been able to justify the time investment. I'd be interested in hearing if there are lots of folks now clamoring for something. John
[NANOG-announce] Please get your talks in for NANOG 50
Folks, NANOG 50 is looming. If you have content you'd like to present, please go to pc.nanog.org, create a username (if you don't have one), and upload your materials. Thanks, Dave (for the NANOG PC) ___ NANOG-announce mailing list nanog-annou...@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: Vyatta as a BRAS
On Monday, July 19, 2010 05:40:07 pm Akyol, Bora A wrote: Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. And then there are Systems on a Chip (SoC) like the Realtek 8650 that really take it to another level. See http://www.csie.nctu.edu.tw/~cfliu/work/8650.htm for more information; by most definitions here this would be a SoC 'hardware' router. It's in many very low cost SoHo devices, such as NetGear FVS114.
Re: Multicast Network Monitoring
On 7/20/2010 06:11, Brandon Kim wrote: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree Is it just me, or is anyone else receiving multiple copies of this same message? ~Seth
RE: Multicast Network Monitoring
9 Copies here. The headers seem to show a bit of bouncing around inside cisco.com -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Wednesday, 21 July 2010 12:22 PM To: nanog@nanog.org Subject: Re: Multicast Network Monitoring On 7/20/2010 06:11, Brandon Kim wrote: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi- casts and being able to see the pattern/tree Is it just me, or is anyone else receiving multiple copies of this same message? ~Seth
Re: Multicast Network Monitoring
On Jul 20, 2010, at 10:29 PM, Jay Mitchell wrote: 9 Copies here. The headers seem to show a bit of bouncing around inside cisco.com Maybe they are having issues with their multicast mail routing protocol. Regards Marshall -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Wednesday, 21 July 2010 12:22 PM To: nanog@nanog.org Subject: Re: Multicast Network Monitoring On 7/20/2010 06:11, Brandon Kim wrote: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi- casts and being able to see the pattern/tree Is it just me, or is anyone else receiving multiple copies of this same message? ~Seth
Re: Multicast Network Monitoring
On Tue, 20 Jul 2010, Marshall Eubanks wrote: Maybe they are having issues with their multicast mail routing protocol. Looks like their mmrpf (multicast mail reply path forwarding) is broken ;) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Re: Multicast Network Monitoring
On Tue, Jul 20, 2010 at 9:44 PM, Antonio Querubin t...@lava.net wrote: On Tue, 20 Jul 2010, Marshall Eubanks wrote: Maybe they are having issues with their multicast mail routing protocol. Looks like their mmrpf (multicast mail reply path forwarding) is broken ;) Or.. perhaps someone over there just turned on smrp routing ? You know.. SMRP ( Sadistic Mail Replication Protocol )g -- -JH
Re: Standard for BGP community lists
On Tue, Jul 20, 2010 at 09:34:40AM -0600, Danny McPherson wrote: On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote: On (2010-07-19 23:45 -0500), Brad Fleming wrote: Hey, : for local rtbh : for local + remote rtbh I didn't have much reason for selecting other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks. I would recommend against using other public ASNs for internal signalling, ASN part should be considered property of given ASN. AS might want to use to signal particular source where route was learned and your customer might want to do TE with it. Now you must delete them on ingress and rob your customers of this possibility. IMO, any reasonable routing policy would reset all BGP communities on ingress (and MEDs for that matter), whether from a customer or peer, as transiting stuff that has varying semantic interpretations, unknown propagation scope, or relying on others to act on non-mandatory not-well-known communities that may not even be propagated in some BGP configurations as a matter of default behavior, is a simple recipe for nondeterministic behavior, more senseless path attribute tuples in the global routing system, resulting in less efficient BGP update packing, and may even result in security issues. We're still seeing buffer overflows, so people obviously fail to generalize about sanitizing input. One would think the need is more obvious for signalling protocols, but expecting people to DTRT often results in disappointment. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
