Hi Jacek,
If the secondary IP on FastEthernet0 is from your address space and there is
no dynamic routing between the customer and ISP B (ISP B has no knowledge of
your address space at the customer site), then traffic from your IP block
should NOT return via ISP B.
If you do not meet these criteria, let me ask some questions:
1. Is the secondary IP range that you are trying to use policy-routing to
force to your ISP from your address space (or does the secondary range NAT
to one of your IPs)? If yes, then all clients using that space should be
coming back through your link if you are the only BGP speaker announcing
that network. If it is address space from ISP B or they are announcing the
network in addition to you, then there could be multiple routes. It needs
to be your address space unless you do option 2 below.
2. Is this a permanent solution or are you trying to get the customer to go
with you and drop ISP B altogether? That makes a huge difference in
configuration if redundancy/failover needs to be factored in. I'll assume
the customer wants to keep both connections in my responses below.
If you can't/won't use BGP to solve this, I only see the following choices
left:
1. If you have no communication/relationship with ISP B -
Customer gets addresses from both providers - default to provider B, policy
route A addresses to provider A (that's what you're trying if the secondary
is your IP). You'll need a floating default to provider A in case the B
link goes down, and you'll need to NAT A addresses if they take the B path
and NAT B addresses if they take the A path. That way all traffic can get
out if a link fails and all traffic can find its way back, and it will
return via whatever pipe it goes out.
2. If you have communication/relationship with ISP B -
Both ISPs can announce the addresses delegated to the customer from the
other ISP (or you as ISP A announce the ISP B addresses and don't assign any
of your own to the customer). You'll both have to announce the same NLRI
for the range or BGP will actually prefer the other provider for your space
(takes the most specific route). Keep policy mapping as is, no NAT needed,
but this will not guarantee symmetrical routing for reasons Howard and
others stated earlier - you have no control over other AS routing policies.
3. If you are using private address space (can't tell from your sample but
I didn't see NAT statements so I assume you replaced public with private
before sending), you can use a variant of either 1 or 2 - there will be NAT
going on all the time rather than for specific uses.
It sounds like 1 will be the easiest and will show the customer how your
connection performs versus the competition. If you don't need redundancy
then you can do #1 and not worry about any NAT at all.
If you want even more answers, I suggest posting to comp.dcom.sys.cisco -
someone there can probably give you the same or better answers as I did but
in an intelligible format :)
Andrew Cook
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Jacek Malinowski
> Sent: Sunday, March 04, 2001 7:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Route-map
>
>
> I want only to know if I've a default route ( 0.0.0.0 0.0.0.0 serial 1),
> and ip policy route-map on the ethernet interface,
> I'll go always trough serial 1 or if the match criteria are met I'll go
> trough serial 0 ?
>
>
>
>
> _________________________________
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
