Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Sun, 25 Jan 2004, Alexei Roudnev wrote: Of course, if they want L3 routing on every box (I do not like such idea, but it's possible), then 3550 (or what do they have now?) is the best choice. Definately not. The 3550 is an overpriced outdated product with moderate performance with way too small table sizes. For instance: The Summit48si handles 128k MAC addresses. The 3550 handles something like 6-15k. The Summit48si can do buffering when doing QoS/shaping, the 3550 does only policing. If you want to deliver a 2meg service over ethernet to a customer, this is a big issue. There is only one product in the 3550 line that is pricewise worth getting is the 3550-12G if you need to do L2 gig aggregation to 1gig uplink and you do not have many VLANs. There are three issues I see where the 3550 actually has a selling point: VRFs (even though they are too few) Q-in-Q (limited by the small mac table size) CEF (if you have very small routing table size and no broadcasts) -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
1) Cisco ISL is much better than urgly 802.1q - first of all, it was designed many years before 802.1q. I am not even talking abiout those idiots, who designed 802.1q as a _spanning tree on the trunk level_, which made many configurations (which we used with ISL ain 199x years) impossble, and caused vendors to extend 802.1q. 2) Of course, VLAN does not infer routing. But VLAN routing can be provided on the switch fabric, effectively bypassing many traditional drawbacks - see Cisco 6509, for example. - Original Message - From: Brian Wallingford [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: ken emery [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 25, 2004 10:17 PM Subject: Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs? On Sun, 25 Jan 2004, Alexei Roudnev wrote: : :L3 switchiong is just term for idiots - it is ROUTING in old terms. So, :VLAN's means _routing_. Um, no, VLAN does not infer routing. 802.1q and even Cisco's ugly proprietary ISL both operate at layer two. As to L3 switching and the spin involved in such, it's an old, predictable story, which we all wrote off as marketing drivel at least a couple years ago...
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
3550 runs IOS. That's an answer. I never allow any non-IOS router in production environment (except high end devices, such as Juniper, when benefits are very high). And 3550 is not expansive (yes, it is not cheap). PS. How much ethernet ports do you have in the office? Do you have 100 K ports? If not, why do you need 128K MAC's? (I know only one case, when I need so much - some kind of DSL service... In most cases, you have 500 - 5,000 ports in one building. If you have more, it is unlikely that you use 3550 switches. So, it is enough for the tasks (just as performance - it have _enough_ performance). Btw, I believed that catalist swithes have not any limitations for the MAC tables (because they use memory _on demand_); where did you get this limitations? /I may be wrong here/ PPS. I do not know for sure, but 3550 should support traffic shaping, which makes bufferring. Technically, yes, CEF (with packet dropping) is not good to provide 2 Mbit by 100 Mbit link. On Sun, 25 Jan 2004, Alexei Roudnev wrote: Of course, if they want L3 routing on every box (I do not like such idea, but it's possible), then 3550 (or what do they have now?) is the best choice. Definately not. The 3550 is an overpriced outdated product with moderate performance with way too small table sizes. For instance: The Summit48si handles 128k MAC addresses. The 3550 handles something like 6-15k. The Summit48si can do buffering when doing QoS/shaping, the 3550 does only policing. If you want to deliver a 2meg service over ethernet to a customer, this is a big issue. There is only one product in the 3550 line that is pricewise worth getting is the 3550-12G if you need to do L2 gig aggregation to 1gig uplink and you do not have many VLANs. There are three issues I see where the 3550 actually has a selling point: VRFs (even though they are too few) Q-in-Q (limited by the small mac table size) CEF (if you have very small routing table size and no broadcasts) -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Mon, 26 Jan 2004, Alexei Roudnev wrote: PS. How much ethernet ports do you have in the office? Do you have 100 K ports? If not, why do you need 128K MAC's? (I know only one case, when I need so much - some kind of DSL service... I guess you're not into metro networking. (just as performance - it have _enough_ performance). Btw, I believed that catalist swithes have not any limitations for the MAC tables (because they use memory _on demand_); where did you get this limitations? /I may be wrong here/ http://www.cisco.com/en/US/customer/products/hw/switches/ps646/products_tech_note09186a0080094bc6.shtml You have something like 16-24.000 entries which are shared between routes, QoS, mac adress table size etc. Default is 5k mac adress size on the 3550-24/48. For metro applications, this is not enough. PPS. I do not know for sure, but 3550 should support traffic shaping, which makes bufferring. Technically, yes, CEF (with packet dropping) is not good to provide 2 Mbit by 100 Mbit link. The 3550 doesnt support shaping of any kind, only policing (dropping packets, never buffer them). How can you advocate a switch which you seem to know so little about? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
3550 runs IOS. That's an answer. I never allow any non-IOS router in production environment (except high end devices, such as Juniper, when benefits are very high). And 3550 is not expansive (yes, it is not cheap). If you believe that IOS solves all problems, we live on different planets. PS. How much ethernet ports do you have in the office? Do you have 100 K ports? If not, why do you need 128K MAC's? (I know only one case, when I need so much - some kind of DSL service... Some kind of DSL service is indeed the background for my question. In most cases, you have 500 - 5,000 ports in one building. If you have more, it is unlikely that you use 3550 switches. So, it is enough for the tasks (just as performance - it have _enough_ performance). Btw, I believed that catalist swithes have not any limitations for the MAC tables (because they use memory _on demand_); where did you get this limitations? /I may be wrong here/ If you believe Catalyst switches have no MAC address limitations, I have a nice plot of land in Florida to sell you :-) Ethernet switches today use CAM to hold the MAC address tables - this CAM has a finite size. PPS. I do not know for sure, but 3550 should support traffic shaping, which makes bufferring. Technically, yes, CEF (with packet dropping) is not good to provide 2 Mbit by 100 Mbit link. 3550 only supports policing. Yes, I have worked extensive with 3550 and it doesn't have the features I need right now. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
DNS Rootservers go international
http://www.theregister.co.uk/content/6/35070.html -Hank
test
Re: Outbound Route Optimization
BGP is relatively good at determining the best path when you a major carrier with connectivity to everyone (i.e. when traffic flows naturally), in many locations, and you engineer your network so that you have sufficient capacity to support the traffic flows. In other words, BGP really only works well when most networks are overbuilt so that there is a single uncongested best path through each network from every ingress to every egress and the paths within any given network's core are roughly similar in capacity. Nowadays there is a lot more variability both within networks and between different networks. How can a simple protocol provide optimal behavior between an MPLS network, an IP over ATM network, a network that is half GRE tunnels, and a network that has core links ranging from DS3 to OC48? I think BGP is another example where something that is good enough has risen to prominence in spite of the fact that it is not optimal. And another thing. How do we know this problem can ever be solved when we continue to use routing protocols which choose the *BEST* path. The best path is always a single path and, by definition, this is a single point of failure. How can we ever have a diverse and reliable network when its core routing paradigm is a single point of failure? Note that people have built IP networks that provide two diverse paths at all times using multicast http://www.simc-inc.org/archive9899/Jun01-1999/bach2/Default.htm and such things may also be possible with MPLS. But are any of the researchers seriously looking at how to provide a network in which all packets flow through two diverse paths to provide better reliability? --Michael Dillon
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
3550 runs IOS. this is a benefit, especially in a switch? randy
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
3550 runs IOS. this is a benefit, especially in a switch? If your whole support organization is geared towards IOS, and unable to learn other CLIs, it may well be. Fortunately, not all support organizations are like that :-) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Sun, 25 Jan 2004, Jeff Kell wrote: We're running 30 SVIs on a 3550-12 (only 10 active at the moment, we're in a transition). It is an aggregation switch that feeds back via L3. According to the documentation on the Cisco site: http://www.cisco.com/warp/public/473/145.html The 3550-12 is only capable of handling 16 SVIs in hardware (regardless of SDM template), after that you get into resource exhaustion which means it add the SVIs, but will go back to software/CPU-based routing. Does the 3550/3750 give any indication that it's in this state (software routing) other than melting under high traffic volumes? We're currently waiting on Cisco getting back to us on figures for the 3750, but given that it has a similar TCAM setup to the 3550-12, I'd doubt it would be different. Rich
Re: Outbound Route Optimization
On Mon, 26 Jan 2004 10:30:38 -0500 [EMAIL PROTECTED] wrote: Yes, we can probably make something better than BGP. But will we be able to understand it? I thought this was a good measure of that question... from the current draft-irtf-routing-reqs draft: 2.1.17 Simplicity The architecture MUST be simple enough so that Radia Perlman can explain all the important concepts in less than an hour. :-) John
Re: Outbound Route Optimization
Although in principle I agree with what you say here, I will point out that the number and frequency of significant network outages (excluding things like the recent power failure in LAX) has become rare as compared to what they were 5 or 6 years ago. Part of this is due to attitudes about the 'net maturing, part due to increased experience of the average engineer, and part due to things such as MPLS fast reroute. I would also point out that, although there remain single points of interconnect, MPLS has meant that the path packets take intra-network doesn't have to be a single route between two boxes. BGP picks the exit point and engineers have configured MPLS to spread the traffic over 3 or 4 tunnels to get there thereby reducing the impact of a single failure. But as you say, this really gets into the realm of overbuilt backbones which, of course, not everyone has. BGP isn't the best. I think many people have recognized that for some years now. However, when propperly managed, it suits current needs. Perhaps it's time for the next generation of BGP to come into being; something that can use up to 4 paths through a network for any single destination rather than simply leaving alternate paths innactive until something changes. Heavens knows there are many instances where there are two or more good (and even equal) paths through a network that are not chosen simply because we're only allowed one. On Mon, Jan 26, 2004 at 10:35:38AM +, [EMAIL PROTECTED] wrote: BGP is relatively good at determining the best path when you a major carrier with connectivity to everyone (i.e. when traffic flows naturally), in many locations, and you engineer your network so that you have sufficient capacity to support the traffic flows. In other words, BGP really only works well when most networks are overbuilt so that there is a single uncongested best path through each network from every ingress to every egress and the paths within any given network's core are roughly similar in capacity. Nowadays there is a lot more variability both within networks and between different networks. How can a simple protocol provide optimal behavior between an MPLS network, an IP over ATM network, a network that is half GRE tunnels, and a network that has core links ranging from DS3 to OC48? I think BGP is another example where something that is good enough has risen to prominence in spite of the fact that it is not optimal. And another thing. How do we know this problem can ever be solved when we continue to use routing protocols which choose the *BEST* path. The best path is always a single path and, by definition, this is a single point of failure. How can we ever have a diverse and reliable network when its core routing paradigm is a single point of failure? Note that people have built IP networks that provide two diverse paths at all times using multicast http://www.simc-inc.org/archive9899/Jun01-1999/bach2/Default.htm and such things may also be possible with MPLS. But are any of the researchers seriously looking at how to provide a network in which all packets flow through two diverse paths to provide better reliability? --Michael Dillon --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Jan 26, 2004, at 2:04 AM, Alexei Roudnev wrote: 1) Cisco ISL is much better than urgly 802.1q - first of all, it was designed many years before 802.1q. I am not even talking abiout those idiots, who designed 802.1q as a _spanning tree on the trunk level_, which made many configurations (which we used with ISL ain 199x years) impossble, and caused vendors to extend 802.1q. Is it April 1st? ISL changes the size of packets, does it not? So know you have to deal with MTU issues. What happens when I want the biggest MTU possible? I know it is not much a difference in size, but for some people, size does matter. I am quite happy with dot1q. My gripe is with poor spanning-tree implementations. I don't want a single spanning-tree for every vlan on a trunk... I like standards, but I am happy with Rapid-PVST. Just my feelings about the issue. I would never deploy ISL unless I had something like a 1900 that did not do dot1q 2) Of course, VLAN does not infer routing. But VLAN routing can be provided on the switch fabric, effectively bypassing many traditional drawbacks - see Cisco 6509, for example. Are you talking about multilayer switching implementations? That is why C came out with dCEF. I costs, but if you want to do serious routing, damn if it ain't fast ;-) - Original Message - From: Brian Wallingford [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: ken emery [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 25, 2004 10:17 PM Subject: Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs? On Sun, 25 Jan 2004, Alexei Roudnev wrote: : :L3 switchiong is just term for idiots - it is ROUTING in old terms. So, :VLAN's means _routing_. Um, no, VLAN does not infer routing. 802.1q and even Cisco's ugly proprietary ISL both operate at layer two. As to L3 switching and the spin involved in such, it's an old, predictable story, which we all wrote off as marketing drivel at least a couple years ago...
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
ISL _DOES NOT CHANGE_ packet size. Is it April 1st? ISL changes the size of packets, does it not? So know you have to deal with MTU issues. What happens when I want the biggest MTU possible? I know it is not much a difference in size, but for some people, size does matter. I am quite happy with dot1q. My gripe is with poor spanning-tree 2) Of course, VLAN does not infer routing. But VLAN routing can be provided on the switch fabric, effectively bypassing many traditional drawbacks - see Cisco 6509, for example. Are you talking about multilayer switching implementations? That is why C came out with dCEF. I costs, but if you want to do serious routing, damn if it ain't fast ;-) Agree in general.
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
1) Cisco ISL is much better than urgly 802.1q - first of all, it was designed many years before 802.1q. I am not even talking abiout those idiots, who designed 802.1q as a _spanning tree on the trunk level_, which made many configurations (which we used with ISL ain 199x years) impossble, and caused vendors to extend 802.1q. Is it April 1st? ISL changes the size of packets, does it not? So know you have to deal with MTU issues. What happens when I want the biggest MTU possible? I know it is not much a difference in size, but for some people, size does matter. I am quite happy with dot1q. My gripe is with poor spanning-tree implementations. I don't want a single spanning-tree for every vlan on a trunk... I like standards, but I am happy with Rapid-PVST. Just my feelings about the issue. I would never deploy ISL unless I had something like a 1900 that did not do dot1q Amen. At my previous employer, we got rid of ISL on almost all trunks. I wouldn't dream of going back. The only thing I don't really like about 802.1q compared to ISL is the idea of native or default VLAN. I want links to be either access (untagged) or trunk (*all* packets tagged). Fortunately, reasonably new Cisco switches let me enforce that with vlan dot1q tag native. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
ISL _DOES NOT CHANGE_ packet size. An 802.1q tag adds 4 bytes to the Ethernet frame. ISL encapsulation adds 30 bytes to the Ethernet frame. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
PS. How much ethernet ports do you have in the office? Do you have 100 K ports? If not, why do you need 128K MAC's? (I know only one case, when I need so much - some kind of DSL service... I guess you're not into metro networking. This is one of my exceptions - you really need 128K MAC's for meto network. And, for metro network, it may be reasonable to spend time in QA'ing and configuration and select non-cisco solution - because it is a very big project. But it is exceptional case. PPS. I do not know for sure, but 3550 should support traffic shaping, which makes bufferring. Technically, yes, CEF (with packet dropping) is not good to provide 2 Mbit by 100 Mbit link. The 3550 doesnt support shaping of any kind, only policing (dropping packets, never buffer them). How can you advocate a switch which you seem to know so little about? I just never tried to configure 'traffic-shape' on it, so I do not know. It is great switch for it's niche. Metro LAN's is not standard switch niche, it is very special network. As I said above, non-cisco solution can paid off for this. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Outbound Route Optimization
] 2.1.17 Simplicity ] ] The architecture MUST be simple enough so that Radia Perlman can ] explain all the important concepts in less than an hour. Oh, phew, good thing that isn't me. I've never been able to explain anything in less than an hour. :) -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Outbound Route Optimization
Richard, you have made some good points in this thread. One general observation, and then specific responses ... I don't assert that current route optimization technology solves ALL routing problems, but do think that there are some specific problems that automation can effectively, and gracefully solve. * The inability to receive FULL bgp routes from every bgp peer to your optimization box without requiring your transit providers to set up a host of eBGP Multihop sessions (which most refuse to do). This means you will always be stuck assuming that every egress path is a transit and can reach any destination on the Internet until your active or passive probing says otherwise. The issue that you describe does indeed offer some constraints to the application of route optimization technology. Within the scope of this issue, though, I think that you would agree that a network which is ALL transit would face no challenge here -- and more specifically, if there is a routing optimization decision among local transit links, that problem could be solved independantly of the existance of non-transit links. Applying this technology in the presence of non- transit routes requires constraining measurments to only the prefixes appropriate for a given link. It is true that knowing all BGP routes (BGP Losers) would be a nice way to get this information ... but it's not necessarily the only approach towards the goal. Some solutions may have topological dependancies, but it can be feasible to simply drop all measurement towards illegal destinations. In other cases, it may be possible to define the set of destinations that are legal over a given link, and constrain measurements for that link. * The requirement of deaggregation in order to make best path decisions effective. For example, someone's T3 to genuithree gets congested and the best path to their little /24 of the Internet is through another provider. Do you move 4.0.0.0/8? Perhaps. Yes, it's a /8. But if measurements to the /8 show better collective performance over another link, why NOT move it? Yes, it could be carrying a lot of traffic, and could result in congesting the next link ... so it is necessary to be able to: - know when links are at/near capacity, and so avoid their use; and - react quickly in case of congestion Note that these problems are not specific to /8s, and that traffic loads are dynamic - even if it does look like there is room for a prefix on a link, once the route gets changed, conditions could very well change also. Any route optimization system needs to deal with these issues for ALL prefixes. There are multiple levels of optimization possible on top of this: a) If there is a general belief that /8s are simply too big to move, they can be manually deaggregated. Our experience shows that by breaking up a /8 into as few as (10) or (15) carefully designed chunks, the resultant load per (deaggregated) prefix becomes equivalent to hundreds of other prefixes. b) If manually configuring deaggregates is not desirable, automated approaches to deaggregation are possible: If I see traffic in this range, and a /xx does not exist for the observed traffic, then create the /xx. c) Dynamically measure all of the possible deaggregations of all active space, and dynamically determine which prefixes need to be deaggregated to what level. Note that in any of the above cases, the de-aggregated routes should be marked NO_EXPORT. I know of solid commercial implementations of (a) and (b). (c) is a more interesting project ... :) * The constant noise of stupid scripts pinging everything on the Internet. Pinging the Internet is clearly a wasteful approach. Essentially no one needs optimization to the ENTIRE Internet. Granted, major backbones probably actually use a great deal of the routing table ... (Quiz for the list readers: What percentage of the Internet routing table does your network actually use?) ... but for many ISP/hosting facility/major multihomed enterprise, our experience shows that only a very small fraction of traffic is seen beyond about (20,000-30,000) routes in a given day. There is no reason to measure destinations unless they are involved with traffic to your network. Basing measurements on observed traffic, or having applications instrumented to automatically generate their own measurement are both clean options here. Companies and ISPs today spend time(=money) managing their connectivity to the Internet. Loop-free connectivity is a basic first step; but in many cases real connectivity goals include: - Capacity management (especially in the presence of asymmetrical bandwidth) - Load management (in the case of usage-based billig) - Performance management (realizing 'best possible' performance) - Maximizing application
Are SW upgrades needed in MPLS core networks?
Hi, Just taking a quick poll, as we don't use MPLS and I think this is an interesting thing to know. One of the many (maybe misguided) arguments for MPLS is that you don't need to perform softwqare (or other similar) upgrades in the core network, and the intelligence is pushed to the to the edges of the MPLS cloud. I'd like to get a feel how correct this argument is in practice. So, if you have had to upgrade the core equipment, please tell. If you haven't (due to the MPLS design), that might be interesting as well. If you had to upgrade, please also indicate the reason for that (fixing bugs (minor upgrade)? providing new features, if so which features? etc.?) Please respond off-list if you feel so. Thanks. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Outbound Route Optimization
On Mon, Jan 26, 2004 at 10:58:49AM -0800, Sean Finn wrote: The issue that you describe does indeed offer some constraints to the application of route optimization technology. Within the scope of this issue, though, I think that you would agree that a network which is ALL transit would face no challenge here -- and more specifically, if there is a routing optimization decision among local transit links, that problem could be solved independantly of the existance of non-transit links. Just noting why it will never be anything other than a small customer transit-only solution. As long as you are guaranteed by design that your product will never be applicable to large networks or networks with any peering, you know that odds are VERY slim you'll ever have anyone with real network clue using the product. Under such conditions, snake oil sales flurish. Applying this technology in the presence of non- transit routes requires constraining measurments to only the prefixes appropriate for a given link. It is true that knowing all BGP routes (BGP Losers) would be a nice way to get this information ... but it's not necessarily the only approach towards the goal. Some solutions may have topological dependancies, but it can be feasible to simply drop all measurement towards illegal destinations. In other cases, it may be possible to define the set of destinations that are legal over a given link, and constrain measurements for that link. Good luck making this scale. :) * The requirement of deaggregation in order to make best path decisions effective. For example, someone's T3 to genuithree gets congested and the best path to their little /24 of the Internet is through another provider. Do you move 4.0.0.0/8? Perhaps. Yes, it's a /8. But if measurements to the /8 show better collective performance over another link, why NOT move it? Yes, it could be carrying a lot of traffic, and could result in congesting the next link ... so it is necessary to be able to: - know when links are at/near capacity, and so avoid their use; and - react quickly in case of congestion What is broken for one provider and fixed at another may very well break something else that was working before at the first provider, yes? Besides the difficulties of assigning a true metric to the overall reachability of a /8 or any aggregate for that matter (ok we decreased rtt by 20ms to these 3 destinations doing 15Mbps each but we increased rtt to this other destination doing 40Mbps by 60ms so we're better right?), do you really want to see the problems you are supposed to be solving with optimized routing popping up and going away again throughout the day? And yes you do bring up another valid point, how much of the congestion you're trying to avoid is caused by your own traffic? If the answer is none you're fine, but this by definition means the failure of your optimized routing product. If it is a success you will either a) have people with lots of traffic using it, or b) have so many small-traffic users that the collective decisions of your box become the huge user. The problems then become: * The quicker you try to react, the more you place yourself at risk of starting a best path flap cycle. * Congestion does not only happen on your uplink circuit, it can happen at every point along the path, including peers, backbone circuits, and even the end user/site links. While I find the sales pitches of people touting the horrors of peering to be quite sad (from Internap to the classic MAE Dulles :P), peering capacity is largely based on the ability to predict the traffic levels far in advance. It doesn't take that many large customers selecting certain destinations through one provider at once to blow up a peer in one region. Balancing the traffic of a GigE and a couple of FastE transits to keep each one uncongested may be enough functionality to sell some boxes to some low end users, but this falls into the categories I've described above, and does nothing to address the true end to end performance. Thus the only real solution to the problem if you actually want to optimize traffic is: c) Dynamically measure all of the possible deaggregations of all active space, and dynamically determine which prefixes need to be deaggregated to what level. Note that in any of the above cases, the de-aggregated routes should be marked NO_EXPORT. Throw away the BGP routing table completely, and build your own based on the topology and metrics you have detected. Of course, this means saying goodbye to the usual failsafe method of keeping the normal BGP routes in the table with a lower localpref so if the box falls over you just fail back to normal BGP path selection. And probably more importantly, there isn't enough scale in the traffic probing system to gather the necessary topology info once for every customer... Maybe if you made
Re: Outbound Route Optimization
On Mon, Jan 26, 2004 at 08:47:54AM -0700, Wayne E. Bouchard wrote: Although in principle I agree with what you say here, I will point out that the number and frequency of significant network outages (excluding things like the recent power failure in LAX) has become rare as compared to what they were 5 or 6 years ago. Part of this is due to attitudes about the 'net maturing, part due to increased experience of the average engineer, and part due to things such as MPLS fast reroute. I am going to have to call bullshit on the MPLS fast reroute thing there Wayne. The canonical counterexample is Sprint. Excellent engineering and ops folks top the list, followed closely by sufficient capacity, not pushing the envelope any more (basically we are now on the scale of growth where things like running out of pps don't happen any more), and the fact that now we are growing in an organic fashion, so the people at the bleeding edge are sufficiently clued up that the vendors products are together for the people following. Major protocol implementations have been beaten into shape, and now it is (mostly) a matter of bigger bandwidth and routers, not any fundamental architectural change. /vijay I would also point out that, although there remain single points of interconnect, MPLS has meant that the path packets take intra-network doesn't have to be a single route between two boxes. BGP picks the exit point and engineers have configured MPLS to spread the traffic over 3 or 4 tunnels to get there thereby reducing the impact of a single failure. But as you say, this really gets into the realm of overbuilt backbones which, of course, not everyone has. BGP isn't the best. I think many people have recognized that for some years now. However, when propperly managed, it suits current needs. Perhaps it's time for the next generation of BGP to come into being; something that can use up to 4 paths through a network for any single destination rather than simply leaving alternate paths innactive until something changes. Heavens knows there are many instances where there are two or more good (and even equal) paths through a network that are not chosen simply because we're only allowed one. On Mon, Jan 26, 2004 at 10:35:38AM +, [EMAIL PROTECTED] wrote: BGP is relatively good at determining the best path when you a major carrier with connectivity to everyone (i.e. when traffic flows naturally), in many locations, and you engineer your network so that you have sufficient capacity to support the traffic flows. In other words, BGP really only works well when most networks are overbuilt so that there is a single uncongested best path through each network from every ingress to every egress and the paths within any given network's core are roughly similar in capacity. Nowadays there is a lot more variability both within networks and between different networks. How can a simple protocol provide optimal behavior between an MPLS network, an IP over ATM network, a network that is half GRE tunnels, and a network that has core links ranging from DS3 to OC48? I think BGP is another example where something that is good enough has risen to prominence in spite of the fact that it is not optimal. And another thing. How do we know this problem can ever be solved when we continue to use routing protocols which choose the *BEST* path. The best path is always a single path and, by definition, this is a single point of failure. How can we ever have a diverse and reliable network when its core routing paradigm is a single point of failure? Note that people have built IP networks that provide two diverse paths at all times using multicast http://www.simc-inc.org/archive9899/Jun01-1999/bach2/Default.htm and such things may also be possible with MPLS. But are any of the researchers seriously looking at how to provide a network in which all packets flow through two diverse paths to provide better reliability? --Michael Dillon --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
Both the ISL _and_ the Dotq headers are stripped off at the trunk interface so they _both_ change the packet size but neither alters the payload. Scott C. McGrath On Mon, 26 Jan 2004 [EMAIL PROTECTED] wrote: ISL _DOES NOT CHANGE_ packet size. An 802.1q tag adds 4 bytes to the Ethernet frame. ISL encapsulation adds 30 bytes to the Ethernet frame. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
Both the ISL _and_ the Dotq headers are stripped off at the trunk interface so they _both_ change the packet size but neither alters the payload. Obviously. But the fact that ISL adds 26 bytes more than 802.1q means that multiple levels of ISL encapsulation is somewhat less practical than multiple levels of 802.1q tags. Some of us *need* those multiple levels of 802.1q tags. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Outbound Route Optimization.
This was one of the pipe dreams that RSVP was _supposed_ to solve in that you could set up a end to end path with precisely specified characteristics. problem is _all_ the devices in the path need to support RSVP. Now the snake oil salesmen are coming out with boxes which purport to monitor the all paths on the internet and will indvidually select the best path for your flow.The racket will be deafening when all these boxes start running scripted ICMP sweeps to find the best path. The solution is simple buy adequate pipes and possibly partner with a content delivery network who peers with _all_ the major carriers so that your traffic will not need to transit the major public peering points. Scott C. McGrath
Cisco 7600
I'm aware the Cisco 7600 series is really just an evolution/different way of orienting the chassis of the Catalyst 6500 line. I'm interested in talking to those of you who are doing production tasks in the backbone or core with the 7600, particularly if you've compared it to vendor J or can comment at length on MPLS, VRF, and uRPF features in the device. Please reply off-list. No sales droids please, this is a technical discussion. Tim
Re[2]: Outbound Route Optimization.
Scott, Not all boxes are created equal. I agree that certain manufactures of route optimization equipment really should be in the used car sales arena. However that is not the case with the unit we purchased. The RouteScience PathControl box we purchased only sends UDP traceroutes to the top 15000 networks that my customers are attempting to get to. This information about the flow of traffic to these networks is based on netflow information from my backbone routers. There are no ping sweeps to locate anything. Using PBR, the box sends a UDP traceroute out each backbone to my top 15000 destinations, calculates which one has the best latency and routes traffic out that backbone. Once I had fully implemented the unit, my latency dropped by 40% to over 100 keynote locations around the world. For me, the proof was in the performance increases. On Mon, 26 Jan 2004 16:15:48 -0500 (EST) Scott McGrath [EMAIL PROTECTED] wrote: This was one of the pipe dreams that RSVP was _supposed_ to solve in that you could set up a end to end path with precisely specified characteristics. problem is _all_ the devices in the path need to support RSVP. Now the snake oil salesmen are coming out with boxes which purport to monitor the all paths on the internet and will indvidually select the best path for your flow.The racket will be deafening when all these boxes start running scripted ICMP sweeps to find the best path. The solution is simple buy adequate pipes and possibly partner with a content delivery network who peers with _all_ the major carriers so that your traffic will not need to transit the major public peering points. Scott C. McGrath ** Richard J. Sears Vice President American Digital Network [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax I fly because it releases my mind from the tyranny of petty things . . Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching.
RE: Cisco 7600
Tim, I can't speak to the 7600 series from experience (I'm using the 6509 with MSFC2); however, my opinion is that Cisco continues to market their routers as suitable for core routing whereas the routers are 'just acceptable' as an edge aggregation device. Several weeks ago there was a lively debate on Nanog regarding cisco performance, if I recall correctly, one party indicated that they upgraded from a 7206 NPE400 to a GSR and only saw a 30% improvement in CPU utilization. That's a lot of bling bling for 30%... I need only a few high capacity interfaces but a lot more acl, mpls, qos crunching horsepower than what I can get from Cisco right now. I'm curious whether vitamin J is a better option for the core at a specific price point. It would be great to have a comparison chart that showed a correlation between a Cisco Mach GT and Juniper Diablo at each key price point, $25,000, $50,000, $75,000 and so on. YMMV, Christopher J. Wolff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Brown Sent: Monday, January 26, 2004 3:06 PM To: [EMAIL PROTECTED] Subject: Cisco 7600 I'm aware the Cisco 7600 series is really just an evolution/different way of orienting the chassis of the Catalyst 6500 line. I'm interested in talking to those of you who are doing production tasks in the backbone or core with the 7600, particularly if you've compared it to vendor J or can comment at length on MPLS, VRF, and uRPF features in the device. Please reply off-list. No sales droids please, this is a technical discussion. Tim
Re: Re[2]: Outbound Route Optimization.
Richard J. Sears [EMAIL PROTECTED] writes: Once I had fully implemented the unit, my latency dropped by 40% to over 100 keynote locations around the world. In some circles, playing games with Keynote is considered excellent sport. ---Rob
in case nobody else noticed it, there was a mail worm released today
my copies (500 or so, before i filtered) are in a ~7MB gzip'd mailbox file called http://sa.vix.com/~vixie/mailworm.mbox.gz (plz don't fetch that unless you need it for comparison or analysis). there's a high degree of splay in the smtp/tcp peer address, and the sender is prepared to try backup MX's if the primary rejects it, though it appears to try the MX's in priority order.
Re: in case nobody else noticed it, there was a mail worm released today
Paul Vixie [1/27/2004 7:22 AM] : my copies (500 or so, before i filtered) are in a ~7MB gzip'd mailbox file called http://sa.vix.com/~vixie/mailworm.mbox.gz (plz don't fetch that unless you need it for comparison or analysis). there's a high degree of splay in the smtp/tcp peer address, and the sender is prepared to try backup MX's if the primary rejects it, though it appears to try the MX's in priority order. MyDoom / Novarg etc http://news.com.com/2100-7349_3-5147605.html?tag=nefd_top -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: in case nobody else noticed it, there was a mail worm released today
We are seeing 2 wide spread worms right now, mydoom and dumaru.* NAI has info at http://vil.nai.com/vil/content/v_100983.htm and http://vil.nai.com/vil/content/v_100980.htm They rate of it is quite surprising. By the description, the trick / method of infection does not seem all that different than past worms viri. Makes me wonder how many people in a room would reach into their purse/pocket on hearing, Wallet inspector ---Mike At 08:52 PM 26/01/2004, Paul Vixie wrote: my copies (500 or so, before i filtered) are in a ~7MB gzip'd mailbox file called http://sa.vix.com/~vixie/mailworm.mbox.gz (plz don't fetch that unless you need it for comparison or analysis). there's a high degree of splay in the smtp/tcp peer address, and the sender is prepared to try backup MX's if the primary rejects it, though it appears to try the MX's in priority order.
Re: Outbound Route Optimization
Richard A Steenbergen wrote: The issue that you describe does indeed offer some constraints to the application of route optimization technology. Within the scope of this issue, though, I think that you would agree that a network which is ALL transit would face no challenge here -- and more specifically, if there is a routing optimization decision among local transit links, that problem could be solved independantly of the existance of non-transit links. Just noting why it will never be anything other than a small customer transit-only solution. As long as you are guaranteed by design that your product will never be applicable to large networks or networks with any peering, you know that odds are VERY slim you'll ever have anyone with real network clue using the product. Under such conditions, snake oil sales flurish. It appears to me that you've acknowledged that route optimization solves a problem, albeit one that is not a complete solution for your network. The claims of 'snake oil' seems inappropriate in this context. One step further: if you are running a network of this type, then there seems to be a large likelihood that you are selling transit. Thus, your customers may well be using technology of this sort to provide real solutions to THEIR problems. (specifically, they may be directing traffic towards providers that are to _their_ advantage; and be gaining detailed insight as to the real quality of connectivity being provided to them.) It's not clear to me how you chose to define real network clue, but I would not suggest that your customers are completely lacking in that area. :) In other cases, it may be possible to define the set of destinations that are legal over a given link, and constrain measurements for that link. Good luck making this scale. :) Granted - it is a limited solution -- but still a solution that does solve a set of real-world problems. What is broken for one provider and fixed at another may very well break something else that was working before at the first provider, yes? Besides the difficulties of assigning a true metric to the overall reachability of a /8 or any aggregate for that matter (ok we decreased rtt by 20ms to these 3 destinations doing 15Mbps each but we increased rtt to this other destination doing 40Mbps by 60ms so we're better right?), Having measurement traffic that directly correlates to actual traffic makes this problem much more managable. The problems then become: * The quicker you try to react, the more you place yourself at risk of starting a best path flap cycle. * Congestion does not only happen on your uplink circuit, it can happen at every point along the path, including peers, backbone circuits, and even the end user/site links. While I find the sales pitches of people touting the horrors of peering to be quite sad (from Internap to the classic MAE Dulles :P), peering capacity is largely based on the ability to predict the traffic levels far in advance. It doesn't take that many large customers selecting certain destinations through one provider at once to blow up a peer in one region. Flap control is an important consideration. Note that in the described topology, changing the selection of an egress point does not affect the routing tables of external networks (as opposed to flapping of route advertisements, for inbound traffic.) I do think that it's useful to compare the behaviour of mortal BGP in the conditions you describe ... if BGP selects a path that is, or becomes, congested ... BGP has no feedback mechanism to make a change until the overall topology changes, or until manual intervention. An automated route optimization system can evaluate the performance, and current load, of alternate egresses, make an automated change to the egress, and then monitor the success of the change. In most cases, the overall conditions will have been improved. In the case you describe above, the route change results in suboptimal performance, and a new decision is needed. This process needs to have effective flap control. This is an area in which I've seen a fair amount of development; and have seen good results in years of production use. Balancing the traffic of a GigE and a couple of FastE transits to keep each one uncongested may be enough functionality to sell some boxes to some low end users, but this falls into the categories I've described above, and does nothing to address the true end to end performance. It's not clear to me what you mean here by true end to end performance. I don't pretend that the approach being discussed is a COMPREHENSIVE solution to all the problems that can impair performance; but I do think that for the class of performance problems that are directly observable via inspection of alternate egresses, redirecting the egress does in fact address true end to end performance. Thus the only
RE: in case nobody else noticed it, there was a mail worm released today
The worm is being talked about on news.com and all the major virus vendors already have advisories on their websites. The worm in my case masqueraded as a Mailer Daemon bounce. Source email address appeared to be valid and matching a domain of a website I visited recently (but have not for a long time). Anyone know the worm generates the sending domain. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: Monday, January 26, 2004 8:52 PM To: [EMAIL PROTECTED] Subject: in case nobody else noticed it, there was a mail worm released today my copies (500 or so, before i filtered) are in a ~7MB gzip'd mailbox file called http://sa.vix.com/~vixie/mailworm.mbox.gz (plz don't fetch that unless you need it for comparison or analysis). there's a high degree of splay in the smtp/tcp peer address, and the sender is prepared to try backup MX's if the primary rejects it, though it appears to try the MX's in priority order.
Re: in case nobody else ...
They rate of it is quite surprising. By the description, the trick / method of infection does not seem all that different than past worms viri. Makes me wonder how many people in a room would reach into their purse/pocket on hearing, Wallet inspector Try and comprehend the typical home user, with no experience reading what appears to be an email from a friend or a relative. It happens. I had a friend who sent me a virus (unknowingly of course), that went to three different accounts that fall into the same mutt directory. When I inspected it, I gave the friend a call and notified them of the virus, and according to them, they only thing they received was a weird message from someone they knew. This was a fairly smart person, albeit comp illiterate. Someone working in the field (comp/networking) is almost always going to point out a flaw with someone not knowing, but the majority of those who get infected don't even know they're infected. Who do you blame them? I blame those whose OS coding is (excuse the term) crappy (security wise) in the sense it would allow 1) viruses to replicate as such, secondly I do put some blame on the provider for not filtering outbound data (silly pseudo spoofing). Just my two cents which obviously have declined with the economy =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Quis custodiet ipsos custodes? - Juvenal J. Oquendo GPG Key ID 0x51F9D78D Fingerprint 2A48 BA18 1851 4C99 CA22 0619 DB63 F2F7 51F9 D78D http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x51F9D78D sil @ politrix . orghttp://www.politrix.org sil @ infiltrated . net http://www.infiltrated.net
