Re: [j-nsp] Apply-group for EX-VC member?
On 12/01/2012, at 5:21 PM, Per Granath wrote: >> Does anyone know if there is a special apply-group for referencing individual >> virtual-chassis members? > > member0, member 1, member2, ... > http://kb.juniper.net/InfoCenter/index?page=content&id=KB15556 > Well that's nice and obvious - thank you very much! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Apply-group for EX-VC member?
Hi all,
Does anyone know if there is a special apply-group for referencing individual
virtual-chassis members?
The SRX has node0, node1 & apply-groups ${node} and M/T have re0 re1 plus the
lcc variants, but I have a hazy (though possibly imagined) recollection of
seeing some config that allowed a distinct hostname to be configured for each
member of an EX-VC.
The "groups xxx when" command that Phil just supplied does this quite nicely
but I'm interested to know if such a group exists.
Cheers,
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 missing ARP entry work-around
Have you contacted JTAC about this issue? On Wed, Jan 11, 2012 at 2:14 PM, Jeff Wheeler wrote: > We have decided on a better work-around for our missing ARP entry > problems on the EX4200 and friends. > > As you may recall, the EX4200 will sometimes have an ARP entry in the > control-plane, but it will not be present in the data-plane. You can > investigate by checking your destination IP address with the command > `show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32` > which will produce output like this: > > PFEM0(vty)# show halp-rt route ip rtt-index 0 prefix 192.0.2.2 > prefix-length 32 > > RouteType Paths RtIdx Rpf SipSa Row:Col:Row:Col > - - --- - --- > 192.0.2.2 ECMP 0 2037 No No439:0:0:0 > > Dev0 (RtIdx:2037) > - > Command : Route CpuCode: 3 > AppSpCpuCodeEn: 0 UcSipFiltEna : 0 > TtlDecEna : 1 TtlOptChkBypass: 0 > IngressMirror : 0 QoSProfileEn : 0 > QoSProfileIndex : 0 QoSPrecedence : 1 > ModifyUp : 2 ModifyDscp : 0 > CounterSet: 2 ArpBc2Cpu : 0 > SipAccessLevel: 0 DipAccessLevel : 0 > IcmpRedirExpnMirr : 0 MtuProfileIdx : 2 > Ipv6ScopeCheckEn : 0 Ipv6DstSiteId : 0 > NhTnnl: 0 NhTnnlIdx : 0 > NhVlan: 6 NhIf : VIDX4095 > NhArpIdx : 138 > Device: 0 > ArpEntry Idx 138 : 00:2b:f0:19:87:01 > Hit/Miss : N > > Notice above a reference to NhArpIdx 138. In order for forwarding to > work correctly, there must be an entry # 138 in the `halp-nh > arp-table.` Since there isn't one, the NhIf shown is VIDX4095, not a > port. However, if you want to verify that there is no NhArpIdx 138 in > the hardware, you can examine the table with `show halp-nh arp-table` > and scroll down to where # 138 should be. You won't find it! > > PFEM0(vty)# show halp-nh arp-table > Device: 0 > ... lots of scrolling ... > ArpEntry Idx 136 : 00:18:8b:f8:b6:6e > ArpEntry Idx 137 : 00:0e:b6:2d:01:a0 > ArpEntry Idx 139 : 00:19:b9:f9:24:2a > ArpEntry Idx 140 : 78:2b:cb:3c:91:60 > > How do you get the switch to populate that entry? Well, since `clear > arp` on the EX4200 doesn't actually do what it is supposed to do, what > we have been doing in the past is deleting whole subnets, impacting > potentially many machines, and then re-adding them. This is not good > but it does work. > > Our new solution is much better. We just add a bogus static arp entry > for 192.0.2.2, pointing to some made-up MAC address, and then we > commit, roll back, and commit again. Like magic, the ARP entry will > re-populate correctly. Almost as if you really did have a `clear arp` > command on the EX4200, one that worked right! > > After adding and then deleting the bogus static ARP for 192.0.2.2 you > can re-examine the PFE and see the results. Also, your customer's > Internets will begin working correctly again. > > I hope this helps. > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > > ___ > 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] EX4200 missing ARP entry work-around
We have decided on a better work-around for our missing ARP entry
problems on the EX4200 and friends.
As you may recall, the EX4200 will sometimes have an ARP entry in the
control-plane, but it will not be present in the data-plane. You can
investigate by checking your destination IP address with the command
`show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32`
which will produce output like this:
PFEM0(vty)# show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32
RouteType Paths RtIdx Rpf SipSa Row:Col:Row:Col
- - --- - ---
192.0.2.2 ECMP 0 2037 No No439:0:0:0
Dev0 (RtIdx:2037)
-
Command : Route CpuCode: 3
AppSpCpuCodeEn: 0 UcSipFiltEna : 0
TtlDecEna : 1 TtlOptChkBypass: 0
IngressMirror : 0 QoSProfileEn : 0
QoSProfileIndex : 0 QoSPrecedence : 1
ModifyUp : 2 ModifyDscp : 0
CounterSet: 2 ArpBc2Cpu : 0
SipAccessLevel: 0 DipAccessLevel : 0
IcmpRedirExpnMirr : 0 MtuProfileIdx : 2
Ipv6ScopeCheckEn : 0 Ipv6DstSiteId : 0
NhTnnl: 0 NhTnnlIdx : 0
NhVlan: 6 NhIf : VIDX4095
NhArpIdx : 138
Device: 0
ArpEntry Idx 138 : 00:2b:f0:19:87:01
Hit/Miss : N
Notice above a reference to NhArpIdx 138. In order for forwarding to
work correctly, there must be an entry # 138 in the `halp-nh
arp-table.` Since there isn't one, the NhIf shown is VIDX4095, not a
port. However, if you want to verify that there is no NhArpIdx 138 in
the hardware, you can examine the table with `show halp-nh arp-table`
and scroll down to where # 138 should be. You won't find it!
PFEM0(vty)# show halp-nh arp-table
Device: 0
... lots of scrolling ...
ArpEntry Idx 136 : 00:18:8b:f8:b6:6e
ArpEntry Idx 137 : 00:0e:b6:2d:01:a0
ArpEntry Idx 139 : 00:19:b9:f9:24:2a
ArpEntry Idx 140 : 78:2b:cb:3c:91:60
How do you get the switch to populate that entry? Well, since `clear
arp` on the EX4200 doesn't actually do what it is supposed to do, what
we have been doing in the past is deleting whole subnets, impacting
potentially many machines, and then re-adding them. This is not good
but it does work.
Our new solution is much better. We just add a bogus static arp entry
for 192.0.2.2, pointing to some made-up MAC address, and then we
commit, roll back, and commit again. Like magic, the ARP entry will
re-populate correctly. Almost as if you really did have a `clear arp`
command on the EX4200, one that worked right!
After adding and then deleting the bogus static ARP for 192.0.2.2 you
can re-examine the PFE and see the results. Also, your customer's
Internets will begin working correctly again.
I hope this helps.
--
Jeff S Wheeler
Sr Network Operator / Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Time-of-day based traffic conditioning
That's pretty cool. Looks like there's some additional knobs as well.
{master}[edit]
jnpr@R1-RE0# set groups dhanks when time 8am to 5pm
{master}[edit]
jnpr@R1-RE0# set groups dhanks when routing-engine re0
{master}[edit]
jnpr@R1-RE0# set groups dhanks snmp community dhanks authorization
read-only
{master}[edit]
jnpr@R1-RE0# set apply-groups dhanks
{master}[edit]
jnpr@R1-RE0# show snmp
{master}[edit]
jnpr@R1-RE0# show snmp | display inheritance
'dhanks' was inherited from group 'dhanks'
##
community dhanks {
##
## 'read-only' was inherited from group 'dhanks'
##
authorization read-only;
}
{master}[edit]
jnpr@R1-RE0# show snmp | display inheritance when time 6pm
{master}[edit]jnpr@R1-RE0#
Thank you,
--
Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks
On 1/10/12 11:28 PM, "Phil Shafer" wrote:
>Dale Shaw writes:
>>Does anyone know of a way to enforce traffic policing or shaping based on
>>time of day?
>
>Beginning in 11.3, config groups have a "conditional application"
>mechanism, so they are only applied on certain products/models or
>at certain time of day ranges.
>
>I'll admit I've never used it, but it's a generic mechanism built
>into configuration groups to handle time-of-day-based configuration:
>
>[edit]
>cli# show groups tod
>when {
>time 02:00 to 03:00;
>}
>system {
>host-name in-the-maint-window;
>}
>
>Annoyingly, I can find no documentation on it, but it's not hidden.
>Google("junos configuration groups when") is not helpful. A snippet
>of internal documentation is appended. If I find more, I'll post it.
>
>I know it uses our getdate() common function, so "2am" == "02:00".
>
>Thanks,
> Phil
>
>
>--
>2.3.5 TIME
>
>This identifies, when this particular config-group needs to be applied on
>the
>router. It takes start time and optional end time as values. If end time
>is
>specified, the applied config-group will be removed at the specified end
>time.
>This will happen everyday on the specified time. If start time is relative
>time e.g, "11am" and end time is not specified, end time will be taken as
>EOD.
>If start is absolute time, the applied configuration will remain, unless
>the
>config-group start time is modified.
>
>The syntax for specificing the time:
>
>time [to ];
>
>The time format is -mm-dd.hh:mm (type time).
>(Relative has just hh:mm, if 12 hours clock is used, it is needed to
>specify
>am/pm.)
>
>Example:
>
>groups {
>my-group-1 {
>// Config-group statements
>when {
>time 11:00 to 15:00;
>}
>}
>}
>
>The config-group 'my-group-1' config statements will be applied at 11 AM
>and
>will be removed at 3 PM daily.
>___
>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] Time-of-day based traffic conditioning
Dale Shaw writes:
>Does anyone know of a way to enforce traffic policing or shaping based on
>time of day?
Beginning in 11.3, config groups have a "conditional application"
mechanism, so they are only applied on certain products/models or
at certain time of day ranges.
I'll admit I've never used it, but it's a generic mechanism built
into configuration groups to handle time-of-day-based configuration:
[edit]
cli# show groups tod
when {
time 02:00 to 03:00;
}
system {
host-name in-the-maint-window;
}
Annoyingly, I can find no documentation on it, but it's not hidden.
Google("junos configuration groups when") is not helpful. A snippet
of internal documentation is appended. If I find more, I'll post it.
I know it uses our getdate() common function, so "2am" == "02:00".
Thanks,
Phil
--
2.3.5 TIME
This identifies, when this particular config-group needs to be applied on the
router. It takes start time and optional end time as values. If end time is
specified, the applied config-group will be removed at the specified end time.
This will happen everyday on the specified time. If start time is relative
time e.g, "11am" and end time is not specified, end time will be taken as EOD.
If start is absolute time, the applied configuration will remain, unless the
config-group start time is modified.
The syntax for specificing the time:
time [to ];
The time format is -mm-dd.hh:mm (type time).
(Relative has just hh:mm, if 12 hours clock is used, it is needed to specify
am/pm.)
Example:
groups {
my-group-1 {
// Config-group statements
when {
time 11:00 to 15:00;
}
}
}
The config-group 'my-group-1' config statements will be applied at 11 AM and
will be removed at 3 PM daily.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
