- Test - lists.nanog.org

Dynamic routing through firewall
by Cliff Bowles 21 Nov '13

21 Nov '13

Request for feedback... We have a need for an external partner to dynamically advertise their network to us in two separate data centers. The hitch is that, touching external partners, our edge routers for B2B partners reside in DMZs. Now, to ensure failover from one data center to another when there is a link/device problem, we need to pass dynamic routing updates through each DMZ firewall to core routing at each data center. (yes, the data centers are in sync via backbone routing) We have multiple B2B peers, so we have multiple VRFs on the edge routers that all need to talk to our core routing, but not necessarily with each other... so we are on the hook for both the routing of these tenants as well as the security inspection. The 4 common options we've considered: 1. Routing through the firewall across a tunnel: Pro - relatively simple, Con - occasional MTU issues and the firewalls may not be able to disassemble/reassemble the tunnel packets for policy inpsection. 2. Transparent firewalling: Pro - extremely easy, Con - some vendors cannot support stateful failover in HA pairs, some won't do stateful at all, so you need to open up rules bidirectional (i.e. reply ports GT 1024), plus all the whizbang IDS/IPS goes out the window along with NAT and other stuff, so it will be a very point solution 3. BGP on the firewall: Pro - moderately easy unless the policies get very sophisticated, and firewalls automatically learn where prefixes are automatically; Con - it's BGP on the firewall... neither the network or the security teams are thrilled about it, support calls tend to loop in both teams, a security guy can cause a lot of problems with human error, we've seen some firewalls with memory leak vulnerabilities and experienced issues in the past 4. BGP through the firewall (multihop): Pro - easy to configure, doesn't require routing on the firewall; Con - for every prefix our upstream edge router advertises to our core, we will need statics in the firewall to make sure that it knows where to forward. We can do a default pointing to the edge router with some large summaries pointing back inside (or wherever), but you get the point - the more prefixes that aren't covered by the default, the less scalable it becomes 5. Firewall on a stick: This is untested, but the idea was floated that we could peer the edge router with our core router, but have Policy-routes on every customer VRF setting the next-hop as the firewall. The firewall will apply policy, and (like option 4) use statics to forward to the core. Reverse path traffic would pretty much do the same from Core-to firewall-to edge. It sounds ugly, and we haven't tested it, but we didn't want to toss it. A lot of you work in multi-tenant environments, and some of you are responsible for the security between tenants. I'd like to hear alternatives, if you know of any. And if you use one of the options I mentioned, please say why you chose it and how it works. Finally, if you tried one of the options and it was terrible, please explain. Thanks in advance! CWB ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

2 1

Looking for a Charter Backbone Engineer
by Dylan Ebner 20 Nov '13

20 Nov '13

If there is a Charter backbone engineer on the list could you email me off list. I am having a peculiar issue with a charter connection and support can't seem to figure it out. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner(a)crlmed.com<mailto:dylan.ebner@crlmed.com> www.consultingradiologists.com<http://www.consultingradiologists.com/>

1 0

Opinions on Fortinet?
by David Hubbard 19 Nov '13

19 Nov '13

Anyone used Fortinet hardware, ideally in both a dual stack and clustered/HA setup, want to share their opinions/experiences with me off list? Looking at some of their stuff. Thanks, David

1 0

Question on routing of Tata AS6453 with their other network AS4755
by Anurag Bhatia 18 Nov '13

18 Nov '13

