We use RSVP exclusively in our business access and core networks due to markets
wanting the 50ms protection for services like cell backhaul and CES. The
boxes we use are fairly small and cheap and handle RSVP fairly well (not C or J
but A). We do break up our access networks into multiple IGP
On Saturday, January 28, 2012 07:59:36 AM Keegan Holley
wrote:
> Makes sense. I'm still straddling the line between large
> enterprise and small service provider so I haven't felt
> the resource bite from RSVP everywhere. Interesting to
> hear that perspective though. I've seen RSVP work in a
2012/1/26 Mark Tinka :
> On Friday, January 27, 2012 02:30:35 AM Keegan Holley wrote:
>
>> I agree... I think. MPLS has a better forwarding paradigm
>> and the IGP only core of P routers is a plus.
>
> Well, I'm not so sure MPLS has a better forwarding paradigm
> per se. If you're talking about raw
-to-edge.
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://packetpushers.net/author/dwinkworth/
From: Mark Tinka
To: Pavel Lunin
Cc:
Sent: Thursday, January 26, 2012 9:21 PM
Subject: Re: [j-nsp] Internet routes in MPLS network, global table or own VR
On Friday, January 27, 2012 03:48:23 AM Pavel Lunin wrote:
> What the VRF-based Internet users will definitely notice
> is (looks like RAS is tired of telling this story) is
> ICMP tunneling and consequent hard to interpret delay
> values. People are very suspicious to the numbers. This
> is almos
On Friday, January 27, 2012 02:30:35 AM Keegan Holley wrote:
> I agree... I think. MPLS has a better forwarding paradigm
> and the IGP only core of P routers is a plus.
Well, I'm not so sure MPLS has a better forwarding paradigm
per se. If you're talking about raw forwarding performance,
hardwa
I think Pavel is speaking of the case where the PLR is more than one hop from
the ingress node. It is very topology dependent but you can end up with
bypasses or detours taking a different path than the IGP especially when its a
few hops from the ingress node. Also ring topologies introduce w
> > Because FRR uses a path from a different entry (PLP) to probably a
> different
>
Ups, I meant PLR, of course.
> > exit (say, next-next-hop). When normal LSP (either SPF or CSPF
> calculated)
> > is a path from head-end to tail-end. Whether this happens often or rare,
> the
> > need to care
On Jan 26, 2012, at 4:01 PM, Keegan Holley wrote:
> 2012/1/26 Pavel Lunin :
>>
>>
>>>
>>> why would FRR LSP's take a route different than what the IGP would
>>> converge to.
>>
>>
>> Because FRR uses a path from a different entry (PLP) to probably a different
>> exit (say, next-next-hop).
2012/1/26 Pavel Lunin :
>
>
>>
>> why would FRR LSP's take a route different than what the IGP would
>> converge to.
>
>
> Because FRR uses a path from a different entry (PLP) to probably a different
> exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated)
> is a path from head-
> why would FRR LSP's take a route different than what the IGP would
> converge to.
Because FRR uses a path from a different entry (PLP) to probably a
different exit (say, next-next-hop). When normal LSP (either SPF or CSPF
calculated) is a path from head-end to tail-end. Whether this happens oft
2012/1/26 Pavel Lunin :
>
>> Why not FRR everything? The control plane hit is negligable even if
>> your internet users wouldn't notice, care about, or even understand
>> the improvements.
>
>
> FRRed traffic can follow very fancy routes eating bandwidth on the way. FRR
> for high loads is like sen
> Why not FRR everything? The control plane hit is negligable even if
> your internet users wouldn't notice, care about, or even understand
> the improvements.
>
FRRed traffic can follow very fancy routes eating bandwidth on the way. FRR
for high loads is like sending trucks from a speedway to a n
2012/1/26 Mark Tinka :
> On Friday, January 27, 2012 12:36:50 AM Keegan Holley wrote:
>
>> What do you use for signaling? It seems like overkill to
>> keep one kind of traffic from using the MPLS operations
>> if there are already LSP's between the source and the
>> destination and L3/L2vpn traffi
On Friday, January 27, 2012 12:36:50 AM Keegan Holley wrote:
> What do you use for signaling? It seems like overkill to
> keep one kind of traffic from using the MPLS operations
> if there are already LSP's between the source and the
> destination and L3/L2vpn traffic flowing between them.
> You
2012/1/26 Mark Tinka :
> On Sunday, January 22, 2012 08:55:07 AM Derick Winkworth
> wrote:
>
>> http://packetpushers.net/internet-as-a-service-in-an-mpls
>> -cloud/
>
> We also want to avoid putting too much reliance on MPLS for
> basic services like Internet access. We relegate MPLS-based
> servic
On Thu, Jan 26, 2012 at 6:52 AM, Mark Tinka wrote:
> Keeping it really stupid is what we're after :-).
>
> Mark.
We run Internet in a VRF, but I have to agree with Mark's comments.
Unfortunately, there are lots of Engineers/Vendors/Security
Experts/Auditors who think that "making it really compl
On Sunday, January 22, 2012 08:55:07 AM Derick Winkworth
wrote:
> http://packetpushers.net/internet-as-a-service-in-an-mpls
> -cloud/
We keep Internet routes in the global table on all routers
we operate. Different routers have different capabilities
when it comes to how many routes they can
19, 2012 9:05 AM
Subject: [j-nsp] Internet routes in MPLS network, global table or own VRF?
Hi
How should the global Internet routes be organized in IP/MPLS network?
Should they be put into global (inet.0) routing table or in their own
VRF (e.g. internet.inet.0)? Assume same P/PE routers are used
How is Juniper with load distribution of traffic over aggregates or ECMP with
it being in a L3VPN? I've seen issues with at least one other vendor who hashes
based on the service label on ingress nodes which makes using a L3VPN
problematic for higher bandwidth networks. They have since solved t
I think in large part it depends on your goal.
I personally chose to keep everything out of my inet.0 table that wasn't
core related.
From this I gained a couple of things.
1. Only the PE's that I want to have the full internet table have it.
2. My inet.0 table is small and it makes spottin
That's really subjective so it depends on your network. Placing the full
internet table in a VRF will could cause it to be advertised to PE routers
that may not need it, but if your routers can handle that it may not be a
big deal. Also, filtering routes for things like partial tables becomes a
ueves, 19 de enero de 2012 16:05
Para: juniper-nsp@puck.nether.net
Asunto: [j-nsp] Internet routes in MPLS network, global table or own VRF?
Hi
How should the global Internet routes be organized in IP/MPLS network?
Should they be put into global (inet.0) routing table or in their own
VRF
nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Smith
Sent: Thursday, January 19, 2012 10:05 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Internet routes in MPLS network, global table or own VRF?
Hi
How should the global Internet routes be organized in IP/MPLS network?
S
Hi
How should the global Internet routes be organized in IP/MPLS network?
Should they be put into global (inet.0) routing table or in their own
VRF (e.g. internet.inet.0)? Assume same P/PE routers are used to route
internet and VRFs.
What are the pros and cons of these approaches?
Pointers to go
25 matches
Mail list logo
