|
Girdle Wax posted:If you've already turned on the debugs, you should be able to use the command 'term mon' to have it drop debug prints to your vty Thanks! Worked like a charm. Now if it would just, you know, work! .Jan 23 18:56:04.406: NTP: xmit packet to 132.163.4.107: .Jan 23 18:56:04.406: leap 3, mode 3, version 3, stratum 0, ppoll 64 .Jan 23 18:56:04.406: rtdel 0560 (20.996), rtdsp 0504 (19.592), refid 407D4E55 (64.125.78.85) .Jan 23 18:56:04.406: ref CB3A1F9B.DA3B1B30 (18:40:27.852 UTC Thu Jan 17 2008) .Jan 23 18:56:04.406: org CB420C04.765D4A9D (18:55:00.462 UTC Wed Jan 23 2008) .Jan 23 18:56:04.406: rec CB420C04.7E334F6C (18:55:00.492 UTC Wed Jan 23 2008) .Jan 23 18:56:04.406: xmt CB420C44.683C0AEF (18:56:04.407 UTC Wed Jan 23 2008) .Jan 23 18:56:04.406: Authentication key 33831 .Jan 23 18:56:04.474: NTP: rcv packet from 132.163.4.107 to 192.168.1.64 on Vlan1: .Jan 23 18:56:04.474: leap 0, mode 4, version 3, stratum 1, ppoll 64 .Jan 23 18:56:04.474: rtdel 0000 (0.000), rtdsp 0000 (0.000), refid 41435453 (65.67.84.83) .Jan 23 18:56:04.474: ref CB420C0C.180D3389 (18:55:08.093 UTC Wed Jan 23 2008) .Jan 23 18:56:04.474: org CB420C44.683C0AEF (18:56:04.407 UTC Wed Jan 23 2008) .Jan 23 18:56:04.474: rec CB420C44.769CC67D (18:56:04.463 UTC Wed Jan 23 2008) .Jan 23 18:56:04.474: xmt CB420C44.769DCCF7 (18:56:04.463 UTC Wed Jan 23 2008) .Jan 23 18:56:04.474: inp CB420C44.7A51C067 (18:56:04.477 UTC Wed Jan 23 2008) .Jan 23 18:56:04.474: Authentication key 0 aon#show ntp rear end detail 132.163.4.107 configured, insane, invalid, unsynced, stratum 16 ref ID 0.0.0.0, time 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900) our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000 delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00 precision 2**5, version 3 org time CB420C44.769DCCF7 (18:56:04.463 UTC Wed Jan 23 2008) rcv time CB420C44.7A51C067 (18:56:04.477 UTC Wed Jan 23 2008) xmt time CB420C44.683C0AEF (18:56:04.407 UTC Wed Jan 23 2008) filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 I've sent an email off to the administrator of the server to ask for assistance. Hopefully life will be good shortly.
|
#
?
Jan 23, 2008 22:36
|
|
|
|
| # ? May 15, 2024 05:43 |
|
|
How are Cisco's layer 3 switches when used as routers, really? We need to upgrade our ancient SSR routers with something that has lots of ports, at least a few of them gigabit, and full resilience. A pair of 24-port 3560G with the "advanced" image would cost way less than "real" routers with all the interface cards we would need. From what I can gather, the advanced image for L3 switches give me about the same features as ipbase, which is well enough. It needs to handle OSPF, and a routing table of maybe 100 entries. It's not like I need wirespeed routing on all ports simultaneously, but at least some decent kind of throughput (a few gigabits total, almost all of it between a few directly attached networks). 32Gbps / 38.7Mpps is plenty (though one is "large packets", the other "small packets"), but will it deliver something like that at layer 3? Will a 3560G do the job, or do we need to spend loads more money for something with way less ports (3845 or 2651 + modules)? I've talked to a couple of Cisco partner-reseller dudes, and they basically just say "hell yes, L3 switches rock, but you should really buy the 3750 or 3750-E they're cooler", but since they're salesmen, I have no reason to trust them. Other people say "you need a real router, L3 switches are no good", but without much technical facts to support that view. Also, what is _really_ the difference between 3560G and 3750G (specifically WS-C3560G-24TS-E and WS-C3750G-24TS-E)? I really don't need the stackwise thing (to me, that seems mainly useful for switching, not routing) or 10G.
|
|
#
?
Jan 24, 2008 00:08
|
|
|
3560G / 3750G is a good candidate. 3750 gives you the external backplane connectors, that's it. Oh, and maybe a slightly different port configuration or two. And shiny metal aluminum front, instead of greenish plastic. Either switch would work just fine for you. I don't understand people who say "L3 switches are no good," since that doesn't make sense to me. These days, layer-3 switching is simply routing in hardware for all practical purposes. There are caveats, such as TCAM size, or features that aren't supported in hardware causing packets to punt to the processor, but you haven't described the need for anything that should be a show-stopper.
|
|
#
?
Jan 24, 2008 00:38
|
|
|
jwh posted:There are caveats, such as TCAM size, or features that aren't supported in hardware causing packets to punt to the processor, but you haven't described the need for anything that should be a show-stopper. Just make sure you keep your broadcast/L2 domains small and you should be fine. We use 4948's here, and they are pretty darn nice. They're similar in price to the 3750's, but pack a bigger punch, near as I can tell. If you don't need the backplane connectors, I wouldn't use them. If you're too worried about sales people, call up M@. He always seems to have the hookups. We have very few actual routers. Catalyst 6500 series "switches" are pretty mean routers once you put a Sup720 in them.
|
|
#
?
Jan 24, 2008 01:12
|
|
|
one big catch on the 3560G/3750 platforms is that you're only supposed to set up 8 (or is it 12?) SVIs or routed ports, while they will run with more than the recommended number, it's not supported by TAC.
|
|
#
?
Jan 24, 2008 01:14
|
|
|
Well, with the amount of routes we have, TCAM size shouldn't be a problem for anything that calls itself a router. If I've understood anything about things like CEF, this is what it should be pretty good at. Anything else (various GRE tunnels and access lists, all of it quite low-bandwidth stuff) is and will mostly be done by separate hardware (2801 is the current weapon of choice). It will do pretty straightforward "nothing-but-routing". We run QoS for voice traffic, but everything is tagged and ready from the source. I could understand people who don't like the "simple" L3 switches. Those that just can do static routing and RIP wouldn't be a replacement for most "proper" routers, but these advanced-image L3 ones should do the job just fine, and if you need more than 3 gig ports and a few FE ones, it's hard to beat the price. Now I'll have 28, which is shitloads. The port configuration that makes sense for us is the -24TS-E (24 gig copper + 4 SFP). The backplane connectors would be nice to have, but I don't really see the need for them (at least not at a 50% premium). I've seen a faulty ethernet blade in a 6509 (Sup32) bring the entire switch down (despite Cisco saying it never really happened), and if something like that could happen with a stack of 3750's, I'd rather not have it and just set them up as a pair of hsrp routers / spanning-tree switches. The metal front is  , but Cisco green always looks good.
|
|
#
?
Jan 24, 2008 01:17
|
|
|
ionn posted:I've seen a faulty ethernet blade in a 6509 (Sup32) bring the entire switch down (despite Cisco saying it never really happened) I've seen pulling out a Sup720 blade while in SSO mode bring the whole thing down.  Had to powercycle the chassis to get the thing to recover.
|
|
#
?
Jan 24, 2008 01:21
|
|
|
Girdle Wax posted:one big catch on the 3560G/3750 platforms is that you're only supposed to set up 8 (or is it 12?) SVIs or routed ports, while they will run with more than the recommended number, it's not supported by TAC. Really? That sounds bad. Does Cisco make a fixed-configuration layer 3 switch that will route all interfaces? 4948?
|
|
#
?
Jan 24, 2008 01:52
|
|
|
jwh posted:Really? That sounds bad. Yeah, the 4948 (internally based off a 4500 I believe) will do (supported) layer 3 on every single port, up to 2048 SVIs or something crazy. But it'll cost you. From the docs, the 3550/3560/3750 there's no "hard" limit, but sdm tells you not to go over 8 SVIs.
|
|
#
?
Jan 24, 2008 02:38
|
|
|
8 SVIs should fulfill our needs pretty well. We currently have 10 or so router IP interfaces, but I can reduce that to 7 by merging a couple of transit lans, and some nets are just management networks that I could stick behind a 1811 (they really don't need much performance, just a bit of isolation). I can get it down to actually requiring 5 SVI's, which would still give me some room. If the limit somehow really is "8 SVI's at full speed and everything else with reduced performance", it would be no problem at all. Can anyone find any hard facts about this recommendation? The 4948 would blow my budget into tiny little pieces I'm afraid, and so would anything involving the 3845. A 2821/2851 with a few modules (HWIC-1GE-SFP and NM-16ESW-1G) plus a layer 2 switch might do the job at a decent cost, but would limit total routing capacity a lot (as it would involve trunking things on a pair of etherchannel gig ports) and leave no or very little room for expansion. 3560G would probably still be the best value for money and performance for what I need, from the looks of it.
|
|
#
?
Jan 24, 2008 10:05
|
|
|
^^^^^ Make sure you get the 3560G that supports jumbo frames, if you are expecting to need them. There are 4 versions of the 3560G IIRC the 24 and 48 port, that support and don't support Jumbo frames. I've got a 3560G around here that is a 48port version with Jumbo Frames, but I'm not sure exactly what the part number is. Check CCO though and it should tell you. (After you coax it some.) Girdle Wax posted:Yeah, the 4948 (internally based off a 4500 I believe) will do (supported) layer 3 on every single port, up to 2048 SVIs or something crazy. But it'll cost you. Yep. That's exactly what a 4948 is. It even has the same Rommon as the old 4507R does. When I discovered that I actually laughed a little. Hell I'd trust a 4948 to be more reliable then the old Cat4500s anyway. ate shit on live tv fucked around with this message at 10:40 on Jan 24, 2008 |
|
#
?
Jan 24, 2008 10:35
|
|
|
ionn posted:If the limit somehow really is "8 SVI's at full speed and everything else with reduced performance", it would be no problem at all. Can anyone find any hard facts about this recommendation? The 8 SVIs is really a recommendation on Cisco's part. The true limit is the TCAM size, so long as you can stay within the TCAM limits it will do full wire speed on as many SVIs as you want. But once you run out of TCAM space you'll be hurting due to traffic getting punted.
|
|
#
?
Jan 24, 2008 13:50
|
|
|
Girdle Wax posted:Yeah, the 4948 (internally based off a 4500 I believe) will do (supported) layer 3 on every single port, up to 2048 SVIs or something crazy. But it'll cost you. Price out a 4948 and you might be surprised. They are "only" marginally more expensive than the 3560G. If you don't need it, you don't need it, but it could be $2,000 well spent. Stupid TCAM size.  WS-4948 posted:*Jan 24 02:24:36 UTC: %C4K_L3HWFORWARDING-4-FWDCAMOUTOFSPACEFORVRFROUTINGTABLE: Insufficient TCAM resources to load VRF IPv4:green routing table. Switching to software forwarding for this VRF.
|
|
#
?
Jan 24, 2008 17:06
|
|
|
For anyone who hasn't seen this yet, there's a new expert level certification in the design track : the CCDE. http://www.cisco.com/web/learning/le3/ccde/index.html http://www.cisco.com/web/learning/le3/ccde/ccde_exam_information.html No info on the lab yet, just a written blueprint.
|
|
#
?
Jan 24, 2008 18:17
|
|
|
Girdle Wax posted:The true limit is the TCAM size, so long as you can stay within the TCAM limits it will do full wire speed on as many SVIs as you want. What _is_ the TCAM size, really?
|
|
#
?
Jan 24, 2008 21:07
|
|
|
ionn posted:What _is_ the TCAM size, really? TCAM is specialized memory that is used for storing the forwarding database. It's very fast, and enables line-rate forwarding on switch platforms. As for the size of the TCAM, it depends on the hardware- 3560G and 3750G switches have a 'sdm prefer' knob that can tune how the TCAM is set up. It's not clear to me how big the 3560G or 3750 TCAM really is, but you might want to look at: http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_see/configuration/guide/swsdm.html#wp1098766 In the case of bigger switches, such as the 6500 or 7600, it depends on the policy feature-card (PFC) on the multi-layer switch feature-card (MSFC). There was a lot of talk recently about the size of full Internet routes, which was approaching 239,000 IPv4 routes, which happened to be just about the maximum you could cram into the PFC2/3 TCAM (is this right?). Once you try and push more routes into the TCAM than will fit, the platform will software switch some prefixes on the route processor, and performance suffers terribly. There are newer 'xl' PFCs that support up to 512k prefixes, tunable to 1024k. I don't know much about them. The reason this is a non-issue on software based routers is because on software platforms, you're limited by DRAM size, not TCAM size. It's a lot more affordable to buy a router with a gig of memory than to buy a switch with equivalent TCAM. Not to mention that with distributed forwarding platforms, you need to put TCAM on every individual linecard.
|
|
#
?
Jan 24, 2008 21:36
|
|
|
Yeah, I know what the TCAM does, I just hadn't found anything describing the size of it for the 3560. From that table, however, looks like we will be well in the clear. A thousand MAC addresses, a hundred or so unicast routes, 10 VLANs, and that's about it. In which case, the number of SVI's won't be a problem, I guess. I'll see what I would have to pay for a 4948. I've always disregarded them as too expensive, but I just realized there was a version without 10G as well... Edit: Seems they're about twice the cost of a 3560G-24TS-E (the 4948 also with the enhanced/advanced/expensive image). If there only was a cheaper 24-port version, it would probably fit well. 2x48 ports is way more than I can justify (and it's probably well outside what I can spend), unless there is something really good about it that we need. I could buy just one, but the major point of the upgrade is to get full resiliency. ionn fucked around with this message at 22:24 on Jan 24, 2008 |
|
#
?
Jan 24, 2008 22:18
|
|
|
ionn posted:Yeah, I know what the TCAM does, I just hadn't found anything describing the size of it for the 3560.
|
|
#
?
Jan 24, 2008 22:21
|
|
|
jwh posted:Oh, sorry. Hopefully I didn't come off as patronizing; I wasn't sure if you were asking what the TCAM size was, as in what it did, or only what the size was. Don't worry about it, I am a noob at this after all. At my last job I just got handed the (horribly overspec'ed) equipment and told what to do with it, and now I get to (and have to) do the whole design myself.
|
|
#
?
Jan 24, 2008 22:27
|
|
|
jwh posted:There are newer 'xl' PFCs that support up to 512k prefixes, tunable to 1024k. I don't know much about them. They're exactly the same as the non-XL PFCs (and DFCs), the only difference is prefix count. Pretty much everyone running full internet tables should be on XLs now, unless they're planning on filtering prefixes... code:
|
|
#
?
Jan 24, 2008 22:46
|
|
|
Girdle Wax posted:
So why do you have less entries using more ram? code:
|
|
#
?
Jan 25, 2008 02:22
|
|
|
H110Hawk posted:So why do you have less entries using more ram? 3BXLs have the same prefix table size as the 3CXL, all the 3CXL has (which requires the RSP720 anyway) is a bigger Ethernet TCAM- since it's aimed at the carrier ethernet aggregation market. YOu're fine with the 3BXLs. Also, I think our mem usage is a bit higher because someone probably turned on soft reconfig, how many (full table) sessions do you have on that box? -edit- code:ragzilla fucked around with this message at 02:56 on Jan 25, 2008 |
|
#
?
Jan 25, 2008 02:51
|
|
|
Girdle Wax posted:3BXLs have the same prefix table size as the 3CXL, all the 3CXL has (which requires the RSP720 anyway) is a bigger Ethernet TCAM- since it's aimed at the carrier ethernet aggregation market. I thought we had soft reconfig enabled. Perhaps not? code:
|
|
#
?
Jan 25, 2008 03:19
|
|
|
One of our PE routers is a Cisco 7206VXR (NPE300) running 12.2(25)S10, and we have a couple of customers whose VPN solution requires multiple VRFs per site. An example CE is a Cisco 1841 running 12.4(1c), and their connection is a G.SHDSL via the router's ATM interface, via a third party ATM pipe, to our PE. Now, because it's ATM, we can't just run a VLAN for each VRF, so we tunnel the VRFs. Anticipating a swap to an Ethernet DSLAM, we prepared the CE for RFC2684 by adding the atm route-bridge ip statement under the CE's ATM point-to-point subinterface, and same on the PE's subinterface pending the swap to Ethernet. Suddenly, the tunnel interface on the PE goes up/down and doesn't come up until we reload the PE no matter how much we wank it. Even then the tunnel interface only stays up for a few hours at a time, and this is a really loving annoying situation. The corresponding tunnel interface on the PE is up/up the whole time, and the loopback interface on the PE and the CE acting as tunnel sources and destinations are up/up. The loopbacks are routed in the main VRF (customer-office). The really weird thing is that you can't ping them from each other although the routes are visible and the point-to-point connection between the PE and CE ATM subinterfaces pings just fine. All other networks routed in the customer-office VRF ping too, just not the loopback /32 prefixes. The kludge is implemented like so (using a DMZ VRF as an example): -- PE -- code:code:
|
|
#
?
Jan 25, 2008 18:38
|
|
|
Yikes, I don't have any ideas- but wouldn't it be easier to provision two PVCs to the same CE instead of working through the GRE vrf forwarding and tunnel vrf stuff? That seems really, really complicated.
|
|
#
?
Jan 25, 2008 20:23
|
|
|
Anyone take the 640-802 CCNA yet? Thoughts, opinions, complaints?
|
|
#
?
Jan 25, 2008 22:21
|
|
|
Is it possible to rate limit traffic by IP on a Catalyst 3750?
|
|
#
?
Jan 26, 2008 01:58
|
|
|
brent78 posted:Is it possible to rate limit traffic by IP on a Catalyst 3750? I too would be interested in this, or something similar. We currently are using two 7120s and were attacked 3 times in the past week with tens of thousands of UDP packets per second to our internal NAT server from three different probably spoofed IP addresses. We're looking for something that could hopefully limit the pps per IP address; or, if someone has any other ideas about preventing/stopping a DoS attack I'd really like to hear it.
|
|
#
?
Jan 28, 2008 14:35
|
|
|
Recluse posted:I too would be interested in this, or something similar. We currently are using two 7120s and were attacked 3 times in the past week with tens of thousands of UDP packets per second to our internal NAT server from three different probably spoofed IP addresses. We're looking for something that could hopefully limit the pps per IP address; or, if someone has any other ideas about preventing/stopping a DoS attack I'd really like to hear it. Preventing/Stopping a DoS attack on the customer side of a circuit is going to be difficult as chances are your pipe out to the world is the smallest link, so the attacker can just saturate that and it doesn't matter what kind of rate limiting or filtering you have on your side of the connection. The best solution to this (if you're talking BGP w/ your provider) is to use BGP remote triggered blackholing, where you can send a /32 prefix up to your provider over your BGP session with them, with a community tag that tells your provider to null route / blackhole the traffic before sending it to you. You can only do this for your own IPs though, so you lose whatever apps are running on the IP you blackhole, but it saves you the bandwidth to your provider so everything else keeps running.
|
|
#
?
Jan 28, 2008 16:37
|
|
|
What in the world: http://www.cisco.com/en/US/products/ps9402/index.html The world made sense an hour ago.
|
|
#
?
Jan 28, 2008 17:29
|
|
|
Girdle Wax posted:Preventing/Stopping a DoS attack on the customer side of a circuit is going to be difficult as chances are your pipe out to the world is the smallest link, so the attacker can just saturate that and it doesn't matter what kind of rate limiting or filtering you have on your side of the connection. The best solution to this (if you're talking BGP w/ your provider) is to use BGP remote triggered blackholing, where you can send a /32 prefix up to your provider over your BGP session with them, with a community tag that tells your provider to null route / blackhole the traffic before sending it to you. You can only do this for your own IPs though, so you lose whatever apps are running on the IP you blackhole, but it saves you the bandwidth to your provider so everything else keeps running. This is excellent and exactly what I'm looking for. Thank you!
|
|
#
?
Jan 28, 2008 19:18
|
|
|
jwh posted:What in the world: http://www.cisco.com/en/US/products/ps9402/index.html I'd be willing to bet that sells for a pretty penny.
|
|
#
?
Jan 28, 2008 19:21
|
|
|
InferiorWang posted:I'd be willing to bet that sells for a pretty penny. There's an article at Network World that says the 7000 starts at around $75,000, although it's not clear what you get for that (supervisors, fabric cards, etc.) The article also says the switch is _not_ positioned as a successor to the 6500, so I'm kind of scratching my head as to who is really looking at this platform. Apparently it will switch fibre-channel, ethernet, and IP all on the same fabric, but I'm not sure what kind of draw that will have for people that have already invested in separate data and storage switches. I'm also willing to bet that NX-OS will never see feature-parity to IOS.
|
|
#
?
Jan 28, 2008 19:44
|
|
|
jwh posted:Apparently it will switch fibre-channel, ethernet, and IP all on the same fabric, but I'm not sure what kind of draw that will have for people that have already invested in separate data and storage switches. Consolidation seems to be a hot topic these days. Maybe Cisco is looking to provide an option to consolidate all of those needs into one supported package instead of customers having to deal with multiple vendors blaming each other during service calls. quote:I'm also willing to bet that NX-OS will never see feature-parity to IOS. Why do you think that? I'm not saying you're wrong, I'm just curious. Granted I don't know anything beyond a wikipedia article about NX-OS, but I just figured it was the "next step".
|
|
#
?
Jan 28, 2008 19:52
|
|
|
NY Times article about Nexus herejwh posted:There's an article at Network World that says the 7000 starts at around $75,000, although it's not clear what you get for that (supervisors, fabric cards, etc.) In my experience, whenever Cisco quotes a price like that it's for an entire base config. jwh posted:The article also says the switch is _not_ positioned as a successor to the 6500 That's weird because the NYT article says "Its Nexus system, which will eventually replace a product line that represents about a third of its $35 billion business." What's it replacing then??
|
|
#
?
Jan 28, 2008 20:17
|
|
|
InferiorWang posted:Why do you think that? I'm not saying you're wrong, I'm just curious. Granted I don't know anything beyond a wikipedia article about NX-OS, but I just figured it was the "next step". Oh, it might be, in the long term. I'm just looking at these NX-OS data sheets, and from what I can tell, the 6500 looks like it will continue to be the more feature-rich platform for a long time to come.
|
|
#
?
Jan 28, 2008 20:44
|
|
|
jwh posted:What in the world: http://www.cisco.com/en/US/products/ps9402/index.html If those are what I believe them to be, there are two of them in our datacenter already. DirecTV has a pair of them. They came in HUGE crates. They're pretty awesome looking, and they seem to be consolidating a lot of bandwidth onto them. Near as I can tell they're turning 5 racks of metro fiber gear into a pair of those.
|
|
#
?
Jan 28, 2008 22:46
|
|
|
jwh posted:I'm also willing to bet that NX-OS will never see feature-parity to IOS. The way they're talking about NX-OS, it sounds a LOT like what they're claiming/pushing with regards to IOS-XR... quote:Virtual Device Contexts (VDCs) to maximize software and hardware resource utilization while providing strong security and software fault isolation quote:Comprehensive XML API for total platform control I'm guessing the next version will be the multi-chassis nexus system like the CRS-1 multi-chassis, where you throw some fabric shelves in your switching room, then drop NEXUS line card shelves out near your servers, and run a bunch of fiber between the LC shelf and your central point, giving you FC/Ethernet/whatever you want all in 1 giant fabric. H110Hawk posted:If those are what I believe them to be, there are two of them in our datacenter already. DirecTV has a pair of them. They came in HUGE crates. They're pretty awesome looking, and they seem to be consolidating a lot of bandwidth onto them. Near as I can tell they're turning 5 racks of metro fiber gear into a pair of those. If DirecTV already has some, they're probably not Nexus since I don't think it's shipping yet, the other Cisco full rack routers would be the CRS-1 single chassis, and I think there's also a GSR (XR) that takes up a full bay. ragzilla fucked around with this message at 02:04 on Jan 29, 2008 |
|
#
?
Jan 29, 2008 02:02
|
|
|
Girdle Wax posted:If DirecTV already has some, they're probably not Nexus since I don't think it's shipping yet, the other Cisco full rack routers would be the CRS-1 single chassis, and I think there's also a GSR (XR) that takes up a full bay. That's what they are, then. They're pretty hot poo poo looking, though!
|
|
#
?
Jan 29, 2008 02:44
|
|
|
|
| # ? May 15, 2024 05:43 |
|
|
jwh posted:Yikes, I don't have any ideas- but wouldn't it be easier to provision two PVCs to the same CE instead of working through the GRE vrf forwarding and tunnel vrf stuff? That seems really, really complicated. The local operator doesn't support that for *DSL connections. Otherwise we would, yeah.
|
|
#
?
Jan 29, 2008 05:58
|
|