Hello everyone I was looking around and noticed a pretty bad route from DTAG to Tata AS6453 (basically destination was Tata Comm's Indian network on AS4755). I am not able to understand cause for inefficient routing but I am sure I am failing to understand something which is crazy in their IGP. The result is that route from Europe to India is via Europe > US > Singapore > India rather then direct India. There seem to be quite a few prefixes with these problem, but for this mail question, I am picking two prefixes - one which seems to be having good routing. 202.54.82.0/24 has pretty bad routing while 93.183.28.0/24. I see both prefixes have valid route objects and are originated by VSNL AS4755 to Tata AS6453 in India. Now if we compare trace from Tata's own core router say in Paris from their looking glass, I get: Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 202.54.82.1 Tracing the route to RAS55.1.ppppun.vsnl.net.in (202.54.82.1) 1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 300 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 525297 Exp 0] 260 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 260 msec 2 if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec if-3-6.tcore1.L78-London.as6453.net (80.231.130.85) [MPLS: Label 523604 Exp 0] 256 msec if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec 3 if-2-2.tcore2.L78-London.as6453.net (80.231.131.1) [MPLS: Label 728466 Exp 0] 264 msec * if-1-2.tcore2.L78-London.as6453.net <http://if-1-2.tcore2.L78-London.as6453.net> (80.231.130.122) [MPLS: Label 728466 Exp 0] 264 msec 268 msec* * 4 if-20-2.tcore2.NYY-NewYork.as6453.net <http://if-20-2.tcore2.NYY-NewYork.as6453.net> (216.6.99.13) [MPLS: Label 354225 Exp 0] 276 msec 260 msec 260 msec* 5 * if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46) [MPLS: Label 365409 Exp 0] 304 msec if-11-2.tcore1.NYY-NewYork.as6453.net (216.6.99.2) [MPLS: Label 782881 Exp 0] 256 msec 6 if-22-2.tcore2.CT8-Chicago.as6453.net (64.86.79.1) [MPLS: Label 361921 Exp 0] 264 msec 264 msec if-1-2.tcore1.PDI-PaloAlto.as6453.net (66.198.127.5) [MPLS: Label 670352 Exp 0] 256 msec 7 if-11-3.tcore2.PDI-PaloAlto.as6453.net (66.198.144.57) [MPLS: Label 321233 Exp 0] 256 msec if-2-2.tcore2.PDI-PaloAlto.as6453.net (66.198.127.2) [MPLS: Label 321233 Exp 0] 260 msec * 8 if-9-2.tcore1.TV2-Tokyo.as6453.net (180.87.180.18) 280 msec 260 msec 260 msec 9 if-2-2.tcore2.TV2-Tokyo.as6453.net (180.87.180.2) [MPLS: Label 581761 Exp 0] 252 msec 252 msec 252 msec 10 if-6-2.tcore1.SVW-Singapore.as6453.net (180.87.12.109) [MPLS: Label 710034 Exp 0] 248 msec 244 msec 248 msec 11 if-5-2.tcore1.CXR-Chennai.as6453.net (180.87.12.54) 244 msec 272 msec 252 msec 12 180.87.36.10 272 msec 256 msec 272 msec 13 172.31.19.94 272 msec 252 msec 256 msec 14 * * 172.25.83.142 288 msec 15 172.25.83.134 !H * * while for other prefix, route is: Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 93.183.28.1 Tracing the route to 93.183.28.1 1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 519713 Exp 0] 12 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec 2 if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec if-14-2.tcore1.WYN-Marseille.as6453.net (80.231.154.170) [MPLS: Label 302880 Exp 0] 36 msec if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec *3 if-2-2.tcore2.WYN-Marseille.as6453.net <http://if-2-2.tcore2.WYN-Marseille.as6453.net> (80.231.217.2) 12 msec 12 msec 12 msec* 4 80.231.200.26 140 msec 116 msec 116 msec 5 172.31.16.193 148 msec 140 msec 144 msec * 6 115.114.71.133.static-chennai.vsnl.net.in <http://115.114.71.133.static-chennai.vsnl.net.in> (115.114.71.133) [AS 4755] 140 msec 148 msec 140 msec* 7 172.29.209.82 [MPLS: Labels 301664/7167 Exp 1] 148 msec 144 msec 148 msec 8 172.31.35.138 [MPLS: Labels 4831/7167 Exp 1] 152 msec 152 msec 148 msec 9 121.242.126.205.static-chennai.vsnl.net.in (121.242.126.205) [AS 4755] [MPLS: Label 7167 Exp 1] 148 msec * 140 msec 10 121.242.126.206.static-chennai.vsnl.net.in (121.242.126.206) [AS 4755] 140 msec 148 msec 140 msec 11 * * * 12 * * * Now if I focus on best route entry in router for both prefixes, I see following: Bad Prefix: 4755 tv2-tcore1. (metric 16148) from *hk2-core3.* (hk2-core3.) Origin IGP, valid, internal, best Community: Originator: 66.110.10.113 Good Prefix: 4755 wyn-tcore2. (metric 10050) *from wyn-tcore2.* (66.110.10.109) Origin IGP, valid, internal, best Community: Now as I understand Paris router is getting bad prefix from TV2 which is their Tokyo router while for other prefix with good routing, route is via their other router on cable landing station in France. Can someone explain me what exactly is happening here? Are they missing some iBGP sessions? It's not perfect mesh & missing route reflectors? Probably both prefixes are originated inside India by different routers but as I understand all prefixes get transit from AS6453 and so is it like AS6453 missing some routes (which seem to be direct) to technically downstream AS4755? Curious to hear your thoughts. Note: I am not worried about issue - it's not really impacting me. Just trying to learn what is wrong in the backbone design here. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com

4 4

Routing Resilience Survey (a project coordinated by ISOC)
by Andrei Robachevsky 18 Nov '13

18 Nov '13

