On 9 November 2013 20:26, CiscoNSP List wrote:
>
> I dont have access to pricing atm, but are the 3600X's a "lot" more
> expensive than 4948's?
>
For comparison, 4948E-E (which has 48 copper ports, four 10G SFP+ ports and
"Enterprise" software for full IP routing features) lists at US$ 20k.
Ad
On Saturday, November 09, 2013 10:26:15 PM CiscoNSP List
wrote:
> Very interesting - Im liking this as a solution! Ive had
> a look at the ME3600X (Are you using the ME-3600X-24TS?
> i.e. you dont require the "CX" version for L3 + L2
> VPNs?), and you need Advanced Metro IP Access?
We generally
Thanks Mark - As always, extremely helpful!
>
> This is why we moved to MPLS in the Access, via the Cisco
> ME3600X platform.
>
> With this box, we were now able to offer services directly
> at the access port connecting to the customer's CPE. IPv4,
> IPv6, l2vpn's, l3vpn's (and in the future
gh it involves the customer buying a second
circuit.
Phil From: CiscoNSP List
Sent: 11/8/2013 1:13
To: mark.ti...@seacom.mu
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ISP / MPLS "POP" design
Thanks again for your responses Mark,
>
> We dealt with this commercially.
>
> W
On Friday, November 08, 2013 08:12:04 AM CiscoNSP List
wrote:
> If you lost a PE, would you migrate those customer tails
> to an alternate PE? (Assume you would to minimise
> downtime?)
This is why we moved to MPLS in the Access, via the Cisco
ME3600X platform.
With this box, we were now able
Thanks again for your responses Mark,
>
> We dealt with this commercially.
>
> We provided customers with a single uplink. Redundancy was
> never a native part of the solution. If a customer wanted
> redundancy, they paid for it. In such a case, we just
> deliver to live links, and let the cu
On Friday, November 08, 2013 02:00:20 AM CiscoNSP List
wrote:
> How do larger networks deal with this situation? i.e.
> When you have multiple PE's terminating customer tails?
We dealt with this commercially.
We provided customers with a single uplink. Redundancy was
never a native part of the
Cheers Mark,
>
> I'm not sure whether you can do this RANCID.
>
> Your main issue is how you trigger the configuration change,
> and this is where EEM might help. I've never used EEM
> before, but someone had suggested it in a previous post.
>
The EEM solution (to me) just seems a little too
>
>
>On 11/6/13 4:52 PM, CiscoNSP List wrote:
>> Don't forget to use per PE/VRF RDs.
>>
>> re per PE RD's - So you are suggesting for each PE, I use unique RD's
>>for a given VRF? I could see this would assist with
>>troubleshooting(Being able to see which PE a route originated from), are
>>there
On 11/6/13 4:52 PM, CiscoNSP List wrote:
Don't forget to use per PE/VRF RDs.
re per PE RD's - So you are suggesting for each PE, I use unique RD's for a
given VRF? I could see this would assist with troubleshooting(Being able to
see which PE a route originated from), are there any other bene
> For BGP to take over the duties of an IGP, I'd reckon a sub- BGP
> protocol that does not interfere with the mature path- vector BGP
> of old, or knobs that can enable the link state portion of mature
> BGP in ways that do not interfere with normal global BGP
> operations.
Yes the most conv
On Thursday, November 07, 2013 12:29:24 PM Adam Vitkovsky
wrote:
> Well I have even more perverse idea of true link-state
> BGP, I mean literally running version of constrained SPF
> algorithm taking into consideration all the current BGP
> path attributes.
> And it would advertise segment labels
>> I can definitely see BGP-LS maintaining LSDB for several millions of
>> prefixes replacing ISIS and OSPF altogether in ISP cores and large
>> DCs.
>
> I think you mean draft-lapukhov-bgp-routing-large-dc-06,
> since BGP-LS, AFAIK, takes its data from the IGP. So it will only scale
> as much a
On Thursday, November 07, 2013 11:38:22 AM Adam Vitkovsky
wrote:
> Yup RFC 3107 is what I proposed but I guess some of the
> folks would try just about anything to maintain the
> status quo instead of implementing separate IGP domains
> and hierarchical MPLS across the globe and I certainly
> und
Yup RFC 3107 is what I proposed but I guess some of the folks would try just
about anything to maintain the status quo instead of implementing separate
IGP domains and hierarchical MPLS across the globe and I certainly
understand why, I mean this could be a carrier changing project if not
executed
On Thursday, November 07, 2013 11:34:45 AM Oliver Boehmer
(oboehmer) wrote:
> or by mutli-area TE, engineered by
> PCE/WAN-Orchestration..
The more the merrier :-).
Mark.
signature.asc
Description: This is a digitally signed message part.
___
cisco-
Yup RFC 3107 is what I proposed but I guess some of the folks would try just
about anything to maintain the status quo instead of implementing separate
IGP domains and hierarchical MPLS across the globe and I certainly
understand why, I mean this could be a carrier changing project if not
executed
>On Thursday, November 07, 2013 11:10:37 AM Oliver Boehmer
>(oboehmer) wrote:
>
>> yep, along with multi-area/level/domain IGP..
>
>In each island, however, multi-level/multi-area IGP's break
>MPLS-TE.
well, there is no free lunch ;-)
>
>Maybe that will be solved by Segment Routing :-).
or by
Yup RFC 3107 is what I proposed but I guess some of the folks would try just
about anything to maintain the status quo instead of implementing separate
IGP domains and hierarchical MPLS across the globe and I certainly
understand why, I mean this could be a carrier changing project if not
executed
On Thursday, November 07, 2013 11:10:37 AM Oliver Boehmer
(oboehmer) wrote:
> yep, along with multi-area/level/domain IGP..
In each island, however, multi-level/multi-area IGP's break
MPLS-TE.
Maybe that will be solved by Segment Routing :-).
> Hmm, I consider BGP-LS only to distribute existi
>
>> no doubt here.. hence I really wonder who would ever put
>> forward such a requirement (and Adam added a smiley, so
>> not sure ;-).. We have unified-mpls to scale to very
>> large MPLS domains, but the IGP certainly doesn't need
>> to scale anywhere close to this..
>
>RFC 3107, I'm assuming
On Thursday, November 07, 2013 10:53:43 AM Oliver Boehmer
(oboehmer) wrote:
> no doubt here.. hence I really wonder who would ever put
> forward such a requirement (and Adam added a smiley, so
> not sure ;-).. We have unified-mpls to scale to very
> large MPLS domains, but the IGP certainly doesn
>On Wednesday, November 06, 2013 04:43:22 PM Oliver Boehmer
>(oboehmer) wrote:
>
>> No, and neither does ISIS, and I am not aware of any such
>> a requirement. Seriously?
>
>Yeah, millions of IGP entries is not a typical requirement,
>AFAIK. BGP issues don't necessarily propagate to the IGP
>:-)
On Thursday, November 07, 2013 03:26:58 AM CiscoNSP List
wrote:
> I think this is a good option - Config-wise, Im thinking
> the best way is to have some templated scriptscan
> Rancid be configured to do something like this? i.e. You
> enter in variables (vlan, vrf, rd, ip address etc), and
>
On Wednesday, November 06, 2013 04:43:22 PM Oliver Boehmer
(oboehmer) wrote:
> No, and neither does ISIS, and I am not aware of any such
> a requirement. Seriously?
Yeah, millions of IGP entries is not a typical requirement,
AFAIK. BGP issues don't necessarily propagate to the IGP
:-).
I thin
Thanks Phil,
>
> IS-IS can scale to a larger number of devices in a single "area" and
> overall network. Really depends on how many devices you are talking
> about. For smaller deployments it usually comes down to who is supporting
> the network and what they are more familiar with.
Cheers -
Thanks Mark,
IS-IS does look quite good - Im going to try it out on a few spare 7200's
> > A couple of options:
>
> 1. Customers pay for two links, and either run them
> as active/active or active/backup. You need to
> ask yourself whether protection for your customer
>
Thanks Adam,
> 1.
> Last time I compared these, in regular IOS ISIS had more knobs than OSPF and
> vice versa in XR.
> But what really matters is the versatility of ISIS and adaptability to new
> protocols/features as Mark mentioned.
Im certainly going to look into ISIS.
>
> 2.
> As Mark m
>> I didn't want to chime into the usual OSPF vs ISIS debate, but the
>> first statement is not (or at least has been for a while no longer)
>> true.
>
>So does OSPF already support 1M routes as requested by an unnamed ISP?
>:)))
No, and neither does ISIS, and I am not aware of any such a requi
> On Nov 6, 2013, at 1:01 AM, "Oliver Boehmer (oboehmer)"
> wrote:
>
>
>
>> IS-IS can scale to a larger number of devices in a single "area" and
>> overall network. Really depends on how many devices you are talking
>> about. For smaller deployments it usually comes down to who is supporti
> I didn't want to chime into the usual OSPF vs ISIS debate, but the
> first statement is not (or at least has been for a while no longer)
> true.
So does OSPF already support 1M routes as requested by an unnamed ISP? :)))
adam
___
cisco-nsp mailing
..@seacom.mu
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ISP / MPLS "POP" design
Hi,
Have a couple more questions on this :)
1. I notice that a number of people use IS-IS rather than OSPF - Is there
benefits to using one vs the other?
2. Majority of customer tails will be suppl
..@seacom.mu
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ISP / MPLS "POP" design
Hi,
Have a couple more questions on this :)
1. I notice that a number of people use IS-IS rather than OSPF - Is there
benefits to using one vs the other?
2. Majority of customer tails will be suppl
On Wednesday, November 06, 2013 08:01:01 AM Oliver Boehmer
(oboehmer) wrote:
> I didn't want to chime into the usual OSPF vs ISIS
> debate, but the first statement is not (or at least has
> been for a while no longer) true.
I tend to agree.
Lots of knobs have made it into OSPF and IS-IS, and co
On Tuesday, November 05, 2013 11:39:11 PM CiscoNSP List
wrote:
> 1. I notice that a number of people use IS-IS rather than
> OSPF - Is there benefits to using one vs the other?
The main differences that I have found between IS-IS and
OSPF that are worth mentioning from a performance standpoint
>IS-IS can scale to a larger number of devices in a single "area" and
>overall network. Really depends on how many devices you are talking
>about. For smaller deployments it usually comes down to who is supporting
>the network and what they are more familiar with.
I didn't want to chime into
to have Carrier A L3 Ints on
>7200(A) and Carrier B L3 Ints on 7200(B), and then if we were to lose
>(for example) 7200(A) we trunk Carrier A's vlans to 7200(B) and create
>the dot1Q Ints to restore service?
>
>Thanks in advance for any feedback/advice.
>
>
>
>>
the dot1Q Ints to restore
service?
Thanks in advance for any feedback/advice.
>
> > From: mark.ti...@seacom.mu
> > To: cisconsp_l...@hotmail.com
> > Subject: Re: [c-nsp] ISP / MPLS "POP" design
> > Date: Thu, 31 Oct 2013 04:06:27 +0200
> > CC: cisco-ns
Thanks very much Mark - Appreciate your input.
> From: mark.ti...@seacom.mu
> To: cisconsp_l...@hotmail.com
> Subject: Re: [c-nsp] ISP / MPLS "POP" design
> Date: Thu, 31 Oct 2013 04:06:27 +0200
> CC: cisco-nsp@puck.nether.net
>
> On Wednesday, October 30,
On Wednesday, October 30, 2013 11:35:59 PM CiscoNSP List
wrote:
> Thanks Mark.
>
> So to clarify - If I run 2 (7201's) as RR's, they would
> take the full tables from the IPTransit 7200's(POPA),
> plus all customer global IP's, plus all VPNv4
> routes(From POPA+B+C)?
That's right.
The 7201's C
On Wednesday, October 30, 2013 02:34:18 AM CiscoNSP List
wrote:
> I thought having RR's would negate the need to create a
> full mesh between PE's?Initially there will be three
> POP's, but expect this to grow to 6+
Route reflectors are always a great idea, whether you have
2x routers or 20
On Wednesday, October 30, 2013 01:54:03 AM Phil Bedard
wrote:
> If I was designing it from scratch there isn't much need
> for the P routers to speak BGP if there are labeled
> paths to the remote PEs. Why are they VPNv4 RRs? You
> do not want a full mesh between PEs or what? How many
> pops
M
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ISP / MPLS "POP" design
Hi,
Hoping someone can provide some "best practice" advise on an ISP/MPLS
design.
Customer's would have a mix of vrf and Internet tails
POP "A" has 2 x 7200's (PE's) and 2 x 6500's (Ps&#
Thanks for the reply Phil,
> If I was designing it from scratch there isn't much need for the P routers to
> speak BGP if there are labeled paths to the remote PEs. Why are they VPNv4
> RRs? You do not want a full mesh between PEs or what? How many pops are
> you talking about?
I t
If I was designing it from scratch there isn't much need for the P routers to
speak BGP if there are labeled paths to the remote PEs. Why are they VPNv4
RRs? You do not want a full mesh between PEs or what? How many pops are you
talking about?
Another kind of popular thing to do these d
Hi,
Hoping someone can provide some "best practice" advise on an ISP/MPLS design.
Customer's would have a mix of vrf and Internet tails
POP "A" has 2 x 7200's (PE's) and 2 x 6500's (Ps') - Both 7200's have a single
IPTransit service(Full BGP table) to different upstreams.
7200's and 6500's wou
46 matches
Mail list logo
