Re: [j-nsp] 'Juniper BGP issues causing locallized Internet Problems, (Mon, Nov 7th)?
On 11/7/11 17:58 , Jared Mauch wrote: Juniper doesn't believe security bugs should be public. You must be a customer with support to access their portal. Cisco has a good policy. You can view any security bugs and get fixes regardless of your contract status. In either case there are a rather complex set of dependencies and caveats associated with available releases, and the risk and timing of an upgrade has to be balanced against operational needs, customer scedures, feature requests and platforms involved. If we rolled a new release everytime juniper sent us a notification or found a pr for a bug we tripped over we'd be rolling probably twice a month which is probably not sustainable. same applies to other vendors we have in the mix. Jared Mauch On Nov 7, 2011, at 6:53 PM, Jack Bates jba...@brightok.net wrote: More importantly, if it was the issue dated in August, how in the heck do I get on a list which tells me such a critical bug exists? Jack On 11/7/2011 2:03 PM, Krembs, Jesse wrote: Has anyone else seen this issue? 'Juniper BGP issues causing locallized Internet Problems, (Mon, Nov 7th) http://isc.sans.edu/diary.html?storyid=11965rss via SANS Internet Storm Center, InfoCON: greenhttp://isc.sans.edu on 11/7/11 We're starting to get reports (thanks to both Branson and Darryl) that a Juniper OS bug with BGP, combined with some specific BGP updates today, are resulting in some key internet routers being DOS'd due to high CPU loads. We'll post more data as it comes in. === Rob VandenBrink Metafore (c) SANS Internet Storm Center. http://isc.sans.edu http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License. Jesse Krembs - Data Network Architecture Planning FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT 05403 | jkre...@fairpoint.commailto:jkre...@fairpoint.com www.FairPoint.comhttp://www.fairpoint.com/ | 802.951.1519 office | 802.735.4886 cell ___ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] syslog for VPLS VC.
Hello experts is there anyway to get syslog message when VPLS VC is up? now i can see VC down message only. thanks *Soongoon Lee** /** CCIE #17724* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Observing error: device vlan not found
Hello Experts, During the configuration for vlan and vlan l3-interfaces we observed error: device vlan not found. Following is configuration which i did on MX80 (11.2R3): interfaces { ge-0/0/0 { unit 0 { family bridge { interface-mode access; vlan-id 601; } } vlan { unit 601 { family inet { no-redirects; address 10.20.21.22/24 { } } } } } bridge-domains { default { description default; domain-type bridge; vlan-id 1; } vlan-601 { domain-type bridge; vlan-id 601; } } we are getting: show interfaces vlan error: device vlan not found Please let me know if this is not supported or there is any other reason. Aside, during a test with irb interfaces everything is working fine. Thanks in advance!!! Regards, Sunny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Observing error: device vlan not found
arent you missing the interface in your bridge-domain ? On 11 November 2011 11:46, saurabh sood saurabh...@gmail.com wrote: Hello Experts, During the configuration for vlan and vlan l3-interfaces we observed error: device vlan not found. Following is configuration which i did on MX80 (11.2R3): interfaces { ge-0/0/0 { unit 0 { family bridge { interface-mode access; vlan-id 601; } } vlan { unit 601 { family inet { no-redirects; address 10.20.21.22/24 { } } } } } bridge-domains { default { description default; domain-type bridge; vlan-id 1; } vlan-601 { domain-type bridge; vlan-id 601; } } we are getting: show interfaces vlan error: device vlan not found Please let me know if this is not supported or there is any other reason. Aside, during a test with irb interfaces everything is working fine. Thanks in advance!!! Regards, Sunny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Observing error: device vlan not found
When using the new-style MX L2 commands, the bridge-domains do not require you to add the interface. However you need to use the bridge-domains knob routing-interface to point to the irb interface. Also on the MX you need to create interface irb.601 and not vlan.601 Thank you, -- Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875 Sr. Systems Engineer Juniper Networks On 11/11/11 5:01 AM, Humair Ali humair.s@gmail.com wrote: arent you missing the interface in your bridge-domain ? On 11 November 2011 11:46, saurabh sood saurabh...@gmail.com wrote: Hello Experts, During the configuration for vlan and vlan l3-interfaces we observed error: device vlan not found. Following is configuration which i did on MX80 (11.2R3): interfaces { ge-0/0/0 { unit 0 { family bridge { interface-mode access; vlan-id 601; } } vlan { unit 601 { family inet { no-redirects; address 10.20.21.22/24 { } } } } } bridge-domains { default { description default; domain-type bridge; vlan-id 1; } vlan-601 { domain-type bridge; vlan-id 601; } } we are getting: show interfaces vlan error: device vlan not found Please let me know if this is not supported or there is any other reason. Aside, during a test with irb interfaces everything is working fine. Thanks in advance!!! Regards, Sunny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ 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] Practical VPLS examples (SRX and J series)
So today I created a mesh of L2VPNs interconnecting virtual-routers on 5 SRX650s and J6350s. I did the 3 650s as a trial, then added 2 J6350s later because, well, I could. Configuring a triangle of RSVP-signalled paths, BGP neighbours, and logical tunnels, wasn't too bad. Adding 2 more points made it almost maddeningly confusing. We'll be adding more sites sooner-or-later too, and my brain is unlikely to cope with anymore sites increasing the mesh exponentially. So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. Could some kind gentle person provide a practical example of VPLS in action, for the hard of thinking please? In simple terms we have 5 devices directly connected to each other (full mesh), and all 5 will have a CE (virtual-router) connected to it via ethernet logical tunnels. Thanks! Currently I'm doing something like this (snipped for berevity); # show routing-instances vr-l2vpn instance-type l2vpn; interface lt-0/0/0.5036; interface lt-0/0/0.5077; interface lt-0/0/0.5135; interface lt-0/0/0.5136; route-distinguisher 500:5034; vrf-target target:500:500; protocols { l2vpn { encapsulation-type ethernet; site fsed { site-identifier 34; interface lt-0/0/0.5036 { remote-site-id 2; } interface lt-0/0/0.5077 { remote-site-id 33; } interface lt-0/0/0.5135 { remote-site-id 101; } interface lt-0/0/0.5136 { remote-site-id 102; } } } } # show interfaces lt-0/0/0 unit 135 { encapsulation ethernet; peer-unit 5135; family inet{ address 10.200.135.35/24; } } unit 5135 { encapsulation ethernet-ccc; peer-unit 135; family ccc { filter { input packet-mode-ccc; } } } # show protocols mpls path-mtu { rsvp mtu-signaling; } label-switched-path fsed-rmdcjs1 { from a.b.c.d; to w.x.y.z; bandwidth 90m; no-cspf; fast-reroute; primary fsed-rmdcjs1; } path fsed-rmdcjs1 { e.f.g.h strict; } -- Mike Williams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Practical VPLS examples (SRX and J series)
On 11/11/2011 11:42 AM, Mike Williams wrote: So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. I believe this is because of the BGP auto-detection of sites. My guess is the logic actually runs up the numbers to range, so defining it to something reasonable speeds up the setup process. I'm still waiting on power for my lab to test vpls w/ BGP signalling, as it might screw up my production network and I'd like to see if I can shift to l2 signaling without dropping the peers. :) Jack ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Practical VPLS examples (SRX and J series)
In Juniper's BGP-based VPLS, you do not need to create pseudowires in-between the VPLS instances. As long as you have one master LSP (usuallyan RSVP one) in-between two PEs, BGP will then (by detecting which VPLS instance is announced from which device), automatically build an inner tunnel between the PEs to echange the VPLS traffic. In order to have this work automatically, we need to reserve a series of 'inner labels' (effectively) which can be used to differentiate sites and VPLS instances. (so when PE#1 sends traffic to PE#2, the latter devvice knows which VPLS domain it should go into). Contrast this with LDP-based VPLS, which requires manually configuring each neighbour in the VPLS domain by hand. - Chris. On 2011-11-12, at 7:01 AM, Jack Bates wrote: On 11/11/2011 11:42 AM, Mike Williams wrote: So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. I believe this is because of the BGP auto-detection of sites. My guess is the logic actually runs up the numbers to range, so defining it to something reasonable speeds up the setup process. I'm still waiting on power for my lab to test vpls w/ BGP signalling, as it might screw up my production network and I'd like to see if I can shift to l2 signaling without dropping the peers. :) Jack ___ 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] Practical VPLS examples (SRX and J series)
We use both LDP- and BGP-signalled in our environment, with LDP-signalled providing somewhat of a 'poor-man's hub and spoke'. The spokes are configured to only build pseudowires to the hub, and the hub builds back to all spokesworks for our particular use case. Anyhow, BGP signalled.as Chris K mentioned, BGP signalling alleviates the need to explicitly configure the IPs of your other endpoint PEs in the VPLS. Instead, BGP advertises a site's route info out with the VPLS's VRF target stuck on it, causing any other remote sites also configured with that VRF target # to import them automatically and learn about each other (simplistically). Tends to scale better than LDP-signalled for that reason, and in large networks, because of the number of pseudowires required for LDP-signalled VPLS. It seems to me some BGP autodiscovery options may have recently been added to LDP-signalled VPLS, but I haven't explored them. Downside of both versus what you're doing now? With VPLS, you learn MACs, so scale accordingly for your platform, though it sounds like your CEs with be routers, so no biggy. The site-range value must be at least as large as the number of sites you have in the VPLS. So, if you pick 6 for the site range, you can have 6 sites in itbut, those site-ids must be numbered 1-6. Alternatively, you could use 100 as your site-range, and as long as no site ID is larger than 100, you're good. We tend to leave a bit of room in the site-range value to allow for customer expansion. I'm almost certainly missing something in this config as I'm not staring at a real one, but it should be close. Doesn't use tunnel interfaces, but you get the drift. [edit routing-instances] myvpls { instance-type vpls; interface ge-1/2/3.4; route-distinguisher x.x.x.x:yy; vrf-target target:yourASN:uniqueCustIdentNum; protocols vpls { encapsulation [ethernet|ethernet-vlan]; no-tunnel-services; site-range 6; site siteNameHere { site-identifier 1; interface ge-1/2/3.4; } } } [edit interfaces ge-1/2/3] flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 4 { encapsulation vlan-vpls; vlan-id 4; } HTH, David On 11 November 2011 10:42, Mike Williams mike.willi...@comodo.com wrote: So today I created a mesh of L2VPNs interconnecting virtual-routers on 5 SRX650s and J6350s. I did the 3 650s as a trial, then added 2 J6350s later because, well, I could. Configuring a triangle of RSVP-signalled paths, BGP neighbours, and logical tunnels, wasn't too bad. Adding 2 more points made it almost maddeningly confusing. We'll be adding more sites sooner-or-later too, and my brain is unlikely to cope with anymore sites increasing the mesh exponentially. So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. Could some kind gentle person provide a practical example of VPLS in action, for the hard of thinking please? In simple terms we have 5 devices directly connected to each other (full mesh), and all 5 will have a CE (virtual-router) connected to it via ethernet logical tunnels. Thanks! Currently I'm doing something like this (snipped for berevity); # show routing-instances vr-l2vpn instance-type l2vpn; interface lt-0/0/0.5036; interface lt-0/0/0.5077; interface lt-0/0/0.5135; interface lt-0/0/0.5136; route-distinguisher 500:5034; vrf-target target:500:500; protocols { l2vpn { encapsulation-type ethernet; site fsed { site-identifier 34; interface lt-0/0/0.5036 { remote-site-id 2; } interface lt-0/0/0.5077 { remote-site-id 33; } interface lt-0/0/0.5135 { remote-site-id 101; } interface lt-0/0/0.5136 { remote-site-id 102; } } } } # show interfaces lt-0/0/0 unit 135 { encapsulation ethernet; peer-unit 5135; family inet{ address 10.200.135.35/24; } } unit 5135 { encapsulation ethernet-ccc; peer-unit 135; family ccc { filter { input packet-mode-ccc; } } } # show protocols mpls path-mtu { rsvp mtu-signaling; } label-switched-path fsed-rmdcjs1 { from a.b.c.d; to w.x.y.z; bandwidth 90m; no-cspf; fast-reroute; primary fsed-rmdcjs1; } path fsed-rmdcjs1 { e.f.g.h strict; } -- Mike Williams ___ 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
Re: [j-nsp] Practical VPLS examples (SRX and J series)
BTW, (although it's an offtopic quite a bit) let me ask if there is anyone here who ever deployed/mantined LDP VPLS + external BGP autodiscovery in real life for more or less large-scale network? How was it? Any gotchas worth to be aware of? 12.11.2011 6:47 пользователь David Ball davidtb...@gmail.com написал: We use both LDP- and BGP-signalled in our environment, with LDP-signalled providing somewhat of a 'poor-man's hub and spoke'. The spokes are configured to only build pseudowires to the hub, and the hub builds back to all spokesworks for our particular use case. Anyhow, BGP signalled.as Chris K mentioned, BGP signalling alleviates the need to explicitly configure the IPs of your other endpoint PEs in the VPLS. Instead, BGP advertises a site's route info out with the VPLS's VRF target stuck on it, causing any other remote sites also configured with that VRF target # to import them automatically and learn about each other (simplistically). Tends to scale better than LDP-signalled for that reason, and in large networks, because of the number of pseudowires required for LDP-signalled VPLS. It seems to me some BGP autodiscovery options may have recently been added to LDP-signalled VPLS, but I haven't explored them. Downside of both versus what you're doing now? With VPLS, you learn MACs, so scale accordingly for your platform, though it sounds like your CEs with be routers, so no biggy. The site-range value must be at least as large as the number of sites you have in the VPLS. So, if you pick 6 for the site range, you can have 6 sites in itbut, those site-ids must be numbered 1-6. Alternatively, you could use 100 as your site-range, and as long as no site ID is larger than 100, you're good. We tend to leave a bit of room in the site-range value to allow for customer expansion. I'm almost certainly missing something in this config as I'm not staring at a real one, but it should be close. Doesn't use tunnel interfaces, but you get the drift. [edit routing-instances] myvpls { instance-type vpls; interface ge-1/2/3.4; route-distinguisher x.x.x.x:yy; vrf-target target:yourASN:uniqueCustIdentNum; protocols vpls { encapsulation [ethernet|ethernet-vlan]; no-tunnel-services; site-range 6; site siteNameHere { site-identifier 1; interface ge-1/2/3.4; } } } [edit interfaces ge-1/2/3] flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 4 { encapsulation vlan-vpls; vlan-id 4; } HTH, David On 11 November 2011 10:42, Mike Williams mike.willi...@comodo.com wrote: So today I created a mesh of L2VPNs interconnecting virtual-routers on 5 SRX650s and J6350s. I did the 3 650s as a trial, then added 2 J6350s later because, well, I could. Configuring a triangle of RSVP-signalled paths, BGP neighbours, and logical tunnels, wasn't too bad. Adding 2 more points made it almost maddeningly confusing. We'll be adding more sites sooner-or-later too, and my brain is unlikely to cope with anymore sites increasing the mesh exponentially. So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. Could some kind gentle person provide a practical example of VPLS in action, for the hard of thinking please? In simple terms we have 5 devices directly connected to each other (full mesh), and all 5 will have a CE (virtual-router) connected to it via ethernet logical tunnels. Thanks! Currently I'm doing something like this (snipped for berevity); # show routing-instances vr-l2vpn instance-type l2vpn; interface lt-0/0/0.5036; interface lt-0/0/0.5077; interface lt-0/0/0.5135; interface lt-0/0/0.5136; route-distinguisher 500:5034; vrf-target target:500:500; protocols { l2vpn { encapsulation-type ethernet; site fsed { site-identifier 34; interface lt-0/0/0.5036 { remote-site-id 2; } interface lt-0/0/0.5077 { remote-site-id 33; } interface lt-0/0/0.5135 { remote-site-id 101; } interface lt-0/0/0.5136 { remote-site-id 102; } } } } # show interfaces lt-0/0/0 unit 135 { encapsulation ethernet; peer-unit 5135; family inet{ address 10.200.135.35/24; } } unit 5135 { encapsulation ethernet-ccc; peer-unit 135; family ccc { filter { input packet-mode-ccc; } } } # show protocols mpls path-mtu { rsvp mtu-signaling; } label-switched-path fsed-rmdcjs1 { from a.b.c.d; to w.x.y.z;