Hi all
Is it possible to configure router with ::/0 same way as hosts are configured
with IPv6 stateless autoconfiguration ?
This is what i would like to achieve:
R1 --- R2
I have eBGP between R1 and R2. I can advertise only one ipv6 prefix (but not
::/0) to R2 and i can not configure R2.
Last email about defaults, I swear. :)
I have two routers that have some feeds to providers. I don't want them to
be advertising the default atomic aggregate I'm generating to downstream
devices when it doesn't have the connectivity to back it up.
Whats the best way to do this? I consider taking
On 8 nov. 2012, at 09:53, Morgan McLean wrote:
Last email about defaults, I swear. :)
I have two routers that have some feeds to providers. I don't want them to
be advertising the default atomic aggregate I'm generating to downstream
devices when it doesn't have the connectivity to back it
On (2012-11-08 00:53 -0800), Morgan McLean wrote:
I'd like to be able to do it based on BGP state...
Any tips?
You probably already generate your PA routes from some central core boxes.
Advertise one of these PA routes and have static default route point to it.
If edge loses connectivity to
Here is the port config:
le...@agg1.pgt show configuration interfaces ge-1/1/4
description UGW9811 2/1/1 for MTU testing;
unit 0 {
family inet {
mtu 1500;
address 10.2.0.241/28;
}
}
le...@agg1.pgt
le...@agg1.pgt show configuration routing-instances s1u
instance-type
Hello,
Is Juniper's implementation of next-hop self on a RR a violation of
RFC1966?
In some implementations, modification of the BGP path attribute,
NEXT_HOP is possible. For example, there could be a need for a RR to
modify NEXT_HOP for EBGP learned routes sent to its internal peers.
In my mind, the default is fine. It is consistent with normal behavior
and there are times when a shared policer would be desired. The lack of
a instance specific option though, that is stupid beyond belief,
shocking surprise.
To me the biggest problem is, you cannot know if instance
On Thu, Nov 08, 2012 at 05:45:25PM +0200, Mihai Gabriel wrote:
Is Juniper's implementation of next-hop self on a RR a violation of
RFC1966?
In some implementations, modification of the BGP path attribute,
NEXT_HOP is possible. For example, there could be a need for a RR to
modify
With other platforms next-hop-self is applied as a bgp attribute in
the configuration of the process. When that's done, they usually
follow the RFC faithfully in that regard. However upon applying
outbound policy the next-hop attribute is allowed to be modified. To
me, modification of the
Hi
I’ve an MX5 peering PIM with a Cisco
6500, Cisco 6500 is also acting as RP with bootstrap-rp.
Unfortunately my MX5 is not dynamically
learning the rp ip address , do I’ve to specify something to do that in MX5 ?
I wondering since with PIM peering I
expect it working without any
Yes, it's a violation of RFC 1966, but RFC 1966 is obsoleted by RFC 4456.
RFC 4456 now includes the wording:
In addition, when a RR reflects a route, it SHOULD NOT modify the
following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
Their modification could potentially result in
If I follow, then no, a Juni router will not process and act upon the contents
of a received RA. It will generate them for use by hosts in auto-conf. As I
understand, Juniper sees auto-conf as a process used by dumb hosts and not one
that is designed for what should be a smart router.
I
12 matches
Mail list logo
