Activity Summary
- 6669 days inactive
- 6669 days old
- pacnog@pacnog.org
- 2 participants
- 3 comments
j
: Next unread message k
: Previous unread message j a
: Jump to all threads
j l
: Jump to MailingList overview
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
Hi Jon,
Jon Leeman wrote:
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!)
Mmmm, I guess they read somewhere that these ACLs were slowing down the router too much? If they were using any reasonably modern IOS, they'd have access to compiled ACLs which show minimal impact on the router CPU.
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.
This will work fine too...
Basically they are null routing your aggregate, and then putting specific entries in the forwarding table for the host IP addresses you are actually using. So making use of the null interface's fast drop capability for traffic going to destinations you don't use. This should be more efficient than using the ACLs they had before.
philip --
Philip,
Mmmm, I guess they read somewhere that these ACLs were slowing down the router too much? If they were using any reasonably modern IOS, they'd have access to compiled ACLs which show minimal impact on the router CPU.
Possibly. When Bigpond was running the router before Reach, my contact in Sydney said this particular router's processor was running at about 30%.
My main beef with them is that they dropped the access-list without notification and it's taken them 6 days to do something about it. Unfortunately we don't have the facility (read dollars) to change providers at this time.
Many thanks for your input.
Jon
Hi Jon,
Jon Leeman wrote:
Possibly. When Bigpond was running the router before Reach, my contact in Sydney said this particular router's processor was running at about 30%.
Mmmm, 30% is hardly challenging at all. My general rule is to start worrying at around 60%, and researching what might be the issue at around 70%.
My main beef with them is that they dropped the access-list without notification and it's taken them 6 days to do something about it. Unfortunately we don't have the facility (read dollars) to change providers at this time.
I don't blame you. Very unprofessional of them, sadly.
philip --