tag:blogger.com,1999:blog-3993498847203183398.post7811094885359335696..comments2024-03-28T09:19:27.451+00:00Comments on RevK<sup>®</sup>'s ramblings: Non standard BGPRevKhttp://www.blogger.com/profile/12369263214193333422noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-3993498847203183398.post-82455025491708761852012-02-06T17:35:42.074+00:002012-02-06T17:35:42.074+00:00It is BGP to support L2Tp to them, so not that bad...It is BGP to support L2Tp to them, so not that bad to say don't peer with other customers. But they could just say that - they don't need firewalls and if they did, then why not lock down IPs we can use.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-13134510085070649892012-02-06T17:17:50.178+00:002012-02-06T17:17:50.178+00:00"to stop us peering with another of their cus..."to stop us peering with another of their customers"<br /><br />OK. That sounds like a potentially dangerous statement from your carrier. <br /><br />Firstly, why would they disallow you from peering with another of their customers?<br /><br />And secondly, if you were to peer with another of their customers, you would need a separate TCP session... Whether your BGP session with the carrier has a TTL 1, 64 or 255 is irrelevant.<br /><br />Are they saying that they will drop *any* bgp traffic (i.e. 179/tcp) you send to them? I would consider an Internet BGP Transit connection with arbitrary port/protocol filtering to be not fit for purpose.<br /><br />I guess they may be applying limits to what you are allowed to do with the link address they have assigned. They will probably have registered this under their name as an INFRA-AW assignment, so I guess there could be a valid argument to do this. It is not something that I have ever seen elsewhere though.Anonymoushttps://www.blogger.com/profile/08962909183683758785noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-24416319535173004632012-02-06T16:04:57.020+00:002012-02-06T16:04:57.020+00:00The main thing is we cannot see why they insist on...The main thing is we cannot see why they insist on it - it is not clear. It is not security, like TTL security would be. The protection from silly mistakes is what helps us so why insist. Indeed for the silly mistakes angle they can send TTL 1 and avoid any issues without insisting on it being TTL 1 from us.<br /><br />The only comment so far was to stop us peering with another of their customers via the link - but surely, like other carriers do, you just set fire-walling as to what we can peer with to be their routers and only their routers. That has to be more logical.<br /><br />Just damn strange, in my experience. We have had no issue with transit or peering or other carriers. This lot seem to be pretty unusual and for no good reason.<br /><br />Oh well.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-40603602065706661232012-02-06T15:45:09.558+00:002012-02-06T15:45:09.558+00:00We do it with one supplier (Jump Networks Ltd), it...We do it with one supplier (Jump Networks Ltd), it doesn't cause us any problems and their reasoning for insisting on it is relatively sound - likewise, we use it on point-to-point links where we are not peering with the loopback interface of either router for the reasons that Russell has already explained.<br /><br />Usually, the admin can say, "My network, my rules!" just as A&A has an Acceptable Use Policy but peering is always a fun one as it is the point where two disparate networks meet therefore AUPs don't always apply (a kind of 'No Mans' Land' for want of a better term).<br /><br />The point being that one admin may not always see eye to eye with the other admin which is what I suspect has happened here.Terry F.https://www.blogger.com/profile/13969846575454712191noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-17573426013665456072012-02-06T14:48:56.595+00:002012-02-06T14:48:56.595+00:00OK, a sanity check may make sense, though TTL secu...OK, a sanity check may make sense, though TTL security covers that nicely too :-)<br /><br />But insisting we send TTL 1 is a tad strange, IMHO. Glad you agree.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-18552877528396179082012-02-06T14:43:35.231+00:002012-02-06T14:43:35.231+00:00Not defending the practice - but have been using B...Not defending the practice - but have been using BGP for long enough to know something of the reasoning behind this...<br /><br />With an eBGP session, it is generally preferred to configure the session over a directly connected link, so there is no risk of a device in the middle having a different forwarding table and introducing a forwarding loop.<br /><br />In some cases you do want to have an indirect (aka multihop) session but generally this is a bad idea.<br /><br />Setting the TTL to 1 is not so much a security measure as a sanity check. Consider a BGP session going over an unnumbered PPP link, where the peer addresses at each end of the link are also the loopback addresses of the routers. If you were to set the TTL to 64, and had an alternate route to your BGP peer with 5 hops (e.g. via a peer at LINX) it is possible that the eBGP session would stay up, even though there is no valid adjacency. <br /><br />Setting the TTL does not protect you from malicious sources out on the big bad Intertubes, but it can protect you from your own mistakes... <br /><br />I agree that making it mandatory and calling it a security feature is dumb though.Anonymoushttps://www.blogger.com/profile/08962909183683758785noreply@blogger.com