Hi,
thanks for all info but with my 11.4R7.5 I cannot implement the check.
Regards,
Marco
2014-03-07 20:47 GMT+01:00 Pedro Cavaca :
>
>
>
> On 7 March 2014 19:44, Pedro Cavaca wrote:
>
>>
>>
>>
>> On 7 March 2014 19:26, Michael Loftis wrote:
>>
>>>
>>> http://www.juniper.net/techpubs/en_US/j
On 3/7/14 5:12 PM, "Meshier, Brent" wrote:
>Level3 won't let us advertise our netblock because RADB shows it owned by
>Telkom South Africa, but it's clearly assigned to us by ARIN. I've
>raised a question with ARIN, could really use someone there that could
>expedite. On that note, when ARIN re
On 3/7/2014 5:03 AM, Rob Seastrom wrote:
for decades. i have a vague recollection of an rfc that said
secondary nameservers ought not be connected to the same psn (remember
those?) but my google fu fails me this early in the morning.
Packet Switch Node?
Not sure what would be in this context
"...That's what ARIN is telling us. They correct their Routing Registry, ours
will change to match"
You are getting caught into a loop here
May I suggest that you take a closer look at the RADB record and determine
which registry it was created by.
Your earlier statement implied that the
> Level3 won't let us advertise our netblock because RADB shows it owned by T=
> elkom South Africa, but it's clearly assigned to us by ARIN. I've raised a=
> question with ARIN, could really use someone there that could expedite. O=
> n that note, when ARIN re-assigns networks, shouldn't they c
On 07/03/14 14:23, Meshier, Brent wrote:
> Already spoke to Merit, their response "That's what ARIN is telling us. They
> correct their Routing Registry, ours will change to match"
What does the source attribute on the object say? If it's RADB then
Merit should be able to help you get the objec
Already spoke to Merit, their response "That's what ARIN is telling us. They
correct their Routing Registry, ours will change to match"
--Brent
-Original Message-
On 07/03/2014 22:12, Meshier, Brent wrote:
> Level3 won't let us advertise our netblock because RADB shows it owned
> by Te
On 07/03/2014 22:12, Meshier, Brent wrote:
> Level3 won't let us advertise our netblock because RADB shows it owned
> by Telkom South Africa, but it's clearly assigned to us by ARIN. I've
> raised a question with ARIN, could really use someone there that could
> expedite. On that note, when ARIN
Level3 won't let us advertise our netblock because RADB shows it owned by
Telkom South Africa, but it's clearly assigned to us by ARIN. I've raised a
question with ARIN, could really use someone there that could expedite. On
that note, when ARIN re-assigns networks, shouldn't they clear out re
BGP Update Report
Interval: 27-Feb-14 -to- 06-Mar-14 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS982952218 1.9% 35.4 --
2 - AS755249007 1.8% 38.3 --
3 - AS2957
This report has been generated at Fri Mar 7 21:13:49 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date
On Fri, Mar 7, 2014 at 12:52 PM, Randy Bush wrote:
>> I think you have the right of it. That the recipient elects only to
>> use the link for a limited set of destinations is an ordinary part of
>> transit service. In Randy's example, a peering link was converted to a
>> transit link on a short te
On 7 March 2014 19:44, Pedro Cavaca wrote:
>
>
>
> On 7 March 2014 19:26, Michael Loftis wrote:
>
>>
>> http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html
>>
>> There's no backref s
On 7 March 2014 19:26, Michael Loftis wrote:
>
> http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html
>
> There's no backref support in the regex subset that juniper has chosen
> to im
http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html
There's no backref support in the regex subset that juniper has chosen
to implement, see
http://juniper.cluepon.net/index.php/ER_Det
Hi Everyone,
I need a help to transform this Cisco IOS command:
ip as-path access-list 50 permit _([0-9]+)_\1_\1_
in Juniper JUNOS policy-options.
Best regards,
Marco
M. +39 348 6019349
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.
Daily listings are sent to bgp-st...@lists.ap
> I think you have the right of it. That the recipient elects only to
> use the link for a limited set of destinations is an ordinary part of
> transit service. In Randy's example, a peering link was converted to a
> transit link on a short term basis.
you know the term?
On 3/8/2014 午前 01:07, Jason Lixfeld wrote:
I don't need to use it much, but when I do, it's an ever-increasing royal pain
in the ass.
My current plight revolves around not being able to get full dumps of objects.
Certain mandatory fields in objects are 'filtered' and/or replaced with dummy
d
On Mar 7, 2014, at 12:01 PM, Koch, Andrew wrote:
> You will notice right at the top of the output there is a hint on getting an
> unfiltered object. Try using the -B flag on your query to get around this.
Indeed, however that doesn't help with the dummy objects that also make it
impossible t
> -Original Message-
> From: Jason Lixfeld [mailto:ja...@lixfeld.ca]
> Sent: Friday, March 07, 2014 10:07
> To: NANOG
> Subject: Who uses ARIN's IRR?
>
> I don't need to use it much, but when I do, it's an ever-increasing royal
> pain in the ass.
>
> My current plight revolves around not
On Fri, Mar 7, 2014 at 11:18 AM, Siegel, David wrote:
> Having been employed by a provider V in one such example of the below,
> I viewed it as a temporary, partial transit relationship. Does such a
> situation meet Bill's original definition?
Hi David,
I think you have the right of it. That th
Having been employed by a provider V in one such example of the below, I viewed
it as a temporary, partial transit relationship. Does such a situation meet
Bill's original definition?
-Original Message-
From: Randy Bush [mailto:ra...@psg.com]
Sent: Thursday, March 06, 2014 7:42 AM
To:
I don't need to use it much, but when I do, it's an ever-increasing royal pain
in the ass.
My current plight revolves around not being able to get full dumps of objects.
Certain mandatory fields in objects are 'filtered' and/or replaced with dummy
data. This poses a problem because one can no
-- Forwarded message --
From: Miwa Fujii
Date: Fri, Mar 7, 2014 at 2:36 AM
Subject: [menog] APRICOT2014 Archives
To: "me...@menog.org"
Hi MENOG members,
APRICOT2014 is over now and archived materials are available in:
https://2014.apricot.net/program
As usual, there were lots
A few observations for this Friday.
--
We where finally able to register our NS IPv6 with NetSol and I just
noticed IPv6 DNS Reflection Attempts (*) starting a few days after.
* By attempts, they could also be probes from projects, but they need to
be pretty aggressive to end up list
bmann...@vacation.karoshi.com writes:
> sorry for the poor attempt at humour...
> it was ancient practice to hang many names (not cnames)
> off a single IP address. all perfectly legal from a DNS POV.
>
> rs.example.org. in a 10.10.10.53
> nick.example.com. in a 10.10.10.53
> bb
On Thu, Mar 06, 2014 at 08:07:55AM -0500, Rob Seastrom wrote:
>
> Nick Hilliard writes:
>
> >>haven't you heard about "anycast"??
> >
> > rs probably has. The owner of 199.73.57.122, probably not.
>
> indeed. there are many pieces of evidence that this is not an anycast
> prefix. proof i
28 matches
Mail list logo