Sounds like you are doing 6VPE if you have an interface on the PE
facing the CE inside a VRF.
You need:
- family inet6 on the EBGP inside the VRF facing the customer.
Assuming your CE want to teach you ipv6 routes via EBGP.
- family inet6-vpn on the IBGP between the PE's in the core.
- You
I have no configs go hand but have done with VPLS with J and C no problem.
Can you post the following?
show bgp sum and show bgp neighbor for peering with the huawei PE
in question. I assume you peer directly with the huawei and not via a
RR?
show conf routing-instance for vpls instance
show
Chances are his lsp to remote PE is up as he has the following route
his is pinging active in his vrf.
10.10.2.0/24 *[BGP/170] 05:27:25, localpref 100, from 10.2.0.1
AS path: I
to 172.16.150.1 via ge-0/0/1.0, Push 16, Push
299808(top)
If the
://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
This can be seen on BGP routes in general. I remembered some wierdness
with respect to 1 complements and google turned up the following.
https://www.juniper.net/techpubs/software/junos/junos91/swcmdref-protocols/show-route-detail.html
In order to use common comparison routines, JUNOS software
static routes?
Any help will be greatly appreciated..
Regards
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
interfaces. Not sure which one is
ugly and not useable at the moment. But would love to hear from you guys...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
will see if that fixes it.
I doubt that'll fix your issue...but who knows :)
-chris
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
If you can find a counter for the vcp throughput then you can populate
the utility mib with the value and snmp poll and graph it.
http://www.juniper.net/techpubs/en_US/junos10.3/topics/task/operational/snmp-best-practices-utility-mib-using.html
That said for all I know there might be a
.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
extended-vlan-vpls encap should forward TPIDs 0x8100, 0x9100, and 0x9901
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
As Stefan mentions one logical unit must to belong to one routing
instance. But you can play (ugly) games with rib groups and interface
routes. The newer instance import policies feature should work for non
VRF instance as well but I only implemented it with RIB groups so far.
The logical unit
://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
behaviour?
Thanks,
Tom
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman
Interestingly you see a hidden route if the static route does a
recursive lookup. See config below and then show route output. The
nexthop interface for 10.0.21.2 is down when the below was executed.
This seems to show that at commit time , unless a static is set to
resolve via indirect
Are you mixing up MTU and TCP MSS (Maximum Segment Size), a MSS is not
MTU but can cause MTU issues.
Also beware mixing up JUNOS protocol bgp mss adustment, which are only
for the routers bgp tcp sessions with general MSS rewrite.
The general mss rewrite affects all tcp syns crossing the box.
Your right but the customer never enjoys being told it could be
dangerous to give them that power :-)
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
: 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
--
Phill Jolliffe
___
juniper
Not the first time I've been told my proposition is technically
possible but to to ugly to execute ;-)
Phill
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Need to be careful when describing the formula. local/remote site id
means varies depending on perspective.
for example:
PE-A, (connected to customer site id 1), advertises a label base of
1000, range of 4 and offset of 1
This route is received by remote PE-B that has another sight in the
same
://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
but the results are identical for
100g MBS as the rest of the lines in the file).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
{
members xx;
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper
/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
All good things come to those who wait :-)
http://tools.ietf.org/html/draft-ietf-mpls-ldp-p2mp-08
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
://puck.nether.net/mailman/listinfo/juniper-nsp
--
Phill Jolliffe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
The cfeb computes/compiles the jtree that will be stored in the in the
sram. Presumably this means the raw forwarding table has to be stored
in the cfeb.
The 'show route summary' command (on the cfeb not the normal RE CLI)
shows this.
CSBR0(London-AMS1 vty)# show route summary
IPv4 Route
30 matches
Mail list logo