Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 areas and make use of MS-PW. Phil On Jan 27, 2012, at 9:56 PM, Mark Tinka wrote: > 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 >> T-series/CRS based large network though so I guess >> platform choice ($$) and design play a role as well. > > Running RSVP in the core is fairly common because there are > fewer boxes to deal with, and the aggregation and edge parts > of the network can simply run LDP, tunneling that inside an > RSVP-based core as needed. > > But in some cases (such as BGP-MVPN or end-to-end strict > paths), one may need to run RSVP edge to edge, edge to > aggregation, edge to core, e.t.c. This isn't always > desirable, particularly if you want to make it avaialble as > a blanket feature for customers that aren't going to pay > additional for it (and why should they, it might not > necessarily be adding any real value to them). > > In our access, we have a number of ME3600X Ethernet > switches. These are pretty powerful devices, but I'd also > shudder as to how much RSVP state they can maintain as the > network expands. > > Besides, as I mentioned before, we like the MPLS topology to > follow the IP topology, and LDP does this quite nicely. But > if absolutely unavoidable, we will deploy RSVP. > > Mark. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 > T-series/CRS based large network though so I guess > platform choice ($$) and design play a role as well. Running RSVP in the core is fairly common because there are fewer boxes to deal with, and the aggregation and edge parts of the network can simply run LDP, tunneling that inside an RSVP-based core as needed. But in some cases (such as BGP-MVPN or end-to-end strict paths), one may need to run RSVP edge to edge, edge to aggregation, edge to core, e.t.c. This isn't always desirable, particularly if you want to make it avaialble as a blanket feature for customers that aren't going to pay additional for it (and why should they, it might not necessarily be adding any real value to them). In our access, we have a number of ME3600X Ethernet switches. These are pretty powerful devices, but I'd also shudder as to how much RSVP state they can maintain as the network expands. Besides, as I mentioned before, we like the MPLS topology to follow the IP topology, and LDP does this quite nicely. But if absolutely unavoidable, we will deploy RSVP. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 forwarding performance, > hardware forwarding these days makes that a non-issue, but > you already knew that :-). I guess I just meant the fact that there are fewer lookups and fewer operations on the actual packet with MPLS. All the switching decisions are done ahead of time. This is obviously what makes things like FRR and backup LSP's possible as failover methods. It's true that hardware performance, and better proc/mem speed up non-MPLS based paths enough to make it mostly academic. In theory though MPLS is stll the better way to do things. > > We like running it for Internet traffic because we can > remove BGP (for v4) from the core. That's all. > > On the application side, we like running it because we can > offer those "cool" services like IPTv, l2vpn and them. > >> 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. > > We have a large-ish network, particularly in the Access > (lots of Metro-E switches that are IP/MPLS-aware). Trying to > run RSVP everywhere isn't feasible, when your customers are > demanding lower and lower prices. 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 T-series/CRS based large network though so I guess platform choice ($$) and design play a role as well. > > Given the amount of effort required for this, we relegate > RSVP-TE to: > > o Multicast for IPTv services (we'll be using mLDP > for data-based Multicast services). We run FRR > here too. > > o Unequal cost routing within the core, so we don't > have idle links when others are full. Keeping it > in the core only reduces state. > > o Specific requests from customers who want their > traffic to take a specific path, or failover > within a very short time (note I don't say 50ms). > This we charge expensively to discourage customers > from buying it, as it's hectic to maintain, and > overall, the differences in latency across several > points in the country is very, very negligible. > Moreover, we've found failover times for BFD + our > tuned IS-IS to be reasonable for most > applications. > > > All RSVP instances run Refresh Reduction for scaling, even > if state is relatively low due to the above. Makes sense. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
I didn't think the design was that complicated. Need to get default route into customer VRFs. Need to support "firewall-in-the-cloud." Done. With reporting and tiered bandwidth. Agree with Mark's points below, however. We started off like "wee!" when it came to MPLS-TE... but then decided to just use LDP by default and MPLS-TE as the exception. Also, we could have put the internet into an LSYS. In fact... now I'm thinking we should do that. For stuff in the same data center as the internet pipe, we are seeing ~1ms of delay from edge-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 VRF? 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 almost impossible to explain, that the numbers, > traceroute shows, have nothing to do with their > kitty-photos-not-loading problem. One of the reasons we: o Don't disable TTL propagation across our MPLS network. o Avoid, as much as possible, running MPLS LPS's that differ, greatly, from IGP routing (i.e., LDP vs. RSVP) for Internet traffic. This issue is massively exacerbated if you're running FA's, which is why if we have to send traffic down RSVP LSP's, we prefer IGP Shortcuts (Autoroute Announce). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 almost impossible to explain, that the numbers, > traceroute shows, have nothing to do with their > kitty-photos-not-loading problem. One of the reasons we: o Don't disable TTL propagation across our MPLS network. o Avoid, as much as possible, running MPLS LPS's that differ, greatly, from IGP routing (i.e., LDP vs. RSVP) for Internet traffic. This issue is massively exacerbated if you're running FA's, which is why if we have to send traffic down RSVP LSP's, we prefer IGP Shortcuts (Autoroute Announce). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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, hardware forwarding these days makes that a non-issue, but you already knew that :-). We like running it for Internet traffic because we can remove BGP (for v4) from the core. That's all. On the application side, we like running it because we can offer those "cool" services like IPTv, l2vpn and them. > 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. We have a large-ish network, particularly in the Access (lots of Metro-E switches that are IP/MPLS-aware). Trying to run RSVP everywhere isn't feasible, when your customers are demanding lower and lower prices. Given the amount of effort required for this, we relegate RSVP-TE to: o Multicast for IPTv services (we'll be using mLDP for data-based Multicast services). We run FRR here too. o Unequal cost routing within the core, so we don't have idle links when others are full. Keeping it in the core only reduces state. o Specific requests from customers who want their traffic to take a specific path, or failover within a very short time (note I don't say 50ms). This we charge expensively to discourage customers from buying it, as it's hectic to maintain, and overall, the differences in latency across several points in the country is very, very negligible. Moreover, we've found failover times for BFD + our tuned IS-IS to be reasonable for most applications. All RSVP instances run Refresh Reduction for scaling, even if state is relatively low due to the above. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 wrapping which can add congestion in the opposite direction. Partial mesh alleviates some of that but most networks have some kind of ring element somewhere. Phil 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). 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 how your detours are calculated is itself a big enough >> headache. > > That's not how FRR works at least for RSVP. It pretty much just > re-runs cspf with something removed. So it's the same route your IGP > would choose if said "thing" went dark. I don't have many obscure > paths where I wouldn't want traffic to go so I can't really comment on > your earlier idea. That being said I've never seen FRR choose a path > worse than the path the IGP would choose. It's just preselects that > path and pre-signals it. I'm sure there are failure scenarios though. > > >> 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 almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. >>> >>> Hey kitty photos are serious business especially if you are facebook >>> stalking the aforementioned kitty. >> >> >> Absolutely. This is why in case of issues you should not waste time for >> explaining why your core router is 200ms away from the previous hop. >> > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
> > 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 how your detours are calculated is itself a big enough > > headache. > > That's not how FRR works at least for RSVP. It pretty much just > re-runs cspf with something removed. So it's the same route your IGP > would choose if said "thing" went dark. I don't have many obscure > paths where I wouldn't want traffic to go so I can't really comment on > your earlier idea. That being said I've never seen FRR choose a path > worse than the path the IGP would choose. It's just preselects that > path and pre-signals it. I'm sure there are failure scenarios though. > > Seems like you confuse FRR (aka local repair) with secondary LSP path. FRR path setup is initiated by P routers, when the primary and secondary LSP paths are initiated by head-end PE. FRR detour only holds until IGP recalculates a new path (doesn't much matter with or without TE), which can (and very probably will) not even include the P router, acted as a point of local repair after failure. http://www.juniper.net/techpubs/software/junos/junos94/swconfig-mpls-apps/fast-reroute-overview.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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). 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 how your detours are calculated is itself a big enough >> headache. > > That's not how FRR works at least for RSVP. It pretty much just > re-runs cspf with something removed. So it's the same route your IGP > would choose if said "thing" went dark. I don't have many obscure > paths where I wouldn't want traffic to go so I can't really comment on > your earlier idea. That being said I've never seen FRR choose a path > worse than the path the IGP would choose. It's just preselects that > path and pre-signals it. I'm sure there are failure scenarios though. > > >> 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 almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. >>> >>> Hey kitty photos are serious business especially if you are facebook >>> stalking the aforementioned kitty. >> >> >> Absolutely. This is why in case of issues you should not waste time for >> explaining why your core router is 200ms away from the previous hop. >> > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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-end to tail-end. Whether this happens often or rare, the > need to care how your detours are calculated is itself a big enough > headache. That's not how FRR works at least for RSVP. It pretty much just re-runs cspf with something removed. So it's the same route your IGP would choose if said "thing" went dark. I don't have many obscure paths where I wouldn't want traffic to go so I can't really comment on your earlier idea. That being said I've never seen FRR choose a path worse than the path the IGP would choose. It's just preselects that path and pre-signals it. I'm sure there are failure scenarios though. > >> > 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 >> > almost impossible to explain, that the numbers, traceroute shows, have >> > nothing to do with their kitty-photos-not-loading problem. >> >> Hey kitty photos are serious business especially if you are facebook >> stalking the aforementioned kitty. > > > Absolutely. This is why in case of issues you should not waste time for > explaining why your core router is 200ms away from the previous hop. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
> 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 often or rare, the need to care how your detours are calculated is itself a big enough headache. > 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 > > almost impossible to explain, that the numbers, traceroute shows, have > > nothing to do with their kitty-photos-not-loading problem. > > Hey kitty photos are serious business especially if you are facebook > stalking the aforementioned kitty. > Absolutely. This is why in case of issues you should not waste time for explaining why your core router is 200ms away from the previous hop. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 sending trucks from a speedway to a narrow detour > path through a village 10 miles away. Only effect is getting it jammed. The > Internet users will also not notice a well-tuned IGP reroute or a head-end > switchover to a pre-signaled backup LSP. I can see this happening in some corner cases, but generally speaking why would FRR LSP's take a route different than what the IGP would converge to. CSPF is roughly SPF over a different set of values. I'm asking because I've never seen this in the wild, but I'm usually switching from one speedway to another without the burden of narrow villages. > > 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 > almost impossible to explain, that the numbers, traceroute shows, have > nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
> 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 narrow detour path through a village 10 miles away. Only effect is getting it jammed. The Internet users will also not notice a well-tuned IGP reroute or a head-end switchover to a pre-signaled backup LSP. 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 almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 traffic flowing between them. >> You also give up some of the MPLS knobs such as FRR and >> link/node protection. What do you gain by doing this? > > We signal mostly by LDP, and scarcely by RSVP. > > One of the main reasons we allow Internet traffic to be > forwarded by MPLS through the network is to enjoy a BGP-free > core for IPv4. That's the only relation the global table has > with MPLS. Otherwise, MPLS is used strictly for MPLS-based > applications. I agree... I think. MPLS has a better forwarding paradigm and the IGP only core of P routers is a plus. > > We only use RSVP for p2mp LSP's for our BGP-MVPN Multicast > (IPTv) services, and also for focused TE requirements, e.g., > unequal cost paths within the core. > > As the TE is mostly for Internet traffic, we don't turn on > FRR for that. We only enable FRR for the p2mp RSVP-based > LSP's, and those are dedicated to IPTv. 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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 also give up some of the MPLS knobs such as FRR and > link/node protection. What do you gain by doing this? We signal mostly by LDP, and scarcely by RSVP. One of the main reasons we allow Internet traffic to be forwarded by MPLS through the network is to enjoy a BGP-free core for IPv4. That's the only relation the global table has with MPLS. Otherwise, MPLS is used strictly for MPLS-based applications. We only use RSVP for p2mp LSP's for our BGP-MVPN Multicast (IPTv) services, and also for focused TE requirements, e.g., unequal cost paths within the core. As the TE is mostly for Internet traffic, we don't turn on FRR for that. We only enable FRR for the p2mp RSVP-based LSP's, and those are dedicated to IPTv. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 > services to those that MUST have it to work, e.g., BGP- > MVPN's, l2vpn's, l3vpn's, VPLS, e.t.c. Anything else that > doesn't really need MPLS lives on its own, e.g., IPv6 (no > need for 6PE), Internet access, e.t.c. > 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 also give up some of the MPLS knobs such as FRR and link/node protection. What do you gain by doing this? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 complex" is much better than "keeping it really stupid." For that reason, "Everything in a VRF" (tm) is sometimes a useful thing to do. -- Tim:> ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 hold in a VRF, or how many VRF's they can have with a fixed number of routes in them. We also want to avoid putting too much reliance on MPLS for basic services like Internet access. We relegate MPLS-based services to those that MUST have it to work, e.g., BGP- MVPN's, l2vpn's, l3vpn's, VPLS, e.t.c. Anything else that doesn't really need MPLS lives on its own, e.g., IPv6 (no need for 6PE), Internet access, e.t.c. Keeping it really stupid is what we're after :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
http://packetpushers.net/internet-as-a-service-in-an-mpls-cloud/ Check that out... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Mark Smith To: juniper-nsp@puck.nether.net Sent: Thursday, January 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 to route internet and VRFs. What are the pros and cons of these approaches? Pointers to good materials are appreciated. (please excuse me if this is in the series of stupid questions ;) Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 the issue by using entropy labels, just wondering how Juniper handles it. As for L3VPN versus not if it is a greenfield build then it could make sense to use it if it fits what you need. Keep infrasrructue Phil On Jan 19, 2012, at 4:11 PM, Nathan Sipes wrote: > 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 spotting routes that shouldn't > exist easy. > 3. I also up until recently had a need to split providers and peerings > in to separate VRFs and selectively control which traffic was allowed to > utilize certain providers to ensure that the outbound and in bound traffic > crossed the same set of firewalls. (this was the result of the conversion > from one network topology/design to another) > 4. I also use my inet.0 instance for in-band management. > > There are some benefits to doing it each way. It always comes back to what > do you want to accomplish? > > Nathan > > > On Thu, Jan 19, 2012 at 8:05 AM, Mark Smith wrote: > >> 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 good materials are appreciated. >> >> (please excuse me if this is in the series of stupid questions ;) >> >> Thanks. >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 spotting routes that shouldn't exist easy. 3. I also up until recently had a need to split providers and peerings in to separate VRFs and selectively control which traffic was allowed to utilize certain providers to ensure that the outbound and in bound traffic crossed the same set of firewalls. (this was the result of the conversion from one network topology/design to another) 4. I also use my inet.0 instance for in-band management. There are some benefits to doing it each way. It always comes back to what do you want to accomplish? Nathan On Thu, Jan 19, 2012 at 8:05 AM, Mark Smith wrote: > 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 good materials are appreciated. > > (please excuse me if this is in the series of stupid questions ;) > > Thanks. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
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 little bit more complicated since you'll have to match extended communities. INET.0 is more or less just another VRF though. Do you have another use for INET.0 or are you just thinking it's cleaner to have everything in VRF's? 2012/1/19 Mark Smith > 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 good materials are appreciated. > > (please excuse me if this is in the series of stupid questions ;) > > Thanks. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
Hey there It depends how symmetric your network is If the links do not have the same BW, you can have it in one VRF so that you can use traffic engineering to avoid certain links which are not the most ideals while you run the IGP on the network to provide services other than internet that might not demand great speed link Of course, as the others say, there's not a right answer, but it depends on what you want Cheers /Jose Maria -Mensaje original- De: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] En nombre de Mark Smith Enviado el: jueves, 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 (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 good materials are appreciated. (please excuse me if this is in the series of stupid questions ;) Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Por favor, antes de imprimir este correo, valore si es estrictamente necesario. La naturaleza y el medio ambiente lo agradecerán. Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que TELECABLE DE ASTURIAS, S.A.U no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención o a través del teléfono (+ 34) 984191000 y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
Personally I think it's a great question - I'm not sure there's a "perfect answer". We run our full tables into inet.0 - we also merge inet.3 into inet.0 using "traffic-engineering bgp-igp-both-ribs" there were a number of reasons for doing this including link-protection etc. By no means am I saying that this was the best route for us to take or one that is the best route to take (pardon the pun here) I would think it depends on what you want from the network... Cheers, Paul -Original Message- From: juniper-nsp-boun...@puck.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? 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 good materials are appreciated. (please excuse me if this is in the series of stupid questions ;) Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 to route internet and VRFs. What are the pros and cons of these approaches? Pointers to good materials are appreciated. (please excuse me if this is in the series of stupid questions ;) Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
