Re: [j-nsp] Network automation vs. manual config
We have daily work to configure basic load balancer, customer certs and open firewalls, daily 5-15 tickets, without some sort of automation that will be waste a lot of resources for Sr people. So I used ansible and some python and shell script. Also considering to use Yaml, Jinja2 for standard template for nexus switch base provisioning, standardize tacacs, snmp, features, not, and some ACLs Just a thought Sent from my iPhone > On Aug 17, 2018, at 6:06 AM, Michael Still wrote: > > Side note on apply groups and display inheritance. I've submitted a Juniper > ER for an enhancement to have the ability to have ' | display inheritance' > a 'default' cli behavior (configurable via 'set cli display-inheritance' > option that is defaulted to off). I've also asked for a login-class option > to enable this for specific user role such as front line NOC users who may > benefit from having it on by default. This is ER-077163 if you want to poke > your Juniper SE about it. > > The reason I've asked for this is specifically because I've seen NOC > personnel spend many cycles investigating an issue not realizing that > particular hidden apply-group config was affecting their investigation. > > I have a couple other semi-related (to automation / configuration > enhancement) ER's going if folks are interested and would like to chat > about those directly. > > >> On Fri, Aug 17, 2018 at 8:20 AM Nathan Ward wrote: >> >> >>> On 17/08/2018, at 10:54 PM, Antti Ristimäki >> wrote: >>> >>> Another option is to apply the auto-generated configuration via >> apply-groups and apply all manual configurations explicitly so that the >> automatic and manual configurations merge with each other. The positive >> side of this approach is that it makes easy to develop the automation tools >> so that manual configs are not overridden by auto-generated config, but I >> personally see somewhat inconvenient that one really doesn't see the >> effective running-config when using apply-groups, unless one remembers to >> display inheritance. >> >> We’ve implemented this at a network I support, seems to be going well. We >> approach it slightly differently though, in a way which may help solve your >> usability problem, in a bit of a roundabout way. In short, we build groups >> in to almost everything so people are used to doing display inheritance if >> they need to look deeper at things. It’s not perfect, but it’s the best way >> I’ve found to manage large bits of JunOS config. >> >> We have 3 types of groups: >> Global* - common on every router they exist on, applied at top level only >> Local* - unique to this router, applied at any level >> * - common on every router they exist on, applied at any level >> >> All our groups have apply-flags omit; >> >> Local* groups are only used when something is re-used several times on the >> one router - for example on our BNGs, a list of DHCP interfaces in each of >> the routing-instances we might push a subscriber in to. >> >> So, for example: >> - GlobalDualREMX sets up whatever our standard things are for an MX with >> 2 REs, applied at top level. >> - “MPLS" is applied at `interfaces blah` and `protocols rsvp interface >> blah`, etc and includes our per-interface MPLS config. >> - VRFCustomers includes our import/export policies for our Customers VRF >> (applied inside a routing-instance), and the loopback filter config for the >> Customers VRF loopback (applied inside an interface). >> >> The only config that’s outside groups is config unique to that router - >> so, IP addressing, routing-instance names and RDs, interfaces (though they >> have apply-groups within them for many settings), hostname, etc. >> >> This means: >> 1) Config is short because of apply-flags omit. Seeing things unique to >> this router is easy. It’s easy to spot differences as apply-groups are >> different - and that’s all you generally need to look for. I just looked, >> our BNGs are all about 500 lines of config, and all have identical group >> config on them. Most of the config is rsvp-te tunnels, and access network >> interfaces. >> 2) When we want to look deeper, we know to do `| display inheritance | >> except #` and it becomes muscle memory - this really is the bit that helps >> your use case, haha. >> 3) We can copy our groups from a git repository, load replace (in our git >> reply they all have replace tags) and commit. Keeping the common config >> consistent is super easy. Automating this is one “leg” of automation and >> solves almost all of our automation requirements. >> 4) We can do bespoke mucking about outside the groups, and it’s obvious >> what those things are, and what things need to be tidied up in to groups, >> or what is junk temp config that needs to be thrown out. >> >> I think where this could work for you, is to have your automation apply >> any router-specific config just like a human would - outside the groups, >> but leveraging the groups as much as possible. If you want to
Re: [j-nsp] L3VPN/RR/PE on Same router
> > It's about increasing the odds of it to fall on the right side, > Exactly ! > But comparing say XR and Junos, judging from the rest of the inner workings I could experience empirically, I'd say they are sufficiently different > implementations. > True. In fact even XE & XR BGP code core is quite different in spite of number of failed attempts to at least make new bgp features to share code. The bottom line is that if you get badly malformed update, broken attribute, illegal NLRIs, mistaken blast of BGP-LS etc .. the probability that all of those BGP implementations crash is much less likely then when compared that your chosen one will work even if you run two instances of it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
> From: Youssef Bengelloun-Zahr [mailto:benge...@gmail.com] > Sent: Friday, August 17, 2018 3:43 PM > To: Robert Raszuk > Cc: adamv0...@netconsultings.com; Saku Ytti; Juniper List > Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > > Hi, > > > > Le 17 août 2018 à 16:28, Robert Raszuk a écrit : > > >> and that thing would then crash BGP on RRs, can't afford that happening. > > > > Then best thing is to run two or three RRs in parallel each using > > different BGP code base - even for the same AFI/SAFI pair > > > > I am seeing number of networks running single vendor RRs and when > > things melt they run around and claim that the problem was was really > > so rear and unexpected :) Well usually bugs are of unexpected nature > > And I have seen the opposite, ie networks running multiple vendor RRs, > ending up with crashs because of buggy BGP implementations. > > At the end of the day, it is a question of tossing a coin and hopping it will > fall > on the right side. > It's about increasing the odds of it to fall on the right side, Yes you can have multiple vendors that have the same quagga/bird BGP message parser code, But comparing say XR and Junos, judging from the rest of the inner workings I could experience empirically, I'd say they are sufficiently different implementations. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
> And I have seen the opposite, ie networks running multiple vendor RRs, > ending up with crashs because of buggy BGP implementations. Hmmm since usually IBGP RRs do not talk to each other (leave alone RR hierarchy aside) what you are essentially endorsing is single vendor networks right ? If I have Cisco PEs and Juniper RRs by your description it may crash ... hence better to avoid it - right ?. Good thing this is thread about iBGP not eBGP :):) Thx R. On Fri, Aug 17, 2018 at 4:43 PM, Youssef Bengelloun-Zahr wrote: > Hi, > > > > Le 17 août 2018 à 16:28, Robert Raszuk a écrit : > > >> and that thing would then crash BGP on RRs, can't afford that happening. > > > > Then best thing is to run two or three RRs in parallel each using > different > > BGP code base - even for the same AFI/SAFI pair > > > > I am seeing number of networks running single vendor RRs and when things > > melt they run around and claim that the problem was was really so rear > and > > unexpected :) Well usually bugs are of unexpected nature > > And I have seen the opposite, ie networks running multiple vendor RRs, > ending up with crashs because of buggy BGP implementations. > > At the end of the day, it is a question of tossing a coin and hopping it > will fall on the right side. > > > > > Thx, > > R. > > > > > > On Fri, Aug 17, 2018 at 4:05 PM, wrote: > > > >>> From: Saku Ytti [mailto:s...@ytti.fi] > >>> Sent: Friday, August 17, 2018 2:38 PM > >>> To: Mark Tinka > >>> Cc: adamv0...@netconsultings.com; tim tiriche; Juniper List > >>> Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > >>> > >>> Hey Mark, > >>> > > Yes a good practice is to separate internet routes from > > internal/services l3vpn routes onto separate BGP control planes > > (different sessions at least) so that malformed bgp msg will affect > > just one part of your overall BGP infrastructure. > > I see you've been giving this advice for quite some time now. > >>> > >>> I'm siding with Adam here. His disaster scenario actually happed to me > in > >>> 3292. We ran for years VXR VPN route-reflectors, after we changed them > to > >>> MX240 we added lot more RR's, with some hard justifications to > >>> management why we need more when we've had no trouble with the count > >>> we had. > >>> After about 3 months of running MX240 reflectors, we got bad BGP UPDATE > >>> and crashed each reflector, which was unprecedented outage in the > history > >>> of the network. And tough to explain to management, considering we just > >>> had made the reflection more redundant with some significant > investment. > >>> I'm sure they believed we just had cocked it up, as people don't really > >>> believe in chance/randomness, evident how people justify that things > >> can't > >>> be broken, by explaining how in previous moment in time it wasn't > broken, > >>> implying that transitioning from non-broken to broken is impossible. > >>> > >>> Note, this is not to trash on Juniper, all vendors have bad BGP > >>> implementations and I'm sure one can fuzz any of them to find crash > bugs. > >>> > >> Oh yeah for sure, the XR RRs too were crashing upon reception of > malformed > >> BGP updates in the past. > >> > >> Currently XR BGP is *somewhat protected by the "BGP Attribute Filter and > >> Enhanced Attribute Error > >> Handling" (now RFC 7606) which already proved itself to me (just got a > log > >> msg informing me the malformed attribute was deleted instead of an > >> important transit session reset). > >> Unfortunately can't enable it on junos as the code we run would instead > of > >> session reset crashed the rpd due to a bug if the RFC 7606 feature > would be > >> enabled. > >> > >> *But still I'd be haunted by what could happen if RFC 7606 would have > >> missed something and that thing would then crash BGP on RRs, can't > afford > >> that happening. > >> > >> > >>> Not only is it CAPEX irrelevant to have separate RR for IPv4 and IPv6, > >> but you > >>> also get faster convergence, as more CPU cycles, fewer BGP neighbours, > >> less > >>> routes. I view it as cheap insurance as well as very simple horizontal > >> scaling. > >>> > >> And going virtual this really is a marginal spend in the grand scheme of > >> things. > >> > >> adam > >> > >> netconsultings.com > >> ::carrier-class solutions for the telecommunications industry:: > >> > >> > >> ___ > >> 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] L3VPN/RR/PE on Same router
Hi, Le 17 août 2018 à 16:28, Robert Raszuk a écrit : >> and that thing would then crash BGP on RRs, can't afford that happening. > > Then best thing is to run two or three RRs in parallel each using different > BGP code base - even for the same AFI/SAFI pair > > I am seeing number of networks running single vendor RRs and when things > melt they run around and claim that the problem was was really so rear and > unexpected :) Well usually bugs are of unexpected nature And I have seen the opposite, ie networks running multiple vendor RRs, ending up with crashs because of buggy BGP implementations. At the end of the day, it is a question of tossing a coin and hopping it will fall on the right side. > > Thx, > R. > > > On Fri, Aug 17, 2018 at 4:05 PM, wrote: > >>> From: Saku Ytti [mailto:s...@ytti.fi] >>> Sent: Friday, August 17, 2018 2:38 PM >>> To: Mark Tinka >>> Cc: adamv0...@netconsultings.com; tim tiriche; Juniper List >>> Subject: Re: [j-nsp] L3VPN/RR/PE on Same router >>> >>> Hey Mark, >>> > Yes a good practice is to separate internet routes from > internal/services l3vpn routes onto separate BGP control planes > (different sessions at least) so that malformed bgp msg will affect > just one part of your overall BGP infrastructure. I see you've been giving this advice for quite some time now. >>> >>> I'm siding with Adam here. His disaster scenario actually happed to me in >>> 3292. We ran for years VXR VPN route-reflectors, after we changed them to >>> MX240 we added lot more RR's, with some hard justifications to >>> management why we need more when we've had no trouble with the count >>> we had. >>> After about 3 months of running MX240 reflectors, we got bad BGP UPDATE >>> and crashed each reflector, which was unprecedented outage in the history >>> of the network. And tough to explain to management, considering we just >>> had made the reflection more redundant with some significant investment. >>> I'm sure they believed we just had cocked it up, as people don't really >>> believe in chance/randomness, evident how people justify that things >> can't >>> be broken, by explaining how in previous moment in time it wasn't broken, >>> implying that transitioning from non-broken to broken is impossible. >>> >>> Note, this is not to trash on Juniper, all vendors have bad BGP >>> implementations and I'm sure one can fuzz any of them to find crash bugs. >>> >> Oh yeah for sure, the XR RRs too were crashing upon reception of malformed >> BGP updates in the past. >> >> Currently XR BGP is *somewhat protected by the "BGP Attribute Filter and >> Enhanced Attribute Error >> Handling" (now RFC 7606) which already proved itself to me (just got a log >> msg informing me the malformed attribute was deleted instead of an >> important transit session reset). >> Unfortunately can't enable it on junos as the code we run would instead of >> session reset crashed the rpd due to a bug if the RFC 7606 feature would be >> enabled. >> >> *But still I'd be haunted by what could happen if RFC 7606 would have >> missed something and that thing would then crash BGP on RRs, can't afford >> that happening. >> >> >>> Not only is it CAPEX irrelevant to have separate RR for IPv4 and IPv6, >> but you >>> also get faster convergence, as more CPU cycles, fewer BGP neighbours, >> less >>> routes. I view it as cheap insurance as well as very simple horizontal >> scaling. >>> >> And going virtual this really is a marginal spend in the grand scheme of >> things. >> >> adam >> >> netconsultings.com >> ::carrier-class solutions for the telecommunications industry:: >> >> >> ___ >> 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] L3VPN/RR/PE on Same router
> and that thing would then crash BGP on RRs, can't afford that happening. Then best thing is to run two or three RRs in parallel each using different BGP code base - even for the same AFI/SAFI pair I am seeing number of networks running single vendor RRs and when things melt they run around and claim that the problem was was really so rear and unexpected :) Well usually bugs are of unexpected nature Thx, R. On Fri, Aug 17, 2018 at 4:05 PM, wrote: > > From: Saku Ytti [mailto:s...@ytti.fi] > > Sent: Friday, August 17, 2018 2:38 PM > > To: Mark Tinka > > Cc: adamv0...@netconsultings.com; tim tiriche; Juniper List > > Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > > > > Hey Mark, > > > > > > Yes a good practice is to separate internet routes from > > > > internal/services l3vpn routes onto separate BGP control planes > > > > (different sessions at least) so that malformed bgp msg will affect > > > > just one part of your overall BGP infrastructure. > > > > > > I see you've been giving this advice for quite some time now. > > > > I'm siding with Adam here. His disaster scenario actually happed to me in > > 3292. We ran for years VXR VPN route-reflectors, after we changed them to > > MX240 we added lot more RR's, with some hard justifications to > > management why we need more when we've had no trouble with the count > > we had. > > After about 3 months of running MX240 reflectors, we got bad BGP UPDATE > > and crashed each reflector, which was unprecedented outage in the history > > of the network. And tough to explain to management, considering we just > > had made the reflection more redundant with some significant investment. > > I'm sure they believed we just had cocked it up, as people don't really > > believe in chance/randomness, evident how people justify that things > can't > > be broken, by explaining how in previous moment in time it wasn't broken, > > implying that transitioning from non-broken to broken is impossible. > > > > Note, this is not to trash on Juniper, all vendors have bad BGP > > implementations and I'm sure one can fuzz any of them to find crash bugs. > > > Oh yeah for sure, the XR RRs too were crashing upon reception of malformed > BGP updates in the past. > > Currently XR BGP is *somewhat protected by the "BGP Attribute Filter and > Enhanced Attribute Error > Handling" (now RFC 7606) which already proved itself to me (just got a log > msg informing me the malformed attribute was deleted instead of an > important transit session reset). > Unfortunately can't enable it on junos as the code we run would instead of > session reset crashed the rpd due to a bug if the RFC 7606 feature would be > enabled. > > *But still I'd be haunted by what could happen if RFC 7606 would have > missed something and that thing would then crash BGP on RRs, can't afford > that happening. > > > > Not only is it CAPEX irrelevant to have separate RR for IPv4 and IPv6, > but you > > also get faster convergence, as more CPU cycles, fewer BGP neighbours, > less > > routes. I view it as cheap insurance as well as very simple horizontal > scaling. > > > And going virtual this really is a marginal spend in the grand scheme of > things. > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: > > > ___ > 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] Network automation vs. manual config
Hi Antti, folks, @Antti: Feel free to reach out directly if we can be of assistance. I understand you are in CSC behind FUNET, connected to GÉANT? Here in GÉANT we have 31 x MX480/960 routers, all acting as PE devices (no P devices), spanning Europe. We run a large set of protocols and services (ie: some logical systems, many routing-instances, carrier-of-carriers, dual-stack, LDP, RSVP-TE, MSDP, PIM, etc. etc.). We shift over 1 Tbps and though our number of 'customers' is few - maybe 5-10 homed per box - we're running upto 50,000 lines of config on some boxes. So where do we stand on config automation? Whilst we do use configuration templates, our ['customers'] requirements necessitate some exceptions in places. Given our central position in connecting EU Research and Education networks together, and to the world, we are running quite a mix of services - production, pilot, experimental - and manual configuration direct on the CLI is the only game in town; why automate disposable config? ** Not to be confused with pure lab work - we have several labs, too, and appropriate divisions between lab and production. We are moving toward Ansible/git/Napalm/Bash glue scripts for chunks of configuration which seldom change, eg: chassis, routing-options, snmp, standard policies and filters, etc. IE: We're going to automate the low-hanging fruit first, and expand from there. RE: manual overwrites - What I'm going to POC is using the Junos 'protect' feature to block CLI users from futzing with what lives in git: when git repo is pushed to the routers, we'll unprotect and re-protect those stanzas. So, in an out of hours emergency, our NOC can still unprotect and overwrite anything they need to. Alternatively, fixes they may wish to implement can be updated in git. The key thing at the outset is choice - you can do it the way you're used to, while you learn the new procedures, and there is no negative impact. To ease the migration, learning, training, we plan to start slow and have the git push triggered by hand, rather than, say, cron. We will have quasi-realtime automated diff reports so deviations are spotted same-day and can be addressed. The idea is anyone making a change updates git then does a push (which also verifies). Until we have that, we continue with our partial automation: I've authored numerous scripts - the most commonly used have a web frontend - which take user input, populate templates, and offer to push to the chosen router(s). For instance, all public and private peerings are 100% automated and populate data from peeringdb.com. NB: The above is our current position and plan of action. Please consider our needs are different from most SP networks. In a more commercial operation with large scale cookie-cutter customers (who don't get special treatment - just a service catalogue), database-is-master is the way to go. I'll finish by saying that the FOSS tools out there do a fantastic job - pick the toolchain you like/can understand, and don't be afraid to use it! Off-topic: Almost all change management is performed by automation - config application and verification checks. This means during the PM window, we need only concentrate on verification and 'what went wrong', should something happen. IE: We don't burn brainpower or time making the changes - all that is done weeks in advance, and peer-reviewed if appropriate. Br, Niall Niall Donaghy Senior Network Engineer GÉANT T: +44 (0)1223 371393 M: +44 (0) 7557770303 Skype: niall.donaghy-dante PGP Key ID: 0x77680027 nic-hdl: NGD-RIPE Networks • Services • People Learn more at www.geant.org GÉANT Vereniging (Association) is registered with the Chamber of Commerce in Amsterdam with registration number 40535155 and operates in the UK as a branch of GÉANT Vereniging. Registered office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands. UK branch address: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK. -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Michael Still Sent: 17 August 2018 14:06 To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Network automation vs. manual config Side note on apply groups and display inheritance. I've submitted a Juniper ER for an enhancement to have the ability to have ' | display inheritance' a 'default' cli behavior (configurable via 'set cli display-inheritance' option that is defaulted to off). I've also asked for a login-class option to enable this for specific user role such as front line NOC users who may benefit from having it on by default. This is ER-077163 if you want to poke your Juniper SE about it. The reason I've asked for this is specifically because I've seen NOC personnel spend many cycles investigating an issue not realizing that particular hidden apply-group config was affecting their investigation. I
Re: [j-nsp] L3VPN/RR/PE on Same router
> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Friday, August 17, 2018 2:38 PM > To: Mark Tinka > Cc: adamv0...@netconsultings.com; tim tiriche; Juniper List > Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > > Hey Mark, > > > > Yes a good practice is to separate internet routes from > > > internal/services l3vpn routes onto separate BGP control planes > > > (different sessions at least) so that malformed bgp msg will affect > > > just one part of your overall BGP infrastructure. > > > > I see you've been giving this advice for quite some time now. > > I'm siding with Adam here. His disaster scenario actually happed to me in > 3292. We ran for years VXR VPN route-reflectors, after we changed them to > MX240 we added lot more RR's, with some hard justifications to > management why we need more when we've had no trouble with the count > we had. > After about 3 months of running MX240 reflectors, we got bad BGP UPDATE > and crashed each reflector, which was unprecedented outage in the history > of the network. And tough to explain to management, considering we just > had made the reflection more redundant with some significant investment. > I'm sure they believed we just had cocked it up, as people don't really > believe in chance/randomness, evident how people justify that things can't > be broken, by explaining how in previous moment in time it wasn't broken, > implying that transitioning from non-broken to broken is impossible. > > Note, this is not to trash on Juniper, all vendors have bad BGP > implementations and I'm sure one can fuzz any of them to find crash bugs. > Oh yeah for sure, the XR RRs too were crashing upon reception of malformed BGP updates in the past. Currently XR BGP is *somewhat protected by the "BGP Attribute Filter and Enhanced Attribute Error Handling" (now RFC 7606) which already proved itself to me (just got a log msg informing me the malformed attribute was deleted instead of an important transit session reset). Unfortunately can't enable it on junos as the code we run would instead of session reset crashed the rpd due to a bug if the RFC 7606 feature would be enabled. *But still I'd be haunted by what could happen if RFC 7606 would have missed something and that thing would then crash BGP on RRs, can't afford that happening. > Not only is it CAPEX irrelevant to have separate RR for IPv4 and IPv6, but you > also get faster convergence, as more CPU cycles, fewer BGP neighbours, less > routes. I view it as cheap insurance as well as very simple horizontal > scaling. > And going virtual this really is a marginal spend in the grand scheme of things. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
> From: Robert Raszuk [mailto:rob...@raszuk.net] > Sent: Friday, August 17, 2018 9:57 AM > To: Mark Tinka > Cc: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net; cisco- > n...@puck.nether.net > Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > > Hey Mark, > > It has been a while > > > We've been running all address families on the same RR's (different > > sessions, obviously, but same hardware) > > Out of pure curiosity how are you setting up different BGP sessions to the > same RR ? > > I think what Adam is proposing is real TCP session isolation, what you may be > doing is just same single TCP session, but different SAFIs which is not the > same. > Yes Robert, I was indeed proposing separate TCP sessions at least -as that's the only way to protect against the default behaviour of terminating session upon malformed bgp update reception. > Sure you can configure parallel iBGP sessions on the TCP level say between > different loopback addresses to the same RR, but what would that really buy > you ? You could even be more brave and use BGP multisession code path (if > happens to be even supported by your vendor) which in most > implementations I have seen is full of holes like swiss cheese but is this > what > you are doing ? > Another alternative would be to spin up a separate BGP process, which I think is supported only in XR, but once again that somewhat places one on the outskirts of the common deployment graph. But I know Mark is using csr1k -so depending on the available NFVI resources (I guess dedicated servers in this case), I think it's not that onerous to spin up yet another VM right? adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
Hey Mark, > > Yes a good practice is to separate internet routes from internal/services > > l3vpn routes onto separate BGP control planes (different sessions at least) > > so that malformed bgp msg will affect just one part of your overall BGP > > infrastructure. > > I see you've been giving this advice for quite some time now. I'm siding with Adam here. His disaster scenario actually happed to me in 3292. We ran for years VXR VPN route-reflectors, after we changed them to MX240 we added lot more RR's, with some hard justifications to management why we need more when we've had no trouble with the count we had. After about 3 months of running MX240 reflectors, we got bad BGP UPDATE and crashed each reflector, which was unprecedented outage in the history of the network. And tough to explain to management, considering we just had made the reflection more redundant with some significant investment. I'm sure they believed we just had cocked it up, as people don't really believe in chance/randomness, evident how people justify that things can't be broken, by explaining how in previous moment in time it wasn't broken, implying that transitioning from non-broken to broken is impossible. Note, this is not to trash on Juniper, all vendors have bad BGP implementations and I'm sure one can fuzz any of them to find crash bugs. Not only is it CAPEX irrelevant to have separate RR for IPv4 and IPv6, but you also get faster convergence, as more CPU cycles, fewer BGP neighbours, less routes. I view it as cheap insurance as well as very simple horizontal scaling. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
* tim tiriche [2018-08-16 16:40]: > Hello, > > I have a MPLS PE (L3VPN) router that is acting as full mesh iBGP within the > US. The other routers in the US are not RR and regular iBGP. This router > also acts as RR for Europe and takes in full BGP table. Is there some > caveats to watch out for? You will run into problems if you try to have a Hub-and-Spoke L3VPN with a downstream hub on the PE. Routes do not get advertised because they already got exported from one routing table to another. Or how Juniper states it in: https://www.juniper.net/documentation/en_US/junos/topics/example/bgp-vpn-session-flap-prevention.html "The route export is not performed if the route in instance.inet.0 is a secondary route. In Junos OS, a route is only exported one time from one routing table as a primary route to another routing table as a secondary route. " Same when you enable the "advertise-from-main-vpn-tables" knob in global bgp config. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network automation vs. manual config
Side note on apply groups and display inheritance. I've submitted a Juniper ER for an enhancement to have the ability to have ' | display inheritance' a 'default' cli behavior (configurable via 'set cli display-inheritance' option that is defaulted to off). I've also asked for a login-class option to enable this for specific user role such as front line NOC users who may benefit from having it on by default. This is ER-077163 if you want to poke your Juniper SE about it. The reason I've asked for this is specifically because I've seen NOC personnel spend many cycles investigating an issue not realizing that particular hidden apply-group config was affecting their investigation. I have a couple other semi-related (to automation / configuration enhancement) ER's going if folks are interested and would like to chat about those directly. On Fri, Aug 17, 2018 at 8:20 AM Nathan Ward wrote: > > > On 17/08/2018, at 10:54 PM, Antti Ristimäki > wrote: > > > > Another option is to apply the auto-generated configuration via > apply-groups and apply all manual configurations explicitly so that the > automatic and manual configurations merge with each other. The positive > side of this approach is that it makes easy to develop the automation tools > so that manual configs are not overridden by auto-generated config, but I > personally see somewhat inconvenient that one really doesn't see the > effective running-config when using apply-groups, unless one remembers to > display inheritance. > > We’ve implemented this at a network I support, seems to be going well. We > approach it slightly differently though, in a way which may help solve your > usability problem, in a bit of a roundabout way. In short, we build groups > in to almost everything so people are used to doing display inheritance if > they need to look deeper at things. It’s not perfect, but it’s the best way > I’ve found to manage large bits of JunOS config. > > We have 3 types of groups: > Global* - common on every router they exist on, applied at top level only > Local* - unique to this router, applied at any level > * - common on every router they exist on, applied at any level > > All our groups have apply-flags omit; > > Local* groups are only used when something is re-used several times on the > one router - for example on our BNGs, a list of DHCP interfaces in each of > the routing-instances we might push a subscriber in to. > > So, for example: > - GlobalDualREMX sets up whatever our standard things are for an MX with > 2 REs, applied at top level. > - “MPLS" is applied at `interfaces blah` and `protocols rsvp interface > blah`, etc and includes our per-interface MPLS config. > - VRFCustomers includes our import/export policies for our Customers VRF > (applied inside a routing-instance), and the loopback filter config for the > Customers VRF loopback (applied inside an interface). > > The only config that’s outside groups is config unique to that router - > so, IP addressing, routing-instance names and RDs, interfaces (though they > have apply-groups within them for many settings), hostname, etc. > > This means: > 1) Config is short because of apply-flags omit. Seeing things unique to > this router is easy. It’s easy to spot differences as apply-groups are > different - and that’s all you generally need to look for. I just looked, > our BNGs are all about 500 lines of config, and all have identical group > config on them. Most of the config is rsvp-te tunnels, and access network > interfaces. > 2) When we want to look deeper, we know to do `| display inheritance | > except #` and it becomes muscle memory - this really is the bit that helps > your use case, haha. > 3) We can copy our groups from a git repository, load replace (in our git > reply they all have replace tags) and commit. Keeping the common config > consistent is super easy. Automating this is one “leg” of automation and > solves almost all of our automation requirements. > 4) We can do bespoke mucking about outside the groups, and it’s obvious > what those things are, and what things need to be tidied up in to groups, > or what is junk temp config that needs to be thrown out. > > I think where this could work for you, is to have your automation apply > any router-specific config just like a human would - outside the groups, > but leveraging the groups as much as possible. If you want to keep your > manual/automated config seperate, stick the automated config in a big > single group - that way, manual config will override it, and it’ll be very > clear that it’s there and where it’s come from. > > -- > Nathan Ward > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- [stillwa...@gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwa...@gmail.com ~]$ ___ juniper-nsp mailing list
Re: [j-nsp] Network automation vs. manual config
> On 17/08/2018, at 10:54 PM, Antti Ristimäki wrote: > > Another option is to apply the auto-generated configuration via apply-groups > and apply all manual configurations explicitly so that the automatic and > manual configurations merge with each other. The positive side of this > approach is that it makes easy to develop the automation tools so that manual > configs are not overridden by auto-generated config, but I personally see > somewhat inconvenient that one really doesn't see the effective > running-config when using apply-groups, unless one remembers to display > inheritance. We’ve implemented this at a network I support, seems to be going well. We approach it slightly differently though, in a way which may help solve your usability problem, in a bit of a roundabout way. In short, we build groups in to almost everything so people are used to doing display inheritance if they need to look deeper at things. It’s not perfect, but it’s the best way I’ve found to manage large bits of JunOS config. We have 3 types of groups: Global* - common on every router they exist on, applied at top level only Local* - unique to this router, applied at any level * - common on every router they exist on, applied at any level All our groups have apply-flags omit; Local* groups are only used when something is re-used several times on the one router - for example on our BNGs, a list of DHCP interfaces in each of the routing-instances we might push a subscriber in to. So, for example: - GlobalDualREMX sets up whatever our standard things are for an MX with 2 REs, applied at top level. - “MPLS" is applied at `interfaces blah` and `protocols rsvp interface blah`, etc and includes our per-interface MPLS config. - VRFCustomers includes our import/export policies for our Customers VRF (applied inside a routing-instance), and the loopback filter config for the Customers VRF loopback (applied inside an interface). The only config that’s outside groups is config unique to that router - so, IP addressing, routing-instance names and RDs, interfaces (though they have apply-groups within them for many settings), hostname, etc. This means: 1) Config is short because of apply-flags omit. Seeing things unique to this router is easy. It’s easy to spot differences as apply-groups are different - and that’s all you generally need to look for. I just looked, our BNGs are all about 500 lines of config, and all have identical group config on them. Most of the config is rsvp-te tunnels, and access network interfaces. 2) When we want to look deeper, we know to do `| display inheritance | except #` and it becomes muscle memory - this really is the bit that helps your use case, haha. 3) We can copy our groups from a git repository, load replace (in our git reply they all have replace tags) and commit. Keeping the common config consistent is super easy. Automating this is one “leg” of automation and solves almost all of our automation requirements. 4) We can do bespoke mucking about outside the groups, and it’s obvious what those things are, and what things need to be tidied up in to groups, or what is junk temp config that needs to be thrown out. I think where this could work for you, is to have your automation apply any router-specific config just like a human would - outside the groups, but leveraging the groups as much as possible. If you want to keep your manual/automated config seperate, stick the automated config in a big single group - that way, manual config will override it, and it’ll be very clear that it’s there and where it’s come from. -- Nathan Ward ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multicast duplicated on LAG with link-protection
Hello Chuck, Thank you for your answer. I didn't know about this option. Looking into the documentation, seems that this will do just what we need. We will test it with our customer. Thank you! Best regards. -Mensaje original- De: Chuck Anderson Enviado el: viernes, 17 de agosto de 2018 13:31 Para: Javier Valero CC: juniper-nsp@puck.nether.net Asunto: Re: [j-nsp] Multicast duplicated on LAG with link-protection Instead of LAG you can try RTG, redundant-trunk-group. That would block ingress and egress traffic on the backup link and not require STP. On Fri, Aug 17, 2018 at 11:20:24AM +, Javier Valero wrote: > Hello all, > > We are facing a problem with one customer and multicast video streams on a > link aggregation. > Maybe someone in the list know this behaviour and how to solve it. > > We have EX4550 (VC) switches on different sites. We transport our customer > traffic over all our sites with a SVLAN assigned for them (QinQ) and give > them multiple access points in different places. > In their service, they transmit some video streams with multicast, to all > their sites. (IPTV) > > In one place, we connect with the customer with two 10G ports, each one from > a different equipment in our side (geographically), for redundancy. > In their side it is only one equipment (also an EX4550). > > We cannot configure a link aggregation in our side, as they are different > equipments. MC-LAG is not supported by EX4550. > But our customer can configure a link aggregation in link-protection mode. By > this way, the avoid the use of STP for loop prevention. > In link-protection mode, the backup interface stays in standby mode, without > egress traffic, but allowing ingress traffic. > > The problem is the multicast traffic. As it is distributed over all the > links, we send the traffic on both 10G interfaces. > The problem is that the backup interface of the link-proteccion is also > accepting the multicast traffic, so in the customer equipment, they have the > multicast duplicated. > > This is causing problems on the customer side. > > We don't know if the LAG is a good solution for this case, or we should tell > our customer that use STP. > Maybe it is as simple as some configuration option that we don't know, or any > filter that can be applicated only on the interface not active. > > Someone have any idea how to solve this? > > Thank you very much in advance. > > Best regards. > Javier Valero. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network automation vs. manual config
On Fri, Aug 17, 2018 at 07:45:12AM -0400, Jason Lixfeld wrote: > Maybe I’m missing an implied exception, but every once in a while one > needs to make some sort of manual configuration to resolve a time > sensitive some corner case that the provisioning system doesn’t > support because someone external to you (ie: customer, IXP > participant) changed something. How is that handled in this use case? Yes, one should create a mechanism that somewhere in the pipeline you can override configuration the system generated. We call these overrides 'hacks'. We track hacks in a version controlled repository, and I'd like to suggest they should be used sparingly. Kind regards, Job ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network automation vs. manual config
Dear Antti, On Fri, Aug 17, 2018 at 01:54:27PM +0300, Antti Ristimäki wrote: > This is something that I've been thinking quite a lot, so I would be > delighted to hear some comments, experiences or recommendations. > > So, now that more and more of us are automating their network, there > will be the question about how to manage the configurations, if they > are partially automated and partially manually maintained. This will > be the case especially while transitioning from a pure CLI jockey > network towards a more automated one. There are probably multiple > approaches to solve this, but below are a few of them: > > One option is to generate the whole config automatically e.g. from a > template or a database and just _not_accepting_ any manual > configurations at all. Then when there are needs to do something > custom not yet supported by the automation tools, instead of manually > configuring it one would take some additional time and build the > support into the automation tools. The cost for this might be that > deploying something new/custom/tailor-made might take a bit more time > compared to just manually configuring it, but in a long run the > benefits are obvious. I'm personally preferring this approach. > > Generating the _whole_ configuration automatically off-line from the > scratch makes it also easy to remove elements from the configuration, > as the auto-generated config can completely replace the existing > running-config. The above paragraph is in a nutshell how NTT's AS 2914 network operates. I can strongly recommend the approach. A presentation is available here: https://ripe69.ripe.net/wp-content/uploads/presentations/29-201411-ripe.pdf https://ripe69.ripe.net/archives/video/178/ Kind regards, Job ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network automation vs. manual config
I’ll admit that I haven’t done much automation yet, so take this with a grain of salt and provide clue where required... > On Aug 17, 2018, at 6:54 AM, Antti Ristimäki wrote: > > Hi colleagues, > > This is something that I've been thinking quite a lot, so I would be > delighted to hear some comments, experiences or recommendations. > > So, now that more and more of us are automating their network, there will be > the question about how to manage the configurations, if they are partially > automated and partially manually maintained. This will be the case especially > while transitioning from a pure CLI jockey network towards a more automated > one. There are probably multiple approaches to solve this, but below are a > few of them: > > One option is to generate the whole config automatically e.g. from a template > or a database and just _not_accepting_ any manual configurations at all. Then > when there are needs to do something custom not yet supported by the > automation tools, instead of manually configuring it one would take some > additional time and build the support into the automation tools. The cost for > this might be that deploying something new/custom/tailor-made might take a > bit more time compared to just manually configuring it, but in a long run the > benefits are obvious. I'm personally preferring this approach. > > Generating the _whole_ configuration automatically off-line from the scratch > makes it also easy to remove elements from the configuration, as the > auto-generated config can completely replace the existing running-config. Maybe I’m missing an implied exception, but every once in a while one needs to make some sort of manual configuration to resolve a time sensitive some corner case that the provisioning system doesn’t support because someone external to you (ie: customer, IXP participant) changed something. How is that handled in this use case? > If the above mentioned is not doable for the entire configuration, one can > take one configuration hierarchy level at a time and automate it, after which > no manual configurations will be accepted under that hierarchy. This is > rather trivial especially for those configuration hierarchies that tend to be > static most of the time. > > Another option is to apply the auto-generated configuration via apply-groups > and apply all manual configurations explicitly so that the automatic and > manual configurations merge with each other. The positive side of this > approach is that it makes easy to develop the automation tools so that manual > configs are not overridden by auto-generated config, but I personally see > somewhat inconvenient that one really doesn't see the effective > running-config when using apply-groups, unless one remembers to display > inheritance. > > Any thoughts appreciated. I tend to agree with you in that apply-groups can make things really hard to follow and make the config explode in size when you try to display inheritance. So maybe it makes sense at this point to just ignore the CLI all together? If you have a tool that is going to write your configs with apply-groups our whatever, it can probably display that configuration in whatever format you want so the CLI becomes somewhat obsolete for config review. And, if you have all that in place, I’m sure this display interface can, and would likely be a single pane of glass for all of your configurations. It would display anything you throw at it in exactly the same format, no matter what sort of device it’s for. I can certainly see the value in that. > Antti > ___ > 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] Multicast duplicated on LAG with link-protection
Instead of LAG you can try RTG, redundant-trunk-group. That would block ingress and egress traffic on the backup link and not require STP. On Fri, Aug 17, 2018 at 11:20:24AM +, Javier Valero wrote: > Hello all, > > We are facing a problem with one customer and multicast video streams on a > link aggregation. > Maybe someone in the list know this behaviour and how to solve it. > > We have EX4550 (VC) switches on different sites. We transport our customer > traffic over all our sites with a SVLAN assigned for them (QinQ) and give > them multiple access points in different places. > In their service, they transmit some video streams with multicast, to all > their sites. (IPTV) > > In one place, we connect with the customer with two 10G ports, each one from > a different equipment in our side (geographically), for redundancy. > In their side it is only one equipment (also an EX4550). > > We cannot configure a link aggregation in our side, as they are different > equipments. MC-LAG is not supported by EX4550. > But our customer can configure a link aggregation in link-protection mode. By > this way, the avoid the use of STP for loop prevention. > In link-protection mode, the backup interface stays in standby mode, without > egress traffic, but allowing ingress traffic. > > The problem is the multicast traffic. As it is distributed over all the > links, we send the traffic on both 10G interfaces. > The problem is that the backup interface of the link-proteccion is also > accepting the multicast traffic, so in the customer equipment, they have the > multicast duplicated. > > This is causing problems on the customer side. > > We don't know if the LAG is a good solution for this case, or we should tell > our customer that use STP. > Maybe it is as simple as some configuration option that we don't know, or any > filter that can be applicated only on the interface not active. > > Someone have any idea how to solve this? > > Thank you very much in advance. > > Best regards. > Javier Valero. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Multicast duplicated on LAG with link-protection
Hello all, We are facing a problem with one customer and multicast video streams on a link aggregation. Maybe someone in the list know this behaviour and how to solve it. We have EX4550 (VC) switches on different sites. We transport our customer traffic over all our sites with a SVLAN assigned for them (QinQ) and give them multiple access points in different places. In their service, they transmit some video streams with multicast, to all their sites. (IPTV) In one place, we connect with the customer with two 10G ports, each one from a different equipment in our side (geographically), for redundancy. In their side it is only one equipment (also an EX4550). We cannot configure a link aggregation in our side, as they are different equipments. MC-LAG is not supported by EX4550. But our customer can configure a link aggregation in link-protection mode. By this way, the avoid the use of STP for loop prevention. In link-protection mode, the backup interface stays in standby mode, without egress traffic, but allowing ingress traffic. The problem is the multicast traffic. As it is distributed over all the links, we send the traffic on both 10G interfaces. The problem is that the backup interface of the link-proteccion is also accepting the multicast traffic, so in the customer equipment, they have the multicast duplicated. This is causing problems on the customer side. We don't know if the LAG is a good solution for this case, or we should tell our customer that use STP. Maybe it is as simple as some configuration option that we don't know, or any filter that can be applicated only on the interface not active. Someone have any idea how to solve this? Thank you very much in advance. Best regards. Javier Valero. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Network automation vs. manual config
Hi colleagues, This is something that I've been thinking quite a lot, so I would be delighted to hear some comments, experiences or recommendations. So, now that more and more of us are automating their network, there will be the question about how to manage the configurations, if they are partially automated and partially manually maintained. This will be the case especially while transitioning from a pure CLI jockey network towards a more automated one. There are probably multiple approaches to solve this, but below are a few of them: One option is to generate the whole config automatically e.g. from a template or a database and just _not_accepting_ any manual configurations at all. Then when there are needs to do something custom not yet supported by the automation tools, instead of manually configuring it one would take some additional time and build the support into the automation tools. The cost for this might be that deploying something new/custom/tailor-made might take a bit more time compared to just manually configuring it, but in a long run the benefits are obvious. I'm personally preferring this approach. Generating the _whole_ configuration automatically off-line from the scratch makes it also easy to remove elements from the configuration, as the auto-generated config can completely replace the existing running-config. If the above mentioned is not doable for the entire configuration, one can take one configuration hierarchy level at a time and automate it, after which no manual configurations will be accepted under that hierarchy. This is rather trivial especially for those configuration hierarchies that tend to be static most of the time. Another option is to apply the auto-generated configuration via apply-groups and apply all manual configurations explicitly so that the automatic and manual configurations merge with each other. The positive side of this approach is that it makes easy to develop the automation tools so that manual configs are not overridden by auto-generated config, but I personally see somewhat inconvenient that one really doesn't see the effective running-config when using apply-groups, unless one remembers to display inheritance. Any thoughts appreciated. Antti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
Just to clarify ... I was not really worried about how to follow various lists - mail client does a good job to combine them into one folder, filter duplicates etc ... But when writing general reply/question to Mark today about BGP sessions I noticed it only had j-nsp - but oh the question is general so where do I post ? I added c-nsp ... that was the trigger for the above comment. On a similar note I would love to hear comments from all of the members on what linux tools they use to test pps on the routers ... which list should I post it to ? Cheers R. On Fri, Aug 17, 2018 at 12:06 PM, wrote: > > PS. Have not been reading -nsp aliases for a while, but now I see that I > > missed a lot ! Btw do we really need per vendor aliases here ? Wouldn't > it > > be much easier to just have single nsp list ? After all we all most > likely > > have all of the vendors in our networks (including Nokia !) and we are > all > > likely reading all the lists :) Or maybe there is one already ? > > Disagree. I follow several of the -nsp lists, but some of them much > more closely than others. Having them all mixed up would definitely > make this more difficult. > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
> PS. Have not been reading -nsp aliases for a while, but now I see that I > missed a lot ! Btw do we really need per vendor aliases here ? Wouldn't it > be much easier to just have single nsp list ? After all we all most likely > have all of the vendors in our networks (including Nokia !) and we are all > likely reading all the lists :) Or maybe there is one already ? Disagree. I follow several of the -nsp lists, but some of them much more closely than others. Having them all mixed up would definitely make this more difficult. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
On 17/Aug/18 10:56, Robert Raszuk wrote: > Hey Mark, > > It has been a while It has, mate. Good to see you in these parts again :-)... > > Out of pure curiosity how are you setting up different BGP sessions to > the same RR ? > > I think what Adam is proposing is real TCP session isolation, what you > may be doing is just same single TCP session, but different SAFIs > which is not the same. You're right; I should have clarified that better - we are, indeed, running one TCP session with multiple SAFI's. The only uniqueness between BGP sessions at a TCP level would be by IP protocol, i.e., IPv4 and IPv6. But even within IPv6, we carry multiple SAFI's across a single TCP session. > > Sure you can configure parallel iBGP sessions on the TCP level say > between different loopback addresses to the same RR, but what would > that really buy you ? You could even be more brave and use BGP > multisession code path (if happens to be even supported by your > vendor) which in most implementations I have seen is full of holes > like swiss cheese but is this what you are doing ? I'm not that brave :-). But to your point, the complete hardware and Layer 4 separation of BGP sessions, perhaps going one step further and having separate planes for different SAFI's, is overkill, IMHO. But that's just me. As I mentioned before, we've had our setup since 2014. With the exception of x86 hardware being more sensitive to temperature situations, causing related failures, we haven't had any issues at all. > PS. Have not been reading -nsp aliases for a while, but now I see > that I missed a lot ! Btw do we really need per vendor aliases here ? > Wouldn't it be much easier to just have single nsp list ? After all we > all most likely have all of the vendors in our networks (including > Nokia !) and we are all likely reading all the lists :) Or maybe there > is one already ? There isn't one to rule them all, AFAIK. In fact, Arista-NSP went live just yesterday, if I'm not mistaken :-). I think there is value in having separate lists for the different vendors. I wouldn't say all network operators have each of them to make one list the ideal. Besides, there are a lot of things I have zero interest in on one list that I wish I could filter out (SRX on j-nsp, ASA on c-nsp, as examples). You can imagine what that'd be like on a single list :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
Hey Mark, It has been a while > We've been running all address families on the same RR's (different > sessions, obviously, but same hardware) Out of pure curiosity how are you setting up different BGP sessions to the same RR ? I think what Adam is proposing is real TCP session isolation, what you may be doing is just same single TCP session, but different SAFIs which is not the same. Sure you can configure parallel iBGP sessions on the TCP level say between different loopback addresses to the same RR, but what would that really buy you ? You could even be more brave and use BGP multisession code path (if happens to be even supported by your vendor) which in most implementations I have seen is full of holes like swiss cheese but is this what you are doing ? Cheers, R,. PS. Have not been reading -nsp aliases for a while, but now I see that I missed a lot ! Btw do we really need per vendor aliases here ? Wouldn't it be much easier to just have single nsp list ? After all we all most likely have all of the vendors in our networks (including Nokia !) and we are all likely reading all the lists :) Or maybe there is one already ? On Fri, Aug 17, 2018 at 7:06 AM, Mark Tinka wrote: > > > On 16/Aug/18 17:15, adamv0...@netconsultings.com wrote: > > > Yes a good practice is to separate internet routes from internal/services > > l3vpn routes onto separate BGP control planes (different sessions at > least) > > so that malformed bgp msg will affect just one part of your overall BGP > > infrastructure. > > I see you've been giving this advice for quite some time now. > > We've been running all address families on the same RR's (different > sessions, obviously, but same hardware) for almost 5 years. The only > reason sessions have gone down is due to hardware problems. It didn't > disrupt services because there are always 2 RR's, but we haven't seen an > outage due to protocol problems in one address family spilling over into > other address families. > > Of course, I see your concern, but from our own experience over several > years, I've not seen this issue. > > I mention this because introducing this kind of separation is onerous. > > 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
