On Wednesday 15 April 2009 11:09:18 am Stacy W. Smith wrote:
> There's a difference between a final term of:
>
> term foo {
> then accept;
> }
>
> and the protocol-specific implicit default policy. In the
> case of BGP, the default policy is equivalent to:
>
> policy foo {
> term bar {
>
On Apr 14, 2009, at 8:53 PM, Mark Tinka wrote:
On Wednesday 15 April 2009 10:19:24 am Stacy W. Smith wrote:
Are you certain you don't see this same behavior for an
IPv4 BGP export policy?
Yes, perhaps that's the bug :-). I'll take a closer look at
it and figure out what's going on. We only h
Are you certain you don't see this same behavior for an IPv4 BGP
export policy? I believe what you describe is the expected behavior
and is consistent across all (or at least most) applications of
routing policy on JUNOS.
--Stacy
On Apr 14, 2009, at 5:47 PM, Mark Tinka wrote:
Hi all.
W
On Wednesday 15 April 2009 10:19:24 am Stacy W. Smith wrote:
> Are you certain you don't see this same behavior for an
> IPv4 BGP export policy?
Yes, perhaps that's the bug :-). I'll take a closer look at
it and figure out what's going on. We only have one or two
of these policies. It's more th
This is a 1 hop lsp, right? VPN traffic should arrive with a vrf label,
and I would assume be considered mpls. Regular inet will ingress as IP
due to php.
Are you using vrf-table? If so, the vrf is popped at ingress, resulting
in an Ip lookup.
That may explain it.
Regards
-Original Mes
Hi all.
We recently experienced a situation where an M7i (JunOS
9.4R1.8), on which we applied an export policy for a v6 BGP
session, was leaking more v6 routes than it should have
been.
We realized that if the final term in the BGP policy was
'accept', not only did the router export the BGP v
I tried the same mpls filter on the PE2 ingress direction, which is
ge-1/3/0, traffic is from CE1 to CE2, still no mpls counters change. any
comment?
On Tue, Apr 14, 2009 at 6:19 PM, Harry Reynolds wrote:
> I've seen this behavior and believe its expected.
>
> At ingress the packet is handled as
I've seen this behavior and believe its expected.
At ingress the packet is handled as an Ip packet. The route is looked
up, which would then possibly link to an egress firewall of family inet.
After executing any inet filter code the route lookup is performed,
assuming the filter accepts the pack
Hi all,
I've just got a MPLS filter problem which I couldnt find reason. I'm quite
new to Junos
so it might be something I miss hope someone could shed a light.
a typical Layer 3 vpn setup:
CE1-PE1(ge-1/3/0)-(ge-1/3/0)PE2CE2
CE1 lo0:1.1.1.1/32
CE2 lo0:2.2.2.2/32
vpn name: vpn-a
Feeling compelled to add...
"If clearing if your bag, but rebooting is a drag"
Then why not use the syslog action modifier? IIRC, this get past the
400 entry limit, allows remote logging, persist through reboots (may be
useful if a DDoS attack lead to a reboot, as now you can do forensics
rather
Some are subscribing to this positionmoreover; it appears a reboot
clears a lot more than just logging. I am looking into our own product
flexibilities.
Jay Murphy
IP Network Specialist
NM Department of Health
ITSD - IP Network Operations
Santa Fe, New Mexico 87502
Bus. Ph.: 505.827.2851
This is output from show interfaces :
RouterA> show interfaces ds-0/1/6:4
Physical interface: ds-0/1/6:4, Enabled, Physical link is Up
Interface index: 261, SNMP ifIndex: 265
Description: *** Customer A ***
Link-level type: PPP, MTU: 1504, Clocking: Internal, Speed: 256kbps,
Loopback: None,
Can you please show us an example.? It will help to understand the problem
better.
Thanks,
Nilesh
On Apr 14, 2009, at 2:16 AM, "Faizal Rachman"
mailto:faizal...@gmail.com>> wrote:
Sorry if you got this message twice, iam worried there something error with
last mail.
On Mon, Apr 13, 2009 a
Sorry if you got this message twice, iam worried there something error with
last mail.
On Mon, Apr 13, 2009 at 11:09 AM, Faizal Rachman wrote:
> Dear All,
> What is cause different MTU size on logical interface while there is
> on same physical interface.
> It happen on channelized E1 IQ without
That is correct; sorry I should have mentioned.
So far, the only way I managed to clear it was reboot :-(
Thanks,
bit.
On Tue, 2009-04-14 at 14:39 +1000, Truman Boyes wrote:
> This appears to be the PFE firewall on a M/T/MX series
>
>
> On 14/04/2009, at 4:49 AM, Murphy, Jay, DOH wrote:
>
15 matches
Mail list logo
