On Sun, May 30, 2010 at 10:16:14AM -0700, Kevin Oberman wrote:
>
> I remember a posting to this list back in the late 90s from Tony Li,
> who knows a bit about BGP. He urged that multi-hop BGP never be used
> and pointed out that it had not been intended for use except as a test
> tool, not a prod
> Date: Sun, 30 May 2010 18:39:39 +0200
> From: Randy Bush
>
> > your perfectly fine multihop BGP session could break when rerouting
> > occurs.
>
> one of the many reasons that there are no perfectly fine multi-hop bgp
> sessions.
I remember a posting to this list back in the late 90s from Ton
* Rubens Kuhl:
> On Sun, May 30, 2010 at 1:46 PM, Florian Weimer wrote:
>> * Randy Bush:
>>
your perfectly fine multihop BGP session could break when rerouting
occurs.
>>>
>>> one of the many reasons that there are no perfectly fine multi-hop bgp
>>> sessions.
>>
>> Uhm, is there a way
On Sun, May 30, 2010 at 1:46 PM, Florian Weimer wrote:
> * Randy Bush:
>
>>> your perfectly fine multihop BGP session could break when rerouting
>>> occurs.
>>
>> one of the many reasons that there are no perfectly fine multi-hop bgp
>> sessions.
>
> Uhm, is there a way around them when building t
>>> your perfectly fine multihop BGP session could break when rerouting
>>> occurs.
>> one of the many reasons that there are no perfectly fine multi-hop bgp
>> sessions.
> Uhm, is there a way around them when building the iBGP mesh?
nope
* Randy Bush:
>> your perfectly fine multihop BGP session could break when rerouting
>> occurs.
>
> one of the many reasons that there are no perfectly fine multi-hop bgp
> sessions.
Uhm, is there a way around them when building the iBGP mesh?
> your perfectly fine multihop BGP session could break when rerouting
> occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
randy
* Rubens Kuhl:
>> You need to put a filter on your interfaces that references a
>> filter later on to not session track a flow. I think you need to
>> be running Junos-jsr[0] 10.0 or 10.1 to use this :
>
> The same goes for 9.x, just be sure to except traffic to the router
> (like BGP session) fr
> You need to put a filter on your interfaces that references a filter later on
> to not session track a flow. I think you need to be running Junos-jsr[0]
> 10.0 or 10.1 to use this :
The same goes for 9.x, just be sure to except traffic to the router
(like BGP session) from the packet-mode, th
On 28 May 2010, at 00:27, Ken Gilmour wrote:
> ISP1 is the default gateway, ISP2 is a backup provider but which is always
> active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
> Client comes in on ISP2's link (non default gateway) but for some reason,
> the packets seem t
* Ken Gilmour:
> ISP1 is the default gateway, ISP2 is a backup provider but which is always
> active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
> Client comes in on ISP2's link (non default gateway) but for some reason,
> the packets seem to be going back out through the
Then you should look at your IGP, right?
On Fri, May 28, 2010 at 8:09 AM, Ken Gilmour wrote:
> Hi Jian,
>
> Yes sir that's what I thought too. The packets are being NATted (and I also
> used a bit of DNAT for port forwarding to test the theory) but the result is
> the same.
>
> Regards,
>
> Ken
>
On 5/28/2010 07:37, Mark Hermsdorfer wrote:
> Having said that, If the JunOS based SRX platform does not do session
> tracking in the same was as the SSG platform it would seem that the most
> reasonable solution would be to NAT the traffic as has already been pointed
> out.
Gonna really highligh
Ken Gilmour wrote:
Strangely, BGP actually works without issues. The only issue is with
statically routed ranges.
Same rules apply, just without control on your end. If a packet hits
ISP2, ISP2 will send it to you by most ISP standards (prefer direct
customers over peers). Outbound, you w
> We replaced our OpenBSD routers with these SRXes since they were supposed to
> be multifunction devices (gateways and routers at the same time) which was
> the selling point. So we expected them to do asymmetric routing and were
> told they could, easily, but apparently they are not acting normal
On Fri, May 28, 2010, Ken Gilmour wrote:
> Yes sir I have used SSG for several years but mainly used BSD for the last
> decade and most recently OpenBSD. There is an easy fix for this on PF for
> OpenBSD and that is to tag the packets from each provider (as in not using
> 802.1q but a specific fun
Hi Joe,
On 28 May 2010 08:13, Joe Maimon wrote:
> Firewalls that can route and service properly multiple "untrusts"?
>
> Good luck. Hit or miss. Constant flux.
>
> Place a router in front of it and that will get you a ways there.
We replaced our OpenBSD routers with these SRXes since they wer
Hi Jack
On 28 May 2010 07:08, Jack Bates wrote:
>
> Your BGP config with ISP2 is probably unideal. This has lead to packets
> coming in via ISP2 despite the fact you prefer to use ISP1. Often, people
> only do AS Prepend to alter traffic patterns. However, if a packet finds
> it's way to your di
Hi Mark,
On 28 May 2010 06:37, Mark Hermsdorfer wrote:
>
> Ken,
>
> As others have pointed out typically interfaces are not kept track of in
> state tables. Having said that, I've worked in the past with the ScreenOS
> based SSG platforms that do this. So if you're coming from an SSG
> backgro
uter instance is needed not forwarding instance as in this
guide.
Jensen Tyler
Network Engineer
Fiberutilities Group, LLC
-Original Message-
From: Jensen Tyler [mailto:jty...@fiberutilities.com]
Sent: Friday, May 28, 2010 10:07 AM
To: Ken Gilmour
Cc: nanog@nanog.org
Subject: RE: Junos As
Hi Joe,
Interesting questions, Answers are below your questions:
On 28 May 2010 00:33, Joe Blanchard wrote:
> That would seem to be a good resolution (Firewall/NAT) . Aside from that,
> perhaps a load
> balancer for each segment might help?
>
Possibly but this will cost money to implement and
Hi Jian,
Yes sir that's what I thought too. The packets are being NATted (and I also
used a bit of DNAT for port forwarding to test the theory) but the result is
the same.
Regards,
Ken
On 27 May 2010 23:46, Jian Gu wrote:
> Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the
, 2010 9:14 AM
To: Ken Gilmour
Cc: nanog@nanog.org
Subject: Re: Junos Asymmetric Routing
Firewalls that can route and service properly multiple "untrusts"?
Good luck. Hit or miss. Constant flux.
Place a router in front of it and that will get you a ways there.
Ken Gilmour wrote:
>
Firewalls that can route and service properly multiple "untrusts"?
Good luck. Hit or miss. Constant flux.
Place a router in front of it and that will get you a ways there.
Ken Gilmour wrote:
Hi all,
I have a very peculiar situation here that i seem to have difficulty
explaining in such a way
Ken Gilmour wrote:
Yes I believe that would be the default if the session was initiated on the
inside, but if it comes from outside on a particular interface which is not
the default route, why would the router then send the packet out another
interface? Should the device not route session-based
Ken Gilmour wrote:
ISP1 is the default gateway, ISP2 is a backup provider but which is always
active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
Client comes in on ISP2's link (non default gateway) but for some reason,
the packets seem to be going back out through the li
On Thu, May 27, 2010 at 8:38 PM, Ken Gilmour wrote:
>
> Yes I believe that would be the default if the session was initiated on the
> inside, but if it comes from outside on a particular interface which is not
> the default route, why would the router then send the packet out another
> interface?
That would seem to be a good resolution (Firewall/NAT) . Aside from
that, perhaps a load
balancer for each segment might help?
One question that comes to mind is why (if ISP2 is a backup) would valid
traffic
be using that route?
Unless maybe your loadbalancing using a DNS round robin perhaps to
Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the
problem gracefully? when connection requests coming in through ISP2,
source NAT the incoming traffic's source IP with IPs on firewall
inside interface, that way when server replies, firewall 2.2.2.1 will
guarantee to receive the A
On 5/27/2010 19:38, Ken Gilmour wrote:
> Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares!
>
> On 27 May 2010 18:07, Ricardo Tavares wrote:
>
>> Not sure if I correctly undestand you but default route its the route
>> that the packet must follow if it do not have a specific rou
f the route announce is coming from the BGP neighbor you need to
verify if the next-hop indicated for this route is itself reached by
the router, if by recursion the router do not resolve how to go to the
next-hop then the announced route will be not available. THe bgp
sender must set the next-hop
On 2010-05-27 17:38, Ken Gilmour wrote:
Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares!
On 27 May 2010 18:07, Ricardo Tavares wrote:
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a specific route for the
Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares!
On 27 May 2010 18:07, Ricardo Tavares wrote:
> Not sure if I correctly undestand you but default route its the route
> that the packet must follow if it do not have a specific route for the
> destination, so, if the next-hop for
Hi Ken,
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a specific route for the
destination, so, if the next-hop for the source IP (3.3.3.3) is not in
the route table then the packet will follow the default route (ISP1).
So, thi
Hi Ken,
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a specific route for the
destination, so, if the next-hop for the source IP (3.3.3.3) is not in
the route table then the packet will follow the default route (ISP1).
So, thi
On 5/27/2010 18:27, Ken Gilmour wrote:
> Hi all,
>
> I have a very peculiar situation here that i seem to have difficulty
> explaining in such a way for people to understand. I just got off the phone
> to the Juniper Devs after about 4 hours with no result. They understand the
> problem but can't
36 matches
Mail list logo