Hello everyone, I'd like to draw your attention to an effort coordinated by the Internet Society aimed at a better understanding of Internet-wide routing security issues. This effort is based on the collection of incident data related to routing resiliency to provide a statistically representative picture of these incidents and their impacts, as a basis for risk assessment and global trend analysis. We would like to invite network operators to join this effort. You can find more information about this project here: https://www.internetsociety.org/rrs/ For participating network operators the project will help answering questions like: - What happens with my prefixes elsewhere in the global Internet? - What impact routing misconfigurations can have on my network? - How "safe" the global routing system is? One important thing I'd like to mention here is related to confidentiality. We understand the sensitivity of some of the data involved in this effort. Therefore, the Internet Society is committed to ensuring participant-specific information remains confidential. All data collected will be stored on Internet Society servers. Any public information or analyses will be fully anonymized. This is a 6-month effort. After the project is successfully completed we will publish a report presenting the findings, statistical data and trends. We'll also be happy to present the results at one of NANOG meetings. We hope you will join this effort. Thanks, Andrei Robachevsky Internet Society

1 0

List of CDNs?
by Carlos Kamtha 17 Nov '13

17 Nov '13

Hi, I was wondering if anyone knows where I could find a compiled list of Content Delivery Networks as well as thier DC nodes? if any.. Please respond offlist. Cheers, Carlos

10 16

Cisco announces it will no longer publishing The Internet Protocol Journal
by Courtney Smith 17 Nov '13

17 Nov '13

Another one bites the dust. Received the below this AM. Hopefully, something similar finds it's way into an electronic format. TO OUR READERS At this time, Cisco Systems, Inc. has decided not to continue publishing The Internet Protocol Journal (IPJ) effective immediately. Cisco wishes to thank Ole Jacobsen, the Editor and Publisher of IPJ for his tireless and professional efforts to inform the community of the Internet, its varied protocols, and its impact upon the world through this publication. Cisco also wishes to thank the authors of the published articles, and all those who submitted articles. A special note of thanks goes to the IPJ Editorial Advisory Board and the article reviewers who have helped to maintain the very high standards of journalistic and technical quality of IPJ. The online version of the Internet Protocol Journal will remain available for reference, including all back issues in PDF and HTML format as well as the index files. The IPJ website remains at:http://www.cisco.com/ipj Courtney Smith courtneysmith(a)comcast.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 2

Best band for your buck router and switch (gigabit)
by Nick Cameo 17 Nov '13

17 Nov '13

Hello Everyone, We are in the market for a used integrated service router and switch to manage our network. A 24 port gigabit switch should suffice accompanied with an industry grade router. We like buying used (still under warranty) equipment as long as there is good feedback. Which make and models are you gents and ladies liking these days? Some Requirements for the router: IPSEC and VPN Enabled Transcoding capabilities using PVDM2 and NM-HDV2 We were considering: Cisco 3845 Cisco WS-C2960G-24TC-L But I thought I would get some insight on value, pricing, and scalability before making a recommendation. Kind Regards, Nick.

7 10

Re: Best band for your buck router and switch (gigabit)
by Nick Cameo 16 Nov '13

16 Nov '13

On 11/15/13, Eric Tykwinski <eric-list(a)truenet.com> wrote: > Nick, > > It really depends on your deployment. If you are looking at Cisco and doing > BGP, I wouldn't go with a 3800 series. > Memory constraints will kill you, especially in dual stack. > > If I was looking for an all in one on the cisco side of things, I'd look at > a Catalyst 6500 series. Battle tested with redundant power, supps, etc... > > If you are looking for cheap and don't mind learning a new OS. MikroTik: > http://www.mikrotik.com/ > Well used in SE Asia, and while I wouldn't use them for mission critical > mainly due to lack of a good service contract, they do hold their own. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > Hello Eric, Thank you so much for your response. The 6500 is what I was trained on however, for this case we cannot afford the rackspace. We're building highly efficient networks using mainly virtual machines and fiberchannel backbone. I did however overlook the 1Gig limit of the 38/3900s.... So basically build our own linux router using a stripped down version of gentoo? N.

2 1

A new forum for discussing large scale TLS/SSL and other crypto deployment issues
by Peter Eckersley 15 Nov '13

15 Nov '13

Dear network operators, Some you may be interested in a project that EFF is launching at the moment, which is intended to be a forum for knowledge sharing amongst people trying to figure out how to deploy TLS and other forms of crypto securely and at large scales. ("What kind of load balancers will terminate 100,000 TLS connections/sec?" "How do I audit our properties for mixed content?" "What resources will it take to enable perfect forward secrecy for a large userbase?" "What kind of certs should I deploy for a large and complicated set of services? Is there a way to use SNI?" etc, etc). The mailing list is intended primarily for people who have complex scalability hurdles to overcome for deploying crypto. It will operate under Chatham House rules. https://lists.eff.org/mailman/admin/crypto-ops Hopefully this will be followed shortly by a wiki to publicly document knoweldge coming out of this conversation. -- Peter Eckersley pde(a)eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993

2 2