Group,
For about 2 years now our upstream provider has had an access-list in place
on their router (Cisco 7500 series) to prevent unwanted traffic choking our
thin 64 Kbps link.
It looked like this; (IP's are an example).
access-list 101 permit ip any host 202.298.224.1
access-list 101 permit ip any host 202.198.224.2
access-list 101 permit ip any host 202.198.224.65
access-list 101 permit ip any host 202.198.224.66
access-list 101 permit ip any host 202.198.224.68
access-list 101 permit ip any host 202.198.224.70
access-list 101 permit ip any host 202.198.224.72
access-list 101 permit ip any host 202.198.224.129
access-list 101 permit ip any host 202.198.224.130
access-list 101 permit ip any 202.198.225.0 0.0.0.63
access-list 101 deny ip any any
After maintenance to their router last Sunday I have been seeing traffic to
all the IP's in the 202.198.224.0/23 range. About 30 emails to their 'help
desk' later, they are proposing the following; (They still haven't
explained why the original access-list is either missing or not working!)
***********************************************
The approach of static route protection is shown as follows
Ip route 203.98.224.0/24 null 0
Ip route 203.98.225.0/25 null 0
Announce the ip blocks, 203.98.224.0/24 and 203.98.225.0/24 to internet
Ip route 202.198.224.1/32 intf xxx 34..59.127.38
Ip route 202.198.224.2/32 intf xxx 34.59.127.38
Ip route 202.198.224.65/32 intf xxx 34.59.127.38
Ip route 202.198.224.66/32 intf xxx 34.59.127.38
Ip route 202.198.224.68/32 intf xxx 34.59.127.38
Ip route 202.198.224.70/32 intf xxx 34.59.127.38
Ip route 202.198.224.72/32 intf xxx 34.59.127.38
Ip route 202.198.224.129/32 intf xxx 34.59.127.38
Ip route 202.198.224.130/32 intf xxx 34.59.127.38
Ip route 202.198.225.0/26 intf xxx 34.59.127.38
**********************************************
As I've had no experience with this approach I'd appreciate if someone can
let me know if this will work.
Thanks,
Jon
Colleagues,
Some in the group had asked about fellowship opportunities to attend APRICOT
2005. The last day for this second round fellowship applications is 20
December.
To apply on-line visit http://www.2005.apricot.net/fellowship.html
The fellowship does not cover travel, so before applying it would help to
discuss/confirm travel support with your organisation.
Regards and best wishes for the festive seasons
Save
--
Savenaca VOCEA | Research & Liaison Officer(Pacific)
| APNIC Secretariat
Email: save(a)apnic.net | PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3107 | Australia
Fax: +61 7 3858 3199 | http://www.apnic.net
Hi can anyone suggest some CIDR block static routes for ARIN networks?
We have just set-up a second (to Optus) duplex IP circuit via NewSkies IPsys
and just want to put a couple of static routes for outbound from Honiara
traffic into our Cisco international gateway router to test things out while
we organise an AS number and set-up BGP.
The current default route for all outbound traffic from Honiara is via
Optus, inbound traffic may be via Optus, PanAmSat or now NewSkies via static
routes advertised by our peers.
Any suggestions for some routes to cover IP address space aggregations that
are mainly USA bound?
Alternatively we could try to route the larger AU ISPs via Optus and the
rest via NewSkies, if that is seen to be easier.
Regards to all,
Mark.
Mark Flynn
Manager Information Systems (Internet Services)
Solomon Telekom Company Ltd.
AU-GSM: + 61 438 395 977
TEL: +61 3 9844 0189
FAX: +61 3 9844 0189 (Currently in Australia)
Email: <mailto:mark.flynn@telekom.com.sb> mark.flynn(a)telekom.com.sb
Hi everyone,
This is to let you know that the registration for APRICOT 2005 in Kyoto,
Japan, from 18th to 25th February 2005 is now open. APRICOT is the Asia
Pacific region's Internet operations and technology conference, and
consists of workshops, tutorials, conference, as well as the 6 monthly
APNIC meeting.
Full information about APRICOT 2005 can be had at www.2005.apricot.net.
Registration and accommodation information is at:
www.2005.apricot.net/registration.htmlwww.2005.apricot.net/accommodation.html
You are encouraged to register as soon as possible as the early bird
registration discount finishes on the 12th of January.
Hope to see you in Kyoto early next year!
philip
--
Hello,
I'm just forwarding this in case its of interest.
Save.
---------- Forwarded message ----------
Date: Thu, 2 Dec 2004 14:39:01 +1000
From: David J. Hughes <bambi(a)Hughes.com.au>
To: Oz-ISP Mailing list <aussie-isp(a)aussie.net>,
isp-australia(a)isp-australia.com
Subject: [Oz-ISP] IOS and Growing BGP tables
Hi,
I'm posting this in an attempt to raise a bit of support. I've been
arguing for a feature enhancement for IOS that will prolong the life of
most Cisco routers that take a full BGP table. The growth of the table
is causing concern for many major providers who can see the RAM on
their lower end 7200's running out in the near future. Their default
solution is not to upgrade the boxes, but to filter out the /24
advertisements.
However, for many years in Australia, a /24 was the normal allocation.
If they blindly filter out all the /24's then lots of networks in
Australia (and other countries) will become unreachable. The proposed
features allows you to filter a prefix if there is a less specific
prefix already in your table (with various tuneable knobs with respect
to next hop etc).
Some guys at Cisco have taken this on and filed a bug / feature request
for this. The more people that open a TAC case and have it linked to
this bug ID the higher the priority of this request will become. It's
being supported on the Cisco-NSP mailing list but I thought it worth
"rattling the cage" on these lists as well. The more voices the
better.
The Cisco Bug ID is "CSCsa45474 : Ability to block overlapping BGP
prefixes from being installed in RIB". Some history of the discussions
is included below. If you have a TAC account and are so inclined,
please open a new case and ask the engineer to link it to this bug ID.
Thanks
Bambi
...
Begin forwarded message:
> From: David J. Hughes <bambi(a)Hughes.com.au>
> Date: 1 December 2004 10:26:18 AM
> To: 'cisco-nsp' <cisco-nsp(a)puck.nether.net>
> Subject: Re: [c-nsp] Growing BGP tables
>
>
> I hope that most people on this list would open a case to try to get a
> feature like this included in upcoming IOS releases. It's about the
> only thing that will extend the life of your "RAM limited" routers
> without breaking connectivity to historically legitimate /24
> allocations.
>
>
> David
> ...
>
>
> On 01/12/2004, at 9:40 AM, Rodney Dunn wrote:
>
>> For those that have the ability to open a TAC case and they think
>> this is something they could use, open a case and have the TAC
>> engineer attach the case to this bug:
>>
>> CSCsa45474
>> Externally found enhancement defect: New (N)
>> Ability to block overlapping BGP prefixes from being installed in RIB
>
------
Begin forwarded message:
Anything that reduces the consumption of RIB and
FIB resources as a result of de-aggregation etc
would be a very welcome step in the right
direction. Thanks for looking into this
Rodney.
David
...
On 24/11/2004, at 3:33 AM, Rodney Dunn wrote:
> My point was that you can't do it with BGP
> because you don't have a way to request a
> re-advertisement from a peer when the
> less specific goes away.
>
> There is a possiblity we could keep the
> more specifics out of the RIB which would
> save memory there and in the FIB.
>
> That being said the best that can
> be done currently appears to block
> the routes from going in the RIB.
> We are looking to see how complex that
> would be to do.
>
> Rodney
>
>
> On Tue, Nov 23, 2004 at 11:11:52AM -0600, Brian Feeny wrote:
>>
>>
>> I like this, basically all your doing is getting rid of the redundant
>> information which serves no purpose other than taking up space in the
>> RIB/FIB anyways. And if someone should further deaggregate or make a
>> change, then the new update is going to run its algorithm against the
>> current RIB all over again.
>>
>>
>> On Nov 22, 2004, at 4:16 PM, David J. Hughes wrote:
>>
>>>
>>> Hey Rodney,
>>>
>>> How about ...
>>>
>>> for each prefix received in update
>>> for each more specific prefix in RIB
>>> if RIB prefix ge /24 and same next hop as update prefix
>>> drop RIB prefix
>>> if update prefix ge /24
>>> for each less specific prefix in RIB
>>> if RIB next hop same as update next hop
>>> drop update prefix
>>>
>>> something like that would filter during the update and wouldn't
>>> require another full copy of the table to be held. I'm sure you
>>> guys could come up with something more efficient but the basic idea
>>> would work wouldn't it?
>>>
>>>
>>> David
>>> ...
----
email "unsubscribe aussie-isp" to majordomo(a)aussie.net to be removed.
