[j-nsp] JUNOS and MX Trio cards
For all those who were wondering about code stability for Trio cards, I have my first experience to report. We just got our first shipment of MPC2 cards, and tested it out in an MX960 running 10.2R1 with MPC2 cards only, no classic DPCs. When I went to commit the config of the very first routed port with a firewall filter (IMHO a fairly simple config, about a dozen terms, but making use of chained filters), the FPC the port was on promptly crashed. Every time the FPC would reboot and come back up, it would immediately crash again. Moving the interface config with the filter to a different FPC caused that FPC to crash as well. Disabling the firewall filter caused the crashing to stop. But, the box didn't fully recover on its own. Following the crash, some packets forwarded through that box were being blackholed. After doing a GRES/NSR switchover, the blackholing cleared briefly, but started again the exact instant the backup RE came back online. I tried disabling the GRES/NSR config, but the blackholing still didn't go away. A complete PFE restart was required to clear the blackholing. Oh and BTW, the pending route BGP stall bug is worse than ever in 10.2. On a MX960 with RE-S-2000 and a BGP config consisting of nothing more than an IBGP mesh (28 sessions) and a SINGLE TRANSIT SESSION, it took just over 12 minutes before a single route from the transit session was successfully installed to hardware. So far things aren't looking good. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Crashing M5 with some log regarding the hard drive
On Tuesday 29 of June 2010 10:48:30 Thomas Eichhorn wrote: Hi all, I have a M5 which is currently rebooting almost exactly all 4 hours with the following log: Jun 29 08:39:45 r1 savecore: reboot after panic: ad_ioctl:1277800528: ad1: Standby not armed but state is invalid: state=ARMED Jun 29 08:39:45 r1 /kernel: savecore: reboot after panic: ad_ioctl:1277800528: ad1: Standby not armed but state is invalid: state=ARMED I know that somebody has seen this on M7i some time ago - but did not got an anwser.. I run that box with 9.3R4.4 and have updated also the CF-card - but the harddrive is the one which has been where for almost ever and never made such problems.. Any clue? Hi, we got answer from Aditya mahale: This looks like a issue with adaptive standby for hard drive. Please open a JTAC case Unfortunately our support for this router has finished. We replaced problematic HDD but it didn't help. Finally we removed HDD and currently router runs on CF only. We have another M7i where CF was replaced and software was upgraded but there are no problems. Regards, Marcin Kucharczyk -- Marcin Kucharczyk Dział Sieciowy ICM, Uniwersytet Warszawski m.kucharc...@net.icm.edu.pl (+48-22) 5520527, 8268009, fax. 8284195 http://www.net.icm.edu.pl/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
On Tuesday 29 June 2010 04:05:55 pm Richard A Steenbergen wrote: So far things aren't looking good. Very, very nasty, indeed. Hope you have JTAC running around on this. Would be glad to hear what comes of it. Nasty, indeed. On my end, while away on tour, Juniper came back and took back a test MX80 and got it reinstalled with a more stable version of JUNOS 10.2. The previous one was causing regular Gig-E SFP modules to output a rather weak laser, and the remote devices didn't have any clue that there was anything the other side (850nm, no less). The box came back with a newer JUNOS and fixed laser power. Yet to follow-up with details, but it's odd. 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] JUNOS and MX Trio cards
When you say 'transit session' what do you mean exactly? Also disappointed to hear about the bugs. Is the stuck-in-pending issue easily reproducible? I have read some of your past posts, but recently it sounds like this can be reproduced without a lot of effort? From: Richard A Steenbergen r...@e-gerbil.net To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tue, June 29, 2010 3:05:55 AM Subject: [j-nsp] JUNOS and MX Trio cards For all those who were wondering about code stability for Trio cards, I have my first experience to report. We just got our first shipment of MPC2 cards, and tested it out in an MX960 running 10.2R1 with MPC2 cards only, no classic DPCs. When I went to commit the config of the very first routed port with a firewall filter (IMHO a fairly simple config, about a dozen terms, but making use of chained filters), the FPC the port was on promptly crashed. Every time the FPC would reboot and come back up, it would immediately crash again. Moving the interface config with the filter to a different FPC caused that FPC to crash as well. Disabling the firewall filter caused the crashing to stop. But, the box didn't fully recover on its own. Following the crash, some packets forwarded through that box were being blackholed. After doing a GRES/NSR switchover, the blackholing cleared briefly, but started again the exact instant the backup RE came back online. I tried disabling the GRES/NSR config, but the blackholing still didn't go away. A complete PFE restart was required to clear the blackholing. Oh and BTW, the pending route BGP stall bug is worse than ever in 10.2. On a MX960 with RE-S-2000 and a BGP config consisting of nothing more than an IBGP mesh (28 sessions) and a SINGLE TRANSIT SESSION, it took just over 12 minutes before a single route from the transit session was successfully installed to hardware. So far things aren't looking good. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] P2MP LSP
All, I have been trying to understand the P2MP LSP signalling and establishment. I have few question about it: How the ingress node knows about all the egress Node? BGP? Any good document or link? Now ingress node knows about the egress node then tunnel will be singaled using the RSVP so there must be interaction between BGP and RSVP right? If so then what kind of communication is it? Any good link or documents? If any one has any good document to share that will be great help, I am looking for control plane communication between Egress nodes and Ingress node to establish P2MP LSP. -- David W. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] P2MP LSP
On Tuesday 29 June 2010 11:43:49 pm David water wrote:
How the ingress node knows about all the egress Node?
BGP?
Yes, the MCAST-VPN address family ('inet-mvpn' in JUNOS)
signals the MVPN BGP NLRI either between peers or between
peers and route reflectors that support this AFI.
Now ingress node knows about the egress node then tunnel
will be singaled using the RSVP so there must be
interaction between BGP and RSVP right?
If so then what
kind of communication is it?
P-tunnels transport MVPN traffic across a p2mp LSP from
ingress to egress. The tunnel typically implemented by JUNOS
for the NG-MVPN infrastructure is MPLS, signaled by RSVP-TE.
The ingress/Sender PE router uses a new BGP attribute called
PSMI (Provider Multicast Service Interface) to disseminate
P-tunnel information to the egress/Receiver PE routers. The
Receiver PE routers then join the P-tunnels, and become
leaves of it.
I-PMSI P-tunnels (inclusive) forward MVPN data to all PE
routers in the RSI. S-PMSI P-tunnels (selective) can
restrict this to only a group of PE routers in the RSI. Both
options have their pros and cons, although inclusive tunnels
tend to be more common (I think).
On the control plane side, BGP is used to distribute
Multicast routing information across the backbone, in
effect, replacing PIM in the core.
Any good link or documents?
If any one has any good document to share that will be
great help, I am looking for control plane communication
between Egress nodes and Ingress node to establish P2MP
LSP.
These are great documents:
http://www.juniper.net/us/en/local/pdf/whitepapers/2000320-
en.pdf
http://www.juniper.net/us/en/local/pdf/app-notes/3500142-
en.pdf
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] Certification advise
On Wednesday 30 June 2010 12:41:21 am Walter Keen wrote: Been working in a service provider environment, mostly Cisco, almost finished with a CCIP. Want to get a Juniper cert as well, but not sure which one is best suited for service provider enviroments. perhaps the JNCIA-M or JNCIS-M? I'd hate to get the JNCIA instead of JNCIS if there is a significant increase in job availability. What are peoples thoughts on this? While JNCIS doesn't require you to have JNCIA, I'd recommend starting with JNCIA as JNCIS assumes some basics (whether you know them from JNCIA or some other source), many of which are covered in JNCIA. 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] P2MP LSP
Mark,
Using those route types we can communicate about the source and destinations
in MVPN. Now as we know how to discover the source and receiver its time for
RSVP to take care of building the P2MP right? So RSVP does use the the BGP
discovered information to establish LSP, correct? So this way LSPs are
totally dynamic.
David W.
On Tue, Jun 29, 2010 at 1:21 PM, Mark Tinka mti...@globaltransit.netwrote:
On Tuesday 29 June 2010 11:43:49 pm David water wrote:
How the ingress node knows about all the egress Node?
BGP?
Yes, the MCAST-VPN address family ('inet-mvpn' in JUNOS)
signals the MVPN BGP NLRI either between peers or between
peers and route reflectors that support this AFI.
Now ingress node knows about the egress node then tunnel
will be singaled using the RSVP so there must be
interaction between BGP and RSVP right?
If so then what
kind of communication is it?
P-tunnels transport MVPN traffic across a p2mp LSP from
ingress to egress. The tunnel typically implemented by JUNOS
for the NG-MVPN infrastructure is MPLS, signaled by RSVP-TE.
The ingress/Sender PE router uses a new BGP attribute called
PSMI (Provider Multicast Service Interface) to disseminate
P-tunnel information to the egress/Receiver PE routers. The
Receiver PE routers then join the P-tunnels, and become
leaves of it.
I-PMSI P-tunnels (inclusive) forward MVPN data to all PE
routers in the RSI. S-PMSI P-tunnels (selective) can
restrict this to only a group of PE routers in the RSI. Both
options have their pros and cons, although inclusive tunnels
tend to be more common (I think).
On the control plane side, BGP is used to distribute
Multicast routing information across the backbone, in
effect, replacing PIM in the core.
Any good link or documents?
If any one has any good document to share that will be
great help, I am looking for control plane communication
between Egress nodes and Ingress node to establish P2MP
LSP.
These are great documents:
http://www.juniper.net/us/en/local/pdf/whitepapers/2000320-
en.pdf
http://www.juniper.net/us/en/local/pdf/app-notes/3500142-
en.pdf
Cheers,
Mark.
--
David W.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] P2MP LSP
Hi David,
Mark is absolutely correct, his example is specific to NG MVPN, although
technically you can also have
L3VPN P2MP, but yeah now best to move to NG MVPN if you can , and get the
benefits of a BGP based core.
Regarding Mark comments that most are using inclusive P-tunnels, we are
using selective P tunnels, although
i think most implementation use inclusive P-tunnels, as it easier to manage
but I personnaly think it add more burden on the network.
Here is also another way of understand how the P2MP is actually build,
AFAIK, think of a network that has
--- PE4
PE 1 -- P1 --- P2--- PE3
--- PE5
First, you enable the p2mp in your mpls config for the lsp's
what happened is that when traffic is destined from PE1 to PE4 , it create a
Point to Point LSP with the labels
when a second traffic request, then goes from PE1 to PE3, it creates a 2nd
P2P LSP,again with it's own labels
a 3rd traffic request comes in which is from PE1 to PE5 , it creates a 3rd
P2P LSP, also with it's own labels
The P2MP options that is enable on MPLS, what it does is that the common LSP
path between the 3 endpoints then gets merge and it create a single label.
So in our examples between PE1 and P2 (PE1 + P1 + P2 ), this part of the
path will be merged and will share among them a single label for all 3
destinations, and then becomes a true P2MP LSP.
HTH
BR
On 29 June 2010 18:21, Mark Tinka mti...@globaltransit.net wrote:
On Tuesday 29 June 2010 11:43:49 pm David water wrote:
How the ingress node knows about all the egress Node?
BGP?
Yes, the MCAST-VPN address family ('inet-mvpn' in JUNOS)
signals the MVPN BGP NLRI either between peers or between
peers and route reflectors that support this AFI.
Now ingress node knows about the egress node then tunnel
will be singaled using the RSVP so there must be
interaction between BGP and RSVP right?
If so then what
kind of communication is it?
P-tunnels transport MVPN traffic across a p2mp LSP from
ingress to egress. The tunnel typically implemented by JUNOS
for the NG-MVPN infrastructure is MPLS, signaled by RSVP-TE.
The ingress/Sender PE router uses a new BGP attribute called
PSMI (Provider Multicast Service Interface) to disseminate
P-tunnel information to the egress/Receiver PE routers. The
Receiver PE routers then join the P-tunnels, and become
leaves of it.
I-PMSI P-tunnels (inclusive) forward MVPN data to all PE
routers in the RSI. S-PMSI P-tunnels (selective) can
restrict this to only a group of PE routers in the RSI. Both
options have their pros and cons, although inclusive tunnels
tend to be more common (I think).
On the control plane side, BGP is used to distribute
Multicast routing information across the backbone, in
effect, replacing PIM in the core.
Any good link or documents?
If any one has any good document to share that will be
great help, I am looking for control plane communication
between Egress nodes and Ingress node to establish P2MP
LSP.
These are great documents:
http://www.juniper.net/us/en/local/pdf/whitepapers/2000320-
en.pdf
http://www.juniper.net/us/en/local/pdf/app-notes/3500142-
en.pdf
Cheers,
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] JUNOS and MX Trio cards
On Tue, Jun 29, 2010 at 08:37:20AM -0700, Derick Winkworth wrote: When you say 'transit session' what do you mean exactly?? Also disappointed to hear about the bugs.? Transit (n): An EBGP session where an external ASN sends you a full copy of the global routing table, usually in exchange for money. :) Is the stuck-in-pending issue easily reproducible?? I have read some of your past? posts, but recently it sounds like this can be reproduced without a lot of effort? Trivially reproducable here, all that seems to be required is a decent number of BGP sessions that you have to send the update to. Just last night I noticed it took over 6 minutes to remove the routes and stop forwarding traffic to a ebgp session I shut down on a 9.6R4 router (which was mostly cpu idle before starting), and EX8200s running 10.1 have taken 5-7 minutes to start installing or exchanging routes with nothing more than 2 IBGP RR feeds and a local transit session. Usually the problem is worst after a fresh reboot, where it can take 10-20 minutes to actually install the routing table into hw, but on newer code it seems to be happening on an otherwise stable router with just a single BGP session flap. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Certification advise
yep , I dont know wha's wrong but I keep agreeing with Mark today ;-) I would start with JNCIA, because if you come from a Cisco background, there are some chapter in the JNCIA that talk about the hardware architecture of Juniper router (not in depth but it's good to know) , and cover somes junos basics. well that's my 2 cents , if you want the certificate for just to have the certificate then jump straight into JNCIS On 29 June 2010 18:27, Mark Tinka mti...@globaltransit.net wrote: On Wednesday 30 June 2010 12:41:21 am Walter Keen wrote: Been working in a service provider environment, mostly Cisco, almost finished with a CCIP. Want to get a Juniper cert as well, but not sure which one is best suited for service provider enviroments. perhaps the JNCIA-M or JNCIS-M? I'd hate to get the JNCIA instead of JNCIS if there is a significant increase in job availability. What are peoples thoughts on this? While JNCIS doesn't require you to have JNCIA, I'd recommend starting with JNCIA as JNCIS assumes some basics (whether you know them from JNCIA or some other source), many of which are covered in JNCIA. 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] Certification advise
Yes, JNCIA is the usual starting point. The JNCIS takes many JNCIA topics into more detail. On Tue, Jun 29, 2010 at 1:27 PM, Mark Tinka mti...@globaltransit.net wrote: On Wednesday 30 June 2010 12:41:21 am Walter Keen wrote: Been working in a service provider environment, mostly Cisco, almost finished with a CCIP. Want to get a Juniper cert as well, but not sure which one is best suited for service provider enviroments. perhaps the JNCIA-M or JNCIS-M? I'd hate to get the JNCIA instead of JNCIS if there is a significant increase in job availability. What are peoples thoughts on this? While JNCIS doesn't require you to have JNCIA, I'd recommend starting with JNCIA as JNCIS assumes some basics (whether you know them from JNCIA or some other source), many of which are covered in JNCIA. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- It has to start somewhere, it has to start sometime. What better place than here? What better time than now? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
So basically, this stalled route issue has been going on for so long, that its truthful to say that Juniper probably doesn't think its important to fix? or they don't care? I wonder what their official line is. Might be similar to their official line with respect to the manufacturing issue with the EX series, where so many ASICs are just bad... I think they have some code in JUNOS now that detects the bad ASICs and just resets them when the failure detected. How unfortunate. I wonder of Alca-Lu can do better. Lord knows Cisco could care less about code quality. surely some networking vendor must give a sh*t. From: Richard A Steenbergen r...@e-gerbil.net To: Derick Winkworth dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tue, June 29, 2010 2:59:55 PM Subject: Re: [j-nsp] JUNOS and MX Trio cards On Tue, Jun 29, 2010 at 08:37:20AM -0700, Derick Winkworth wrote: When you say 'transit session' what do you mean exactly?? Also disappointed to hear about the bugs.? Transit (n): An EBGP session where an external ASN sends you a full copy of the global routing table, usually in exchange for money. :) Is the stuck-in-pending issue easily reproducible?? I have read some of your past? posts, but recently it sounds like this can be reproduced without a lot of effort? Trivially reproducable here, all that seems to be required is a decent number of BGP sessions that you have to send the update to. Just last night I noticed it took over 6 minutes to remove the routes and stop forwarding traffic to a ebgp session I shut down on a 9.6R4 router (which was mostly cpu idle before starting), and EX8200s running 10.1 have taken 5-7 minutes to start installing or exchanging routes with nothing more than 2 IBGP RR feeds and a local transit session. Usually the problem is worst after a fresh reboot, where it can take 10-20 minutes to actually install the routing table into hw, but on newer code it seems to be happening on an otherwise stable router with just a single BGP session flap. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Stripping off BGP Prepends
Hi there.. Some of you might get a chuckle out of this... Have a customer who called and wants us to strip off their prepends they are padding in their BGP session with us. They are padding their AS number 6 times and now the traffic levels are getting too large with their other upstream provider. Obviously I asked - umm... why don't *you* change it? Their answer was that a consultant set this up for them and he's on holidays this week yikes... Anyways, JunOS on MX series - Do this in an import policy? I'm looking for something that says AS numbers in path only allowed once for simplicity sake I think Thanks for any input ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
