I have been buying my Optics from enfoPoint contact t...@enfopoint.com They have served me well and at a much lower price than the Standard Premium Juniper priced optics. This is not meant as an advisement but informational content. They have totally built me any optic I have needed. -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of juniper-nsp-requ...@puck.nether.net Sent: Thursday, February 23, 2012 7:52 AM To: juniper-nsp@puck.nether.net Subject: juniper-nsp Digest, Vol 111, Issue 31
Send juniper-nsp mailing list submissions to juniper-nsp@puck.nether.net To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/juniper-nsp or, via email, send a message with subject or body 'help' to juniper-nsp-requ...@puck.nether.net You can reach the person managing the list at juniper-nsp-ow...@puck.nether.net When replying, please edit your Subject line so it is more specific than "Re: Contents of juniper-nsp digest..." Today's Topics: 1. Re: Set MED in BGP to IGP metric for iBGP NEXT-HOP router (Jeff Wheeler) 2. Re: Junos MPLS/LDP L2circuit label issue (Mark Tinka) 3. Re: Only announce BGP learned networks (Chris Kawchuk) 4. Re: Set MED in BGP to IGP metric for iBGP NEXT-HOP router (Paul Zugnoni) 5. Re: Sources for SFP+ optics (Daniel Roesen) 6. IS-IS routes not installed (Kevin Wormington) 7. Re: Sources for SFP+ optics (Robert Juric) 8. Re: Sources for SFP+ optics (Tim Jackson) ---------------------------------------------------------------------- Message: 1 Date: Wed, 22 Feb 2012 20:29:54 -0500 From: Jeff Wheeler <j...@inconcepts.biz> To: Paul Zugnoni <paul.zugn...@onlive.com> Cc: juniper-nsp <juniper-nsp@puck.nether.net> Subject: Re: [j-nsp] Set MED in BGP to IGP metric for iBGP NEXT-HOP router Message-ID: <CAPWAtbL5Z+_NYZXTLJsZDYtXwKvhacxSUWiMgDK6+tP=trh...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 21, 2012 at 7:25 PM, Paul Zugnoni <paul.zugn...@onlive.com> wrote: > I'm looking to set the MED on routes exported to eBGP peers to reflect > the IGP metric to the BGP protocol next-hop I did not see any replies to your question. Apologies if you already figured this out yourself. set metric igp already does what you describe. You will also want to read the documentation on `set metric minimum-igp` which is often what folks really want. Keep in mind that the MED will be set to the IGP metric to the protocol next-hop, NOT "the address of the router it learned the route from." You used both phrasings in your post. So for example, if you have a route reflector in your AS, a route may be learned from an RR but the metric will obviously not be based on the path to the RR, but the path to the next-hop. -- Jeff S Wheeler <j...@inconcepts.biz> Sr Network Operator? /? Innovative Network Concepts ------------------------------ Message: 2 Date: Thu, 23 Feb 2012 11:33:37 +0800 From: Mark Tinka <mti...@globaltransit.net> To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Junos MPLS/LDP L2circuit label issue Message-ID: <201202231133.37568.mti...@globaltransit.net> Content-Type: text/plain; charset="us-ascii" On Wednesday, February 22, 2012 10:45:20 PM Scott Harvanek wrote: > I've tried many different traceoptions but nothing has > proven useful in generating an error message that can be > acted upon. Does anyone have any ideas on why a label > that exists both on the l2circuit and in mpls.0 would > not be getting inserted into the ldp database such as > this? Can we see the Cisco side as well? That should be: #sh mpls l2transport vc 777 detail Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20120223/e0a5c8e7/attachment-0001.sig> ------------------------------ Message: 3 Date: Thu, 23 Feb 2012 17:55:44 +1100 From: Chris Kawchuk <juniperd...@gmail.com> To: Patrick Okui <po...@psg.com> Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Only announce BGP learned networks Message-ID: <74b412f8-d41e-41a6-9a36-d1d332c14...@gmail.com> Content-Type: text/plain; charset=us-ascii On 2012-02-23, at 1:25 AM, Patrick Okui wrote: > Well, apart from l3vpns you'll typically want to have your > infrastructure addresses in your IGP and "internet/customer" addresses > in BGP. Default AD of 20 for eBGP in IOS means you'll believe an > advertisement from an external AS before say an OSPF or ISIS one for > the same exact prefix.[*] Serendipitous timing of this discussion. Dunno if you guys watch the AUSNOG list. Major outage in Telstra (AS1221) Australia today: http://www.smh.com.au/technology/technology-news/internet-crashes-for-telstra-customers-20120223-1tpqq.html A peer of Telstra ended up re-advertising all of Telstra's own routes back to Telstra as if it originated in the Peers ASN. (a BGP -> OSPF -> BGP redistribution most likely happened) If eBGP is better than IS-IS/OSPF, then all Telstra traffic (including routes to their own website and their own primary DNSs) went to the peer. Traffic ended up ping-pong'ing between the Peer and Telstra until TTL Expired. (I happen to be a Telstra xDSL subscriber as well at home - got a few traceroutes that looked like this). Naturally a prefix-limit would have helped; or a route-filter prefix-list... alas apparently neither of these were in effect. Fun and excitement down under... I have a feeling everyone is re-checking their BGP stanzas with a fine toothed comb today. =) - Chris. ------------------------------ Message: 4 Date: Thu, 23 Feb 2012 07:23:24 +0000 From: Paul Zugnoni <paul.zugn...@onlive.com> To: Jeff Wheeler <j...@inconcepts.biz> Cc: juniper-nsp <juniper-nsp@puck.nether.net> Subject: Re: [j-nsp] Set MED in BGP to IGP metric for iBGP NEXT-HOP router Message-ID: <4c4c57fd-4533-4113-ba61-b9059f2ab...@onlive.com> Content-Type: text/plain; charset="us-ascii" Hi Jeff - Thanks for the reply. Until your email, I hadn't solved it. I was getting stuck, in part, because it appears the command does /not/ have an effect on the MED when used as an import policy applied to the iBGP neighbor (at least when using ISIS level 2 metrics). I had it configured first as an import policy and troubleshooting it that way before emailing for help last night. Secondly, I hadn't yet tried clearing the BGP neighbor, and curiously found this to update my eBGP peer with the updated metric after the right export policy was applied: clear bgp neighbor 10.1.1.1 soft-minimum-igp We're on the same page re: metric minimum-igp; thanks for the distinction on the RR advertised route, too. Paul Zugnoni On Feb 22, 2012, at 17:29 , Jeff Wheeler wrote: On Tue, Feb 21, 2012 at 7:25 PM, Paul Zugnoni <paul.zugn...@onlive.com<mailto:paul.zugn...@onlive.com>> wrote: I'm looking to set the MED on routes exported to eBGP peers to reflect the IGP metric to the BGP protocol next-hop I did not see any replies to your question. Apologies if you already figured this out yourself. set metric igp already does what you describe. You will also want to read the documentation on `set metric minimum-igp` which is often what folks really want. Keep in mind that the MED will be set to the IGP metric to the protocol next-hop, NOT "the address of the router it learned the route from." You used both phrasings in your post. So for example, if you have a route reflector in your AS, a route may be learned from an RR but the metric will obviously not be based on the path to the RR, but the path to the next-hop. -- Jeff S Wheeler <j...@inconcepts.biz<mailto:j...@inconcepts.biz>> Sr Network Operator / Innovative Network Concepts ------------------------------ Message: 5 Date: Thu, 23 Feb 2012 11:31:43 +0100 From: Daniel Roesen <d...@cluenet.de> To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Sources for SFP+ optics Message-ID: <20120223103143.ga...@srv03.cluenet.de> Content-Type: text/plain; charset=us-ascii On Wed, Feb 22, 2012 at 02:27:40PM -0600, Robert Juric wrote: > Juniper also has only tested and verified their equipment with their > optics. If you want to know without doubt that it will work, go > straight to the source. "Without doubt" will give you surprises. See PR/486951 for extended fun with certain revision of Juniper-premium-price-sold Picolight/JDSU XFPs with links not coming up anymore. Or the desaster with early revision of Methode Elec. SFP-T which had a bad physical design of the locking/ejection mechanics so you were almost unable to remove them from without damaging the DPC. Bottom line: we had far less trouble with 3rd party transceivers than with Juniper premium priced transceivers.... for a fraction of cost. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ------------------------------ Message: 6 Date: Thu, 23 Feb 2012 05:11:15 -0600 From: Kevin Wormington <kw...@sofnet.com> To: juniper-nsp@puck.nether.net Subject: [j-nsp] IS-IS routes not installed Message-ID: <4f461ed3....@sofnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I have a lab setup with three nodes (2 M7i and 1 EX4200) in the following topology (forgive the bad ascii art): M7i1 <--> EX \ / \ / M7i2 The links between them are all gige going through layer2 switches with a VLAN 302 that all devices are a member of and VLAN 300 which is only the link between M7i2 and EX. IS-IS adjacencies form between all the devices and routes are propogated as expected when all links are up. If I break the link between M7i1 & EX by removing the EX from the VLAN between them then after convergence time from the EX I see the correct routes to M7i1 coming through via M7i2 and on M7i1 I see the correct route to EX via M7i2. However, if I instead break the connection between the EX and M7i2 then from M7i1 I see the correct routes coming from the EX and M7i2, but on the EX I don't see the routes to M7i2 coming via M7i1 and on M7i2 I don't see the routes from EX coming via M7i1. On M7i2 and EX the IS-IS database does show the TLVs of the routes...they are just not installed into the routing table. By routes I mean a few directly connect routes and the loopback /32s. The method I used to simulate a link failure was to remove either VLAN from the trunk port of the EX. This is a single level (level2 only) single area setup. As to why the crazy vlan setup and secondary IP config you will see below...trying to mock up something that sort of exists in the real world as part of a transition. I must be missing something simple. Any pointers would be appreciated. Thanks Kevin Config snippets: EX kevin@ex> show configuration protocols isis export isis-export; level 1 disable; interface lo0.0 { passive; } interface vlan.300; interface vlan.302; kevin@ex> ...cy-options policy-statement isis-export term term-1 { from { route-filter 0.0.0.0/0 exact; } then reject; } term term-2 { from protocol static; then accept; } term term-3 { from protocol direct; then accept; } kevin@ex> show configuration interfaces lo0 unit 0 { family inet { address 10.10.10.242/32; } family iso { address 49.0001.0100.1001.0242.0001.00; } } kevin@ex> show configuration interfaces vlan unit 300 family inet { description "M7i2 link" address 10.10.10.231/28; } family iso; kevin@ex> show configuration interfaces vlan unit 302 description "M7i1 link"; family inet { address 10.20.20.10/30; } family iso; M7i1 kevin@m7i1> show configuration protocols isis export isis-export; level 1 disable; interface ge-1/0/0.0; interface lo0.0 { passive; } kevin@m7i1> ...cy-options policy-statement isis-export term term-1 { from { route-filter 0.0.0.0/0 exact; } then accept; } term term-2 { from protocol static; then accept; } term term-3 { from protocol direct; then accept; } kevin@m7i1> show configuration interfaces ge-1/0/0 description "Link to M7i2 and EX"; unit 0 { family inet { address 10.20.20.6/30; address 10.20.20.9/30; } family iso; } kevin@m7i1> show configuration interfaces lo0 unit 0 { family inet { address 10.20.20.32/32; } family iso { address 49.0001.0100.2002.0032.0001.00; } } M7i2 kevin@m7i2> show configuration protocols isis export isis-export; level 1 disable; interface ge-1/3/0.300; interface ge-1/3/0.302; interface lo0.0 { passive; } kevin@m7i1> ...cy-options policy-statement isis-export term term-1 { from { route-filter 0.0.0.0/0 exact; } then reject; } term term-2 { from protocol static; then accept; } term term-3 { from protocol direct; then accept; } kevin@m7i2> show configuration interfaces ge-1/3/0 unit 300 description "EX Link"; vlan-id 300; family inet { address 10.10.10.228/28; } family iso; kevin@m7i2> show configuration interfaces ge-1/3/0 unit 302 description "M7i1 Link"; vlan-id 302; family inet { address 10.20.20.5/30; } family iso; kevin@m7i2> show configuration interfaces lo0 unit 0 { family inet { address 10.10.10.240/32; } family iso { address 49.0001.0100.1001.0240.0001.00; } } ------------------------------ Message: 7 Date: Thu, 23 Feb 2012 07:46:51 -0600 From: Robert Juric <robert.ju...@gmail.com> To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Sources for SFP+ optics Message-ID: <CABq8KQ=TwgsVx0bYD4Er=dmba36cg-2q-ffczzsn-slprjy...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Thanks for the insights. Which 3rd party transceivers have you had the best luck with then? Robert On Thu, Feb 23, 2012 at 4:31 AM, Daniel Roesen <d...@cluenet.de> wrote: > On Wed, Feb 22, 2012 at 02:27:40PM -0600, Robert Juric wrote: > > Juniper also has only tested and verified their equipment with their > > optics. If you want to know without doubt that it will work, go > > straight to the source. > > "Without doubt" will give you surprises. See PR/486951 for extended > fun with certain revision of Juniper-premium-price-sold Picolight/JDSU > XFPs with links not coming up anymore. Or the desaster with early > revision of Methode Elec. SFP-T which had a bad physical design of > the locking/ejection mechanics so you were almost unable to remove > them from without damaging the DPC. > > Bottom line: we had far less trouble with 3rd party transceivers than > with Juniper premium priced transceivers.... for a fraction of cost. > > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ------------------------------ Message: 8 Date: Thu, 23 Feb 2012 07:53:00 -0600 From: Tim Jackson <jackson....@gmail.com> To: Robert Juric <robert.ju...@gmail.com> Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Sources for SFP+ optics Message-ID: <cak19y1dqgger7sd6uqkj6---i8bhmhsqwejhhwzmupwpc0g...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Personally I've never had a single issue with Finisar, Fujitsu, or Opnext. SFP, SFP+, or XFP. On Thu, Feb 23, 2012 at 7:46 AM, Robert Juric <robert.ju...@gmail.com> wrote: > Thanks for the insights. Which 3rd party transceivers have you had the best > luck with then? > > Robert > > On Thu, Feb 23, 2012 at 4:31 AM, Daniel Roesen <d...@cluenet.de> wrote: > >> On Wed, Feb 22, 2012 at 02:27:40PM -0600, Robert Juric wrote: >> > Juniper also has only tested and verified their equipment with their >> > optics. If you want to know without doubt that it will work, go >> > straight to the source. >> >> "Without doubt" will give you surprises. See PR/486951 for extended >> fun with certain revision of Juniper-premium-price-sold Picolight/JDSU >> XFPs with links not coming up anymore. Or the desaster with early >> revision of Methode Elec. SFP-T which had a bad physical design of >> the locking/ejection mechanics so you were almost unable to remove >> them from without damaging the DPC. >> >> Bottom line: we had far less trouble with 3rd party transceivers than >> with Juniper premium priced transceivers.... for a fraction of cost. >> >> >> Best regards, >> Daniel >> >> -- >> CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 >> _______________________________________________ >> 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 End of juniper-nsp Digest, Vol 111, Issue 31 ******************************************** ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp