Re: [j-nsp] Bypass LSP functionality question
Correction, I said Path Tear in my previous message, rather I meant Path Err... Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant On 7/7/2011 12:15 AM, Stefan Fouant wrote: On 7/6/2011 11:50 AM, David Ball wrote: Just looking for confirmation of a suspicion here. If I have an LSP configured with link-protection on every interface along the way (creating many-to-one Bypass LSPs, as opposed to 1:1 detours), no secondary standby path defined, and a protected interface fails, the ingress node will have no ability to perform a make-before-break, right? Because the Path Tear messages will be sent both upstream and downstream from the failed interface? The bypass will only help me up until the upstream nodes process the Path Tears and a new LSP is signalled from the ingress nodeor am I missing something? Hi David, The bypass is only used temporarily to save the traffic that is already traversing the LSP. At the same time that the bypass LSP is being used, the node which established the Bypass around the failure will will send the Path Tear message upstream towards the Ingress LSR. Once the Ingress LSR receives the Path Tear it may signal an alternate path assuming some Secondary paths have been configured. You could have the Secondary LSP set up as a Standby in which case it is pre-signaled but will require double the amount of reservation state in the network. This is inherently make-before-break because the Secondary Standby is already established by the time your Primary has failed. Another option is to configure the Adaptive option which will force the Ingress LSR to continue using the Primary LSP (traversing a Bypass) until it has signaled the Secondary path and only once the secondary has been established will it cease using the Primary. This has the benefit of also reducing the amount of reservation state in the network due to the fact that Adaptive option signals LSPs using the Shared Explicit style. HTHs, Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ 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] Bypass LSP functionality question
That's not correct. You should take a look at RFC4090. A Patherr message is sent to the head-end node with a flag set to notify it local protection is in use. There are also flags in the RESV RRO to notify the head-end local protection is in use. The head-end node is smart enough to keep using the path until it can reserve a new path and do a MBB operation. Facility bypass wouldn't be very useful if it only protected traffic for a few ms...:) Phil On 7/6/11 11:50 AM, "David Ball" wrote: > Just looking for confirmation of a suspicion here. > > If I have an LSP configured with link-protection on every interface >along the way (creating many-to-one Bypass LSPs, as opposed to 1:1 >detours), no secondary standby path defined, and a protected interface >fails, the ingress node will have no ability to perform a >make-before-break, right? Because the Path Tear messages will be sent >both upstream and downstream from the failed interface? The bypass >will only help me up until the upstream nodes process the Path Tears >and a new LSP is signalled from the ingress nodeor am I missing >something? > > More familiar with detours, so just checking myself wrt bypasses > >Cheers, > >David >___ >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] Bypass LSP functionality question
On 7/6/2011 11:50 AM, David Ball wrote: Just looking for confirmation of a suspicion here. If I have an LSP configured with link-protection on every interface along the way (creating many-to-one Bypass LSPs, as opposed to 1:1 detours), no secondary standby path defined, and a protected interface fails, the ingress node will have no ability to perform a make-before-break, right? Because the Path Tear messages will be sent both upstream and downstream from the failed interface? The bypass will only help me up until the upstream nodes process the Path Tears and a new LSP is signalled from the ingress nodeor am I missing something? Hi David, The bypass is only used temporarily to save the traffic that is already traversing the LSP. At the same time that the bypass LSP is being used, the node which established the Bypass around the failure will will send the Path Tear message upstream towards the Ingress LSR. Once the Ingress LSR receives the Path Tear it may signal an alternate path assuming some Secondary paths have been configured. You could have the Secondary LSP set up as a Standby in which case it is pre-signaled but will require double the amount of reservation state in the network. This is inherently make-before-break because the Secondary Standby is already established by the time your Primary has failed. Another option is to configure the Adaptive option which will force the Ingress LSR to continue using the Primary LSP (traversing a Bypass) until it has signaled the Secondary path and only once the secondary has been established will it cease using the Primary. This has the benefit of also reducing the amount of reservation state in the network due to the fact that Adaptive option signals LSPs using the Shared Explicit style. HTHs, Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE : Perempt hold-down time on vrrp
Hi David, Thanks for the reply. So, the preempt hold-time will not work if master router configured with tracking interface and priority-cost to subtract it's priority to less than the backup router? Please check the below document. It says that if we omit preempt statement, the backup router cannot preempt a master router. http://www.juniper.net/techpubs/software/junos/junos91/swconfig-high-availability/preempt.html#preempt-statement-vrrp Thanks, Siva Sent from my Android. On Thu, Jul 7, 2011 at 1:39 AM, wrote: > Hi > > Hold-time on Junos is only available when Vrrpd restart (It is usually used > when VRRP crash or RE reboot or RE switchover without NSR) > > Regards > David > > > De : juniper-nsp-boun...@puck.nether.net [ > juniper-nsp-boun...@puck.nether.net] de la part de MSusiva [ > ssiva1...@gmail.com] > Date d'envoi : mercredi 6 juillet 2011 20:44 > À : juniper-nsp@puck.nether.net > Objet : [j-nsp] Perempt hold-down time on vrrp > > Hi experts, > > I have been testing prempt hold time on vrrp & it did not work as expected > or may be my understanding is wrong. > > I have set prempt hold-down time as 60sec. In the case of master router is > going down, the backup router takes master state immediately. When the > previous master comes up, it has to wait 60sec before taking the master > state. > > Can some please explain? > > Thanks, > Siva > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > IMPORTANT.Les informations contenues dans ce message electronique y compris > les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) > mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, > veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues dans > ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamment > s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout > virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidential > and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named > recipient(s), please immediately notify the sender and delete this e-mail > message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not > be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > > > > -- Thanks, Subramania Siva Madhu Mob: +91-9840453317 "Nothing is wrong until you are caught" ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE : Perempt hold-down time on vrrp
On Wed, Jul 06, 2011 at 10:09:05PM +0200, david@orange-ftgroup.com wrote: > Hold-time on Junos is only available when Vrrpd restart (It is usually > used when VRRP crash or RE reboot or RE switchover without NSR) I cannot confirm that from own observation. Interface state change is enough to trigger hold-timer. We've actually found a problem with hold-time in a corner case situation where it holds "far too long". Assume a setup with two routers, A and B. Rtr A has higher VRRP prio than B, preemption is enabled with hold-timer e.g. 300sec. Rtr A interface goes down, Rtr B assumes mastership. Rtr A interface comes up again, and hold-timer kicks in. Rtr A sees the VRRP PDUs from Rtr B. Now while in hold-time period, Rtr B VRRP interface goes down and thus VRRP PDUs sent from Rtr B stop. We would have expected Rtr A to detect that and immediately assume mastership, but that doesn't happen. Observing that, we would have expected that it takes until hold-time expiry for that to happen - but it only took ~1m, which was still ~1.5m short of expiry. Didn't have time to dig deeper and confirm the last observation with more tests, but hold-timer (at least for some time) ignoring sudden absence of lower-prio master definately caused unexpected outage. 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
[j-nsp] RE : Perempt hold-down time on vrrp
Hi Hold-time on Junos is only available when Vrrpd restart (It is usually used when VRRP crash or RE reboot or RE switchover without NSR) Regards David De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] de la part de MSusiva [ssiva1...@gmail.com] Date d'envoi : mercredi 6 juillet 2011 20:44 À : juniper-nsp@puck.nether.net Objet : [j-nsp] Perempt hold-down time on vrrp Hi experts, I have been testing prempt hold time on vrrp & it did not work as expected or may be my understanding is wrong. I have set prempt hold-down time as 60sec. In the case of master router is going down, the backup router takes master state immediately. When the previous master comes up, it has to wait 60sec before taking the master state. Can some please explain? Thanks, Siva ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Perempt hold-down time on vrrp
Hi experts, I have been testing prempt hold time on vrrp & it did not work as expected or may be my understanding is wrong. I have set prempt hold-down time as 60sec. In the case of master router is going down, the backup router takes master state immediately. When the previous master comes up, it has to wait 60sec before taking the master state. Can some please explain? Thanks, Siva ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] RE : Matching communities in 'show route receive-protocol bgp' command
Hi >From the Junos Guide : The output displays the selected routes and the attributes with which they were received, but does not show the effects of import policy on the routing attributes REgards David De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] de la part de Alexander Shikoff [minot...@crete.org.ua] Date d'envoi : mercredi 6 juillet 2011 18:33 À : Stacy W. Smith Cc : Juniper List Objet : Re: [j-nsp] Matching communities in 'show route receive-protocol bgp' command On Wed, Jul 06, 2011 at 10:28:07AM -0600, Stacy W. Smith wrote: > OK. Thanks for the additional details. That allows me to replicate the > behavior you are seeing. > > It seems the 'community' argument to 'show route' always evaluates post > import policy even when 'receive-protocol' is specified. [...] > I suspect this is because each argument to 'show route' is evaluated > independently. I'm not aware of a way to change this behavior. Hmmm... Now I'm wondering is that a bug or feature? :) > Would it be acceptable to change your import policies to use 'community add' > rather than 'community set'? That would be a potential workaround. Yes, of course. I guess I'll use that workaround. Thanks a lot for quick help! -- MINO-RIPE ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Matching communities in 'show route receive-protocol bgp' command
On Wed, Jul 06, 2011 at 10:28:07AM -0600, Stacy W. Smith wrote: > OK. Thanks for the additional details. That allows me to replicate the > behavior you are seeing. > > It seems the 'community' argument to 'show route' always evaluates post > import policy even when 'receive-protocol' is specified. [...] > I suspect this is because each argument to 'show route' is evaluated > independently. I'm not aware of a way to change this behavior. Hmmm... Now I'm wondering is that a bug or feature? :) > Would it be acceptable to change your import policies to use 'community add' > rather than 'community set'? That would be a potential workaround. Yes, of course. I guess I'll use that workaround. Thanks a lot for quick help! -- MINO-RIPE ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Matching communities in 'show route receive-protocol bgp' command
OK. Thanks for the additional details. That allows me to replicate the behavior
you are seeing.
It seems the 'community' argument to 'show route' always evaluates post import
policy even when 'receive-protocol' is specified.
Here's an example.
Route is received with community 1:1.
root@j6300> show route receive-protocol bgp 192.168.0.1 detail
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2
hidden)
R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 192.168.200.0/25 (1 entry, 1 announced)
Accepted
Nexthop: 192.168.0.1
AS path: 1 I
Communities: 1:1
My import policy uses 'community set' to replace the community with 2:2.
root@j6300> show route protocol bgp detail
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2
hidden)
R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
192.168.200.0/25 (1 entry, 1 announced)
*BGPPreference: 170/-101
Next hop type: Router, Next hop index: 568
Next-hop reference count: 2
Source: 192.168.0.1
Next hop: 192.168.0.1 via lt-0/0/0.1, selected
State:
Local AS: 2 Peer AS: 1
Age: 2:24
Task: BGP_1_2.192.168.0.1+179
Announcement bits (1): 0-KRT
AS path: 1 I
Communities: 2:2
Accepted
Localpref: 100
Router ID: 192.168.255.254
Now I can no longer match on 1:1.
root@j6300> show route receive-protocol bgp 192.168.0.1 community 1:1
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2
hidden)
R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
But I can match on 2:2, even when 'receive-protocol' is specified.
root@j6300> show route receive-protocol bgp 192.168.0.1 community 2:2
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2
hidden)
R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED LclprefAS path
* 192.168.200.0/25192.168.0.1 1 I
I suspect this is because each argument to 'show route' is evaluated
independently. I'm not aware of a way to change this behavior.
Would it be acceptable to change your import policies to use 'community add'
rather than 'community set'? That would be a potential workaround.
--Stacy
On Jul 6, 2011, at 10:04 AM, Alexander Shikoff wrote:
> On Wed, Jul 06, 2011 at 09:50:55AM -0600, Stacy W. Smith wrote:
>> I just tried to replicate your problem (on an old version of JunOS), and the
>> community knob works as expected for me.
>>
>> root@j6300> show version
>> Hostname: j6300
>> Model: j6300
>> JUNOS Software Release [9.3S9]
>>
>> root@j6300> show route receive-protocol bgp 192.168.0.1 detail table
>> R1.inet.0
>>
>> R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
>> * 192.168.200.0/25 (1 entry, 1 announced)
>> Accepted
>> Nexthop: 192.168.0.1
>> AS path: 1 I
>> Communities: 1:1
>>
>> root@j6300> show route receive-protocol bgp 192.168.0.1 community 1:1
>>
>>
>> inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
>>
>> __juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown,
>> 2 hidden)
>>
>> R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
>> PrefixNexthop MED LclprefAS path
>> * 192.168.200.0/25192.168.0.1 1 I
>>
>>
>> What version of JunOS are you using? What platform?
> JunOS 10.3R3.7
> Juniper MX80-48T
>
>> Can you also provide us with the output 'show route ams-ix.net extensive
>> table World.inet.0'?
> minot...@br1-gdr.ki> show route ams-ix.net extensive table World.inet.0
>
> World.inet.0: 362220 destinations, 720282 routes (358772 active, 30 holddown,
> 3907 hidden)
> 91.200.16.0/22 (2 entries, 1 announced)
> TSI:
> KRT in-kernel 91.200.16.0/22 -> {77.88.200.133}
> Destination class: to-World
> Source class: from-World
>*BGPPreference: 170/-111
>Next hop type: Router, Next hop index: 711
>Next-hop reference count: 760367
>Source: 77.88.200.133
>Next hop: 77.88.200.133 via ge-1/0/1.1252, selected
>State:
>Peer AS: 21011
>Age: 1w3d 5:47:14
>Task: BGP_21011.77.88.200.133+56251
>Announcement bits (4): 0-RT 1-KRT 2-rt-export 4-Resolve
Re: [j-nsp] Matching communities in 'show route receive-protocol bgp' command
On Wed, Jul 06, 2011 at 09:50:55AM -0600, Stacy W. Smith wrote:
> I just tried to replicate your problem (on an old version of JunOS), and the
> community knob works as expected for me.
>
> root@j6300> show version
> Hostname: j6300
> Model: j6300
> JUNOS Software Release [9.3S9]
>
> root@j6300> show route receive-protocol bgp 192.168.0.1 detail table
> R1.inet.0
>
> R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
> * 192.168.200.0/25 (1 entry, 1 announced)
> Accepted
> Nexthop: 192.168.0.1
> AS path: 1 I
> Communities: 1:1
>
> root@j6300> show route receive-protocol bgp 192.168.0.1 community 1:1
>
>
> inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
>
> __juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown,
> 2 hidden)
>
> R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
> PrefixNexthop MED LclprefAS path
> * 192.168.200.0/25192.168.0.1 1 I
>
>
> What version of JunOS are you using? What platform?
JunOS 10.3R3.7
Juniper MX80-48T
> Can you also provide us with the output 'show route ams-ix.net extensive
> table World.inet.0'?
minot...@br1-gdr.ki> show route ams-ix.net extensive table World.inet.0
World.inet.0: 362220 destinations, 720282 routes (358772 active, 30 holddown,
3907 hidden)
91.200.16.0/22 (2 entries, 1 announced)
TSI:
KRT in-kernel 91.200.16.0/22 -> {77.88.200.133}
Destination class: to-World
Source class: from-World
*BGPPreference: 170/-111
Next hop type: Router, Next hop index: 711
Next-hop reference count: 760367
Source: 77.88.200.133
Next hop: 77.88.200.133 via ge-1/0/1.1252, selected
State:
Peer AS: 21011
Age: 1w3d 5:47:14
Task: BGP_21011.77.88.200.133+56251
Announcement bits (4): 0-RT 1-KRT 2-rt-export 4-Resolve tree 2
AS path: 21011 1200 I
AS path: Recorded
Communities: 25372:20480
Accepted
Localpref: 110
Router ID: 88.81.250.22
BGPPreference: 170/-101
Next hop type: Router, Next hop index: 767
Next-hop reference count: 1743395
Source: 87.245.247.13
Next hop: 87.245.247.13 via ge-1/0/0.200, selected
State:
Inactive reason: Local Preference
Peer AS: 9002
Age: 38:51
Task: BGP_9002.87.245.247.13+179
AS path: 9002 1200 I
Communities: 25372:6 25372:20480
Accepted
Localpref: 100
Router ID: 87.245.225.101
I'm changing communities when importing routes. If call the command with
'receive-protocol bgp' then the output will differ:
minot...@br1-gdr.ki> show route ams-ix.net receive-protocol bgp 77.88.200.133
extensive table World.inet.0
World.inet.0: 362199 destinations, 720243 routes (358775 active, 6 holddown,
3906 hidden)
* 91.200.16.0/22 (2 entries, 1 announced)
Accepted
Nexthop: 77.88.200.133
AS path: 21011 1200 I
AS path: Recorded
Communities: 21011:400 21011:6777 21011:64528 31445:400
Now let's try to filter routes by community:
minot...@br1-gdr.ki> show route ams-ix.net community 25372:20480 table World
World.inet.0: 362185 destinations, 720235 routes (358767 active, 0 holddown,
3906 hidden)
+ = Active Route, - = Last Active, * = Both
91.200.16.0/22 *[BGP/170] 1w3d 05:50:14, localpref 110
AS path: 21011 1200 I
> to 77.88.200.133 via ge-1/0/1.1252
[BGP/170] 00:41:51, localpref 100
AS path: 9002 1200 I
> to 87.245.247.13 via ge-1/0/0.200
It works.
Now let's try to filter routes but with 'receive protocol bgp' options:
minot...@br1-gdr.ki> show route ams-ix.net receive-protocol bgp 77.88.200.133
extensive table World.inet.0 community 21011:64528
- empty output.
For some strange reason filtering by community does not work for me with
'receive protocol bgp'
option.
--
MINO-RIPE
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Matching communities in 'show route receive-protocol bgp' command
I just tried to replicate your problem (on an old version of JunOS), and the community knob works as expected for me. root@j6300> show version Hostname: j6300 Model: j6300 JUNOS Software Release [9.3S9] root@j6300> show route receive-protocol bgp 192.168.0.1 detail table R1.inet.0 R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 192.168.200.0/25 (1 entry, 1 announced) Accepted Nexthop: 192.168.0.1 AS path: 1 I Communities: 1:1 root@j6300> show route receive-protocol bgp 192.168.0.1 community 1:1 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) __juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED LclprefAS path * 192.168.200.0/25192.168.0.1 1 I What version of JunOS are you using? What platform? Can you also provide us with the output 'show route ams-ix.net extensive table World.inet.0'? Thanks, --Stacy On Jul 6, 2011, at 8:29 AM, Alexander Shikoff wrote: > Hello, > > I have a problem with matching communities in 'show route receive-protocol > bgp' command. > For example, I have a route: > > minot...@br1-gdr.ki> show route ams-ix.net receive-protocol bgp 77.88.200.133 > detail table World.inet.0 > > World.inet.0: 362279 destinations, 720396 routes (358851 active, 9 holddown, > 3907 hidden) > * 91.200.16.0/22 (2 entries, 1 announced) > Accepted > Nexthop: 77.88.200.133 > AS path: 21011 1200 I > AS path: Recorded > Communities: 21011:400 21011:6777 21011:64528 31445:400 > > Now I'm trying to filter all routes from 77.88.200.133 peer with 21011:64528 > community: > > minot...@br1-gdr.ki> show route receive-protocol bgp 77.88.200.133 community > 21011:64528 > > And output is empty. > > Then I tried to match community via policy: > minot...@br1-gdr.ki> show configuration policy-options community Netherlands > members 21011:64528; > > minot...@br1-gdr.ki> show route receive-protocol bgp 77.88.200.133 > community-name Netherlands > > And output is empty again. > > Could please someone give an example of right command? > Thanks in advance! > > -- > MINO-RIPE > ___ > 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] Bypass LSP functionality question
Just looking for confirmation of a suspicion here. If I have an LSP configured with link-protection on every interface along the way (creating many-to-one Bypass LSPs, as opposed to 1:1 detours), no secondary standby path defined, and a protected interface fails, the ingress node will have no ability to perform a make-before-break, right? Because the Path Tear messages will be sent both upstream and downstream from the failed interface? The bypass will only help me up until the upstream nodes process the Path Tears and a new LSP is signalled from the ingress nodeor am I missing something? More familiar with detours, so just checking myself wrt bypasses Cheers, David ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Firewalls "as-a-service" in an MPLS infrastructure...
Thoughts on this blog entry? I wonder if Cisco will support BGP on ASA soon.. I know people have been asking for it. It would be nice if it had something Netconf on it too... The new ASA blade is coming out for Nexus I hear, anyone know how many virtual-firewalls it will support? Juniper's SRX will do LSYS soon.. 32 per box. That seems like a low number. Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Matching communities in 'show route receive-protocol bgp' command
Hello, I have a problem with matching communities in 'show route receive-protocol bgp' command. For example, I have a route: minot...@br1-gdr.ki> show route ams-ix.net receive-protocol bgp 77.88.200.133 detail table World.inet.0 World.inet.0: 362279 destinations, 720396 routes (358851 active, 9 holddown, 3907 hidden) * 91.200.16.0/22 (2 entries, 1 announced) Accepted Nexthop: 77.88.200.133 AS path: 21011 1200 I AS path: Recorded Communities: 21011:400 21011:6777 21011:64528 31445:400 Now I'm trying to filter all routes from 77.88.200.133 peer with 21011:64528 community: minot...@br1-gdr.ki> show route receive-protocol bgp 77.88.200.133 community 21011:64528 And output is empty. Then I tried to match community via policy: minot...@br1-gdr.ki> show configuration policy-options community Netherlands members 21011:64528; minot...@br1-gdr.ki> show route receive-protocol bgp 77.88.200.133 community-name Netherlands And output is empty again. Could please someone give an example of right command? Thanks in advance! -- MINO-RIPE ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
