|
Don't use bgp weight attribute as it's proprietary to Cisco. Use localpref, med/metric, and as-path length.
|
#
?
Dec 16, 2015 14:05
|
|
|
|
| # ? May 30, 2024 23:49 |
|
|
Or just say screw it and let serial numbers sort it out
|
|
#
?
Dec 16, 2015 17:56
|
|
|
falz posted:Don't use bgp weight attribute as it's proprietary to Cisco. Use localpref, med/metric, and as-path length. Yeah, this. I had to find out the hard way when I started integrating non-cisco hardware into my BGP peers.
|
|
#
?
Dec 16, 2015 20:11
|
|
|
Methanar posted:Do you you have to phone other network admins responsible for other AS numbers to request changes? IRC is usually faster
|
|
#
?
Dec 17, 2015 04:34
|
|
|
how loving deep does this enterprise rabbit hole go  
|
|
#
?
Dec 17, 2015 09:01
|
|
|
1998 called and wanted their clip art back.
|
|
#
?
Dec 17, 2015 09:28
|
|
|
They also want their XML based configuration back.
|
|
#
?
Dec 17, 2015 17:18
|
|
|
Collateral Damage posted:Does anyone know why some Aironet 3702i would trigger BPDU guard on a connected Cisco 2960-X, while most others don't? As far as I can see the configuration in the APs are identical. Is it an autonomous AP? Because if so, I'd say because it is sending tagged frames.
|
|
#
?
Dec 17, 2015 19:28
|
|
|
Methanar posted:Alright just for fun I'm playing with BGP and set up a simple network. All the basic configuration is done with ospf/eigrp redistributed into the bgp. Everything works. If you control AS200, it easy to control your egress traffic without talking to the other AS's. Local Preference should do the trick for the network you are interested in. If you want to treat a particular link to an AS as a back up and you are learning all networks from both, you can set local-preference on import. Note that all this stuff ONLY affects traffic outgoing, incoming traffic is significantly more difficult to influence.
|
|
#
?
Dec 17, 2015 19:33
|
|
|
quote:bgp Neat. While I'm at it, does anyone have some good ideas for interesting situations that I should try to model and play with?
|
|
#
?
Dec 17, 2015 19:47
|
|
|
Speaking of BGP fun. I requested a /27 from our carrier, GTT. They gave it to me, and then I advertised it to them via BGP. I couldn't get ping to work, so obviously it was an issue with them not accepting the prefix. I open the ticket and was informed they only accept /24's  Anyway, 'Tier2' whatever that is, made changes to the import policy so I'm good to go now.
|
|
#
?
Dec 17, 2015 19:48
|
|
|
Methanar posted:Neat. Create a transit AS with 5 or so AS's. Then figure out how to prevent it. For extra credit think about why you normally wouldn't want to be a transit AS on the internet.
|
|
#
?
Dec 17, 2015 19:50
|
|
|
Powercrazy posted:Create a transit AS with 5 or so AS's. Then figure out how to prevent it. Because 50gbits of netflix
|
|
#
?
Dec 17, 2015 19:51
|
|
|
Most providers don't accept anything larger than a /24 prefix via BGP to keep the global table from getting out of hand. I'm guessing you have two connections to GTT and are just doing BGP with them for redundancy? I can't imagine any other carrier accepting a /27 from some one else's allocation via BGP.
|
|
#
?
Dec 17, 2015 19:59
|
|
|
Methanar posted:Neat. Start introducing iBGP inside your AS. For example, in AS200 you would have separate routers connected to AS100 and AS300. Build a large BGP core in a single AS (4+ routers). Then collapse that into a 2 router core with Route Reflectors.
|
|
#
?
Dec 17, 2015 20:11
|
|
|
Powercrazy posted:Speaking of BGP fun. I requested a /27 from our carrier, GTT. They gave it to me, and then I advertised it to them via BGP. I couldn't get ping to work, so obviously it was an issue with them not accepting the prefix. I open the ticket and was informed they only accept /24's That's weird. I thought /24 is the accepted minimum for the global BGP table to the point that multi homing is an instant justification for a /24 (well, up until depletion). Hopefully they summarize somewhere.
|
|
#
?
Dec 17, 2015 20:19
|
|
|
Powercrazy posted:Speaking of BGP fun. I requested a /27 from our carrier, GTT. They gave it to me, and then I advertised it to them via BGP. I couldn't get ping to work, so obviously it was an issue with them not accepting the prefix. I open the ticket and was informed they only accept /24's I had some fun times with GTT supporting us sending them a /25+/24 pair over 2 circuits (each sent a different /25 with NO-EXPORT of the aggregate /24). Talked to design, said everything was fine. Talk to implementation tech, said everything was in place. Sent traffic to each /25, all traffic went over one link. Took a few days of emailing to finally get it sorted out.
|
|
#
?
Dec 17, 2015 20:45
|
|
|
Methanar posted:Neat. I would add in IS-IS, set up some route redistribution between each protocol, possibly BGP confederation, MED, communities (both exporting and importing).
|
|
#
?
Dec 17, 2015 20:47
|
|
|
I'm studying for my CCENT and I'm not quite clear on something. When you summarize a route, you're basically creating a secondary routing table for the summarized addresses in the same router, right?
|
|
#
?
Dec 17, 2015 21:26
|
|
|
KS posted:That's weird. I thought /24 is the accepted minimum for the global BGP table to the point that multi homing is an instant justification for a /24 (well, up until depletion). Was instant justification until the ipv4 supply ran out. Now ARIN tells you to buy/rent portable address space from your ISP, or go buy some from an IPv4 scalper. Also prefixes >/24 are still rejected by the vast majority of peering orgs and I don't see that changing after ARIN flatly rejected the vote delegate prefixes > /24 All pressure is to move to IPv6 now anyways.
|
|
#
?
Dec 17, 2015 21:39
|
|
|
I did reference depletion.22 Eargesplitten posted:I'm studying for my CCENT and I'm not quite clear on something. When you summarize a route, you're basically creating a secondary routing table for the summarized addresses in the same router, right? If a router knows how to get to a bunch of small networks and they all go to the same next hop, you can set the router to summarize that route into a bigger network that contains all of the smaller ones. Example: 10.10.10.0/24 10.10.11.0/24 10.10.12.0/24 could be summarized as 10.10.8.1/21 That router can then be set to distribute the summary route instead of a bunch of smaller routes when it talks to other routers. This keeps the routing table smaller and easier to manage.
|
|
#
?
Dec 17, 2015 21:42
|
|
|
Okay. So the router doing the summarization has all of the routes in its table, but it tells the other routers on the network that it has the summarized routes instead.
|
|
#
?
Dec 17, 2015 21:51
|
|
|
Yeah. Summarization is all about what it advertises.
|
|
#
?
Dec 17, 2015 21:53
|
|
|
KS posted:Yeah. Summarization is all about what it advertises. Careful when using this with BGP, summarization happens on a timer- but the router will advertise all prefixes it receives as soon as it gets them, then withdraw them later when they get summarized. This could be a bad thing if one or more of your peers has a max-prefix facing you.
|
|
#
?
Dec 17, 2015 22:20
|
|
|
Filthy Lucre posted:Most providers don't accept anything larger than a /24 prefix via BGP to keep the global table from getting out of hand. Only have a single connection with GTT, but also have a connection with Zayo. We advertise our Arin assigned block to both. However we want an additional provider specific IP block to terminate some AWS vpns so we can do some crude traffic engineering from AWS Tokyo. The point is, GTT is advertising the supernet, a /17 or something and they gave us a /27 that will stay within their AS, so the usual /24 wouldn't apply in this case.
|
|
#
?
Dec 17, 2015 23:06
|
|
|
Methanar posted:Because 50gbits of netflix Now how do you prevent becoming a Transit AS?
|
|
#
?
Dec 17, 2015 23:10
|
|
|
Powercrazy posted:Now how do you prevent becoming a Transit AS? bgpq3  e: also upgrade your ScreenOS devices http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554
|
|
#
?
Dec 18, 2015 01:30
|
|
|
doomisland posted:bgpq3 Not as shocking as it initially reads. You need administrative access to the device to do any decryption.
|
|
#
?
Dec 18, 2015 02:04
|
|
|
H.R. Paperstacks posted:Not as shocking as it initially reads. You need administrative access to the device to do any decryption. I read that there were 2 vulnerabilities: one that let you gain administrative access over SSH/telnet, and another that let you decrypt VPN traffic. e: here's the link - http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713&actp=search madsushi fucked around with this message at 02:15 on Dec 18, 2015 |
|
#
?
Dec 18, 2015 02:12
|
|
|
madsushi posted:I read that there were 2 vulnerabilities: one that let you gain administrative access over SSH/telnet, and another that let you decrypt VPN traffic. In order to decrypt the VPN traffic, you need to have administrative access to the device via SSH. In order to exploit the SSH/Telnet vulnerability, you need to have the ability to get at the control plane of the device. Typical CPP and BCP when it comes to securing a device stops both of these issues. I only allow SSH to devices from a specific subnet on a specific interface, one that is in an OOB network, or a separate VRF at minimum.
|
|
#
?
Dec 18, 2015 02:18
|
|
|
Powercrazy posted:If you control AS200, it easy to control your egress traffic without talking to the other AS's. Local Preference should do the trick for the network you are interested in. If you want to treat a particular link to an AS as a back up and you are learning all networks from both, you can set local-preference on import. I think most carriers will honor the AS-PATH you set so prepending is generally the fastest way to influence inbound routing. I could be wrong though. In other news has anyone configured a noviflow-based openflow lab? Our carrier just publicly announced their testbed for this active and it looks sweet (if you like Java).
|
|
#
?
Dec 18, 2015 02:25
|
|
|
H.R. Paperstacks posted:In order to decrypt the VPN traffic, you need to have administrative access to the device via SSH. In order to exploit the SSH/Telnet vulnerability, you need to have the ability to get at the control plane of the device. Typical CPP and BCP when it comes to securing a device stops both of these issues. Right. In addition this only affects a narrow range of OS releases. So while it's significant, I think even though Screen has a huge deployment, the actual number of compromised scenario's is low.
|
|
#
?
Dec 18, 2015 02:26
|
|
|
H.R. Paperstacks posted:I only allow SSH to devices from a specific subnet on a specific interface, one that is in an OOB network, or a separate VRF at minimum. If you're doing things securely, sure. But you can look at any of the internet port scans to see that there's plenty of stuff with admin access exposed to the internet. When I was doing consulting, I saw many environments where administrative access was open publicly so their team could "remote in" to fix things. I am sure there are tons of ScreenOS boxes with the SSH box ticked in their Untrust interface settings, and the fact that they could be totally owned is bad.
|
|
#
?
Dec 18, 2015 02:32
|
|
|
abigserve posted:I think most carriers will honor the AS-PATH you set so prepending is generally the fastest way to influence inbound routing. I could be wrong though. Only takes one transit AS to strip the duplicate path, and then it does nothing.
|
|
#
?
Dec 18, 2015 02:47
|
|
|
I guess ScreenOS isn't dead yet?
|
|
#
?
Dec 18, 2015 04:15
|
|
|
inignot posted:I guess ScreenOS isn't dead yet? Banks and credit processors.
|
|
#
?
Dec 18, 2015 04:32
|
|
|
Powercrazy posted:Only takes one transit AS to strip the duplicate path, and then it does nothing. I don't think I've ever seen an implementation which does this, but prepending everything to TE a single remote AS is a pain in the rear end, and kind of a blunt object approach. Ideally your transit will have prepend communities (to prepend to a specific peer of theirs- they usually don't implement this on customer sessions), or path poisoning is the other trick if you need to TE an AS that's 1+ hops out.
|
|
#
?
Dec 18, 2015 04:34
|
|
|
ragzilla posted:I don't think I've ever seen an implementation which does this, but prepending everything to TE a single remote AS is a pain in the rear end, and kind of a blunt object approach. Ideally your transit will have prepend communities (to prepend to a specific peer of theirs- they usually don't implement this on customer sessions), or path poisoning is the other trick if you need to TE an AS that's 1+ hops out. Hmm. Well how about this scenario. We have multiple providers and we are trying to get to a remote AS, (AWS Tokyo) from New York. Somewhere in the BGP chosen return path is congestion/loss/internet fuckery. So our ~200Mb/s SCP transfer speeds drop to 150kb/s. AS-prepend didn't redirect the return path traffic for whatever reason, but withdrawing the prefix from one of our providers, using a do not advertise community did work to shift return traffic to the other provider, and more importantly fixed the slow transfer speeds. What would you do to address it? Note that i'm not a carrier or anything, this is just our own prefix from our own AS, dual homed. ate shit on live tv fucked around with this message at 04:55 on Dec 18, 2015 |
|
#
?
Dec 18, 2015 04:52
|
|
|
out of curiousity, at what size of business (bank if it matters) should I be to (be worried about) get my own AS?
|
|
#
?
Dec 18, 2015 05:07
|
|
|
|
| # ? May 30, 2024 23:49 |
|
|
adorai posted:out of curiousity, at what size of business (bank if it matters) should I be to (be worried about) get my own AS? If you host public web services and have IPv4 space, you should have your own AS number. They are easy to get unlike IP addresses.
|
|
#
?
Dec 18, 2015 05:13
|
